Multi-select list on form via embedded xdialog

[Bill Murray]

I'm trying to create a multi-select list on a form. The only way I've found to do this is to embed an Xdialog supercontrol in the form. That part works. But I need to show/report which items in the original list were selected and keep the order of the original list. That requires knowing what the original list order was, as discussed here:

http://msgboard.alphasoftware.com/al...ad.php?t=84693

Therefore, I need to send 2 variables back to the form from the embedded Xdialog, the multiple selections plus the original list.

I set up a form in a sample db to illustrate this, named some_new_form.

If I click on the embedded Xdialog, I can return 1 of the variables back to the form via binding, but I can't manage to make the other one return. I've tried a lot of things, but nothing seems to work. Is there a limit on the number of variable bindings in an embedded xdialog? Based on the description at the top of the Embedded Xdialog window, which says "You can link variables in the dialog to fields and variables on the form by adding them to the bindings list", it sounds like binding multiple variables should work. But nothing I've tried let's me get more than 1 back.

Can someone see a problem in what I've done or explain how to get more than 1 variable back from an embedded Xdialog?

[Tim Kiebert]

Re: Multi-select list on form via embedded xdialog

Works in v9. Report it as a bug. I was also getting Unhandled exception errors which closed Alpha

Edit: just tested in the new Beta patch and doesn't work there either.

[Bill Murray]

Re: Multi-select list on form via embedded xdialog

Thanks for the testing & feedback, Tim.

I just tested it myself in v9 and it works for me as well. I'll report it.

[Cian Chambliss]

Re: Multi-select list on form via embedded xdialog

I took a look at the application and determined that the problem is that we *assume* the bound variables are passed in from the form (i.e. form determines initial values) - the xdialog gets set up *before* even the forms OnInit event occurs.

Given that the design assumes that the xdialog first 'consumes' variables, after which we respond to changes, having the LIST reflected in the xdialog requires the form to initialize the list.

I was able to get this working by Create an OnInit event for the form that looks like this:

dim global vmyVar2 as c
dim tbl as p
tbl = table.open("anothertable")
vmyVar2 = tbl.record_content_get("myfirstfield")
tbl.close()
vmyVar2 = line_insert(vmyVar2,"All",0)



This xdialog code I changed to this:


DIM item as c
DIM vlist as c

