Combobox is always in read mode

HCL Domino Domino Forum
1
  • While attempting to resolve this (), the combo box suddenly decided it should be readonly. Now it’s stuck there forever, apparently. Nothing what-so-ever will make it editable. I’ve tried:

  1. Removing the readonly attribute from the combobox.

  2. Explicitly setting readonly=“false” on the combobox.

  3. Doing a clean & build on the custom control.

  4. Shutting down DDE and doing a full rebuild on the code.

  5. Shutting down DDE, deleting cache.ndk, unloading http, flushing cache, and doing a full rebuild on the code.

  6. Shutting down the server, rebooting the machine running DDE, and doing a full rebuild on the code.

After each action I cleared cache and reloaded the browser, yet the combobox is still readonly, ei, it cannot be edited when the document is in edit mode.

This is important because I’m making a custom control to simulate combo boxes that have “allow values not in list” set. The only way that control can set the value is to use getItemValueString(). Yet when I do that, the combobox is never editable. Sort of defeats the purpose.

Here’s the current Xpage source:

<xp:comboBox id=“someField” value=“#{javascript:doc.getItemValueString(‘field’)}”>

<xp:selectItems>

	<xp:this.value><![CDATA[#{javascript:

		var items=@DbLookup(@DbName(), "Lookup", "fieldKeys", 2);

		(items==null ? "" : items);

	}]]></xp:this.value>

</xp:selectItems>

<xp:selectItem itemLabel="#{javascript:doc.getItemValueString('field')}" />

</xp:comboBox>

On a whim I set value=“doc.field”, instead of using getItemValueString(). Now it’s editable again.

If I use “$” instead of “#” on a getItemValueString() setting, that combobox is editable even in read mode. It seems unlikely this is intentional behaviour…

EDIT:

  • If I take out value= and use xp:this.defaultValue with getItemValueString(), then the combobox is always editable, regardless of whether $ or # are used.

  • At this point it looks like I’ve wasted the days spent attempting do anything out of the ordinary with an Xpage combobox, which has been my experience over and over and over again. The supplied controls are simply inadequate for anything but the simplest, most mundane purpose. Every single thing I’ve done, I’ve used gobs of time building a custom solution. Sure I can reuse that work, but it’s been a glacially slow nightmare.

  • I’m feeling more and more like Xpages are pretty, but doing anything truly complicated is impossible because of constant flaky behaviour. Views allow ad-hoc data binding, but static column settings. Comboboxes work differently depending how the default value is set. The date picker forces a value to appear even when no validation is set. DDE refused to keep my compiler version settings. Showing column value as an icon takes hours of searching and fiddling to function. The list goes on and on and on. I’ve squandered dozens upon dozens of hours doing nothing but trying to work around the constant randomness.

  • I’d literally have this project finished if I’d used R-prior technology, with LS Agents and pass-thru HTML building custom web rendering, but instead I don’t even have trivially simple elements of the UI working reliably. It’s phenomenally difficult to look at Xpages as a step forward at this juncture.