[opendx-users] SelectorList: bad dog

[Chris Pelkie]

I wonder if any of the original coders (Greg, Donna, Martin, Nancy, et al) have any thoughts on the apparent design decision that causes SelectorList to automatically select its first list item when DX first executes, if the SelectorList is data-driven (and forced to yield an output).

I never liked this widget, so just became aware of this behavior because a colleague started using it and observed this. He thinks it's a bug; I'm calling it a non-optimal design decision for now. Happens on Linux, Mac, and Windows in 4.3.2.

Description of issue:
x=List('a', 'b');
y=SelectorList(stringlist=x);
Print(y);

Put SelectorList on a Control Panel. Execute.
SelectorList properly constructs item list 0=a, 1=b; a is selected, Print yields 'a'.
Toggle 'a' to OFF (up). Execute. Print yields 'null object'.
Reset Server and Execute. SelectorList sets 'a' to ON and Print yields 'a'.

If you disconnect List now (after SelectorList has been initialized to 0=a, 1=b) and unset both a and b, then
Reset Server, Execute, Print yields 'null object' and neither item is set to ON.

There is no apparent way to defeat the auto-setting of item 1 on first execute in the data-driven case.

In my friend's case, this means an unwanted Control Panel pops up and must be closed by unclicking the first toggle in SelectorList each time he starts up (he's using upstream inputs to generate a name list of CPs, sending the list to SelectorList, then to ManageControlPanels). We got around it by prepending a bogus item with:
x=List('a','b');
y=List("------",x);

This creates a new entry at the top of the list that will be auto-selected but doesn't correspond to a Control Panel name, so nothing annoying pops up.

Thoughts anyone?
_______________________________
Chris Pelkie
Scientific Visualization Producer
622 Rhodes Hall, Cornell Theory Center
Ithaca, NY 14853