'IMPORTANT: Do not change the dialog title.
ui_modeless_dlg_box(dlgTitle,<<%dlg%
{watch=vlist}
{background=<Transparent>}

[%M%.40,5item^#vlist];
{lf};

%dlg%,<<%code%

%code%)

And the variable binding to this:

item=VAR->vMyVar1
vlist=VAR->vMyVar2


Important to note - I needed to add a {watch=} expression to xdialogs list variable to address a caveat in xdialog - if no xdialog event has occurred, the xdialog does *not* check to see if the list has changed. On the plus side, changes to vmyvar2 made on the form get reflected in the xdialog when the user gives it focus.

[Bill Murray]

Re: Multi-select list on form via embedded xdialog

Thanks for taking a look at it and making a suggestion.

Unfortunately, at least on my system, the suggestion doesn't work, assuming I copied/pasted correctly. I've uploaded a revision with your code in the OnInit event and a revised embedded Xdialog. In the RC, what I see happening is that only 1 of the 2 variables shows on the form. In my real work, I implemented your suggestion and had a slightly different result. I could get both fields to display, but only on the 2nd pass of displaying the form. The first time, the embedded xdialog was blank but clicking in it caused the entries to appear. Also, although I set the equivalent of vMyVar1 to a value, I couldn't get to show as selected on the form.

The original code worked fine in ver 9, as Tim & I confirmed. Was this an intentional change in the way variable bindings worked from ver 9 to 10?

Any other suggestions?

[Cian Chambliss]

Re: Multi-select list on form via embedded xdialog

You are correct - When I tested the form, I forgot to take into consideration that the variable in question is a global - so it was remembering the value from the *first* pass. If I start from scratch I have to run the form twice.

This issue seems to be caused by a bug in form-embedded xdialogs - it appears that the watch on this xdialog is *never* being evaluated. I put a couple watches on the xdialog & none are ever getting evaluated, its as if the xdialog is locked, prevented from processing watch events- This is a bug that needs to be fixed & once it is fixed the example provided should work.

[Cian Chambliss]

Re: Multi-select list on form via embedded xdialog

I have a work-around that should work with the existing build the first time through.

This uses direct binding to 'vMyVar2', instead of making a copy - my first attempt failed because the Global frame appears to be 'hidden' from the xdialog (another bug - which I am looking into). I got around this by getting an explicit pointer to the global variable frame, and accessing the globals through that pointer.

DIM item as c
DIM g as p = global_variables()


'IMPORTANT: Do not change the dialog title.
ui_modeless_dlg_box(dlgTitle,<<%dlg%
{watch=g.vMyVar2}
{background=<Transparent>}

[%M%.40,5item^#g.vMyVar2];
{lf};

%dlg%,<<%code%

%code%)


Then you can remove the binding to vmyvar2, since it is being used directly.

[MikeC]

Re: Multi-select list on form via embedded xdialog

Bill,
Although using the embedded xdialog gives you the added option of multi-select via highlighting, an embedded browse with checkboxes will do the same as the checkbox xdialog control....just another option if this doesn't work out for you.

...unless this is a networked situation--then, if the embedded xdialog is still unbound from a table it would be better. Which I guess is just a related question--Is an xdialog that is embedded in a form and bound to data still unbound to a table thus preventing networking issues?? Guess it would depend upon how the data is being bound to the xdialog. I could experiment but maybe someone knows already......

[Bill Murray]

Re: Multi-select list on form via embedded xdialog

@ Cian - The workaround works. Thanks. One thing I'll point out for others following this: you have to set any default value for the field in the form (in this case vMyVar1) in the OnInit event. Another thing: because the xdialog assumes the variables are there even before the OnInit event, you can create the same affect by running any script that initializes the variables as globals as long as you do it before you open the form.

But that leaves unanswered this question: the original design worked in v 9. It changed in v 10. Was that intentional, because v 9 wasn't working the way it should? Cian, can you comment on that?

@ Mike - Ignoring the networked implications, it comes down to design preference. In another thread, you showed a big xdialog where you used checkboxes in a browse, but then you had to create a button to select "all". That button took up space and made the xdialog crowded, IMO. The checkboxes themselves took up horizontal space. By inserting "all" into the list and by avoiding the button, you save both horizontal and vertical screen real estate. And this technique was only required to put the selected items in the original list order. If you take out that consideration, it works even without Cian's workarounds. But your tip is a good one to add to the toolbag. You never know when you have to go digging in there for another tool.

[Cian Chambliss]

Re: Multi-select list on form via embedded xdialog

Hi Bill - form initialization has completely changed between v9 and v10 because of the browse rewrite, and because of the 'bound property' feature - variable update occurs at the same time as dynamic properties calculation - this was done to fix issues were variables were *not* being refreshed.

The issue I was seeing when I debugged the code is that it appeared that the xdialog was being initialized, then the binding occurred *after* the fact - at which point the binding needs to determine *which* variable/field is correct - it currently assumes that the form level variable/field WINS over the xdialogs variable.

V9 worked in this case because of a different ordering of operations, but has its own set of caveats.

The only design level change I can see making that could fix this ambiguity would be to make variable binding a separate pass, and do it BEFORE any of the controls are opened.

The Good news from this is that two serious bugs were uncovered and fixed as a result of this investigation:

1) {watch=} now works properly for xdialog supercontrols - the locked control issue has been resolved.
2) Global & Shared variables were *not* visible to the xdialog supercontrol (I tested this against v9 as well - it has the same problem) - in the next patch, they should work fine, which will eliminate the need to make 'bound' copies of the list variables in the first place, people will just be able to directly use the form variables to populate the listboxes. The 'selected' variable will still want to be bound, however since both the xdialog AND the form can change them.

[Bill Murray]

Re: Multi-select list on form via embedded xdialog

Thanks, Cian. That explanation is very useful. Great job on getting to the bottom of this so quickly.

[Tom Cone Jr]

Re: Multi-select list on form via embedded xdialog

Cian, could you elaborate on the concept of "bound variables" and "binding variables" and "bound property"? Without experience using super-controls I"m having trouble following this discussion. Where might I turn for mor information on this? Thanks.

-- tom