Combo boxes are really hard, 'emKay!

[Minty23185Fresh]

Here's the question: Can the dropdown list for a combobox "splash" outside of the combobox's container (window)?

Here are the details of the situation: For the Field Filters for All Libraries extension I am trying to implement a windowlist that will contain the field filters. That way if there are a large number of filters, as there are for the NPCs library, only a finite number are displayed at any one time and the user would use a scroll bar to access the others.

The way I have implemented it is: the windowlist contains a collection of "items". Each item is a window that contains a field name text box and a selection of filter choices, a combobox.

The drop down list of choices cannot splash out over the size of the containing window. So if the window containing the combobox is the same size as the combobox, the dropdown doesn't even show up, the control appears non-functional.

To solve this, when the combobox drops down, I dynamically resize the container (the window). It looks a bit funny, but it does work.

Back to the question: Is there a property, that I have overlooked, that would allow the combobox's dropdown to splash outsides of the containing window? (I would be surprised if there were such an option, because this would allow the drop down list to possibly fall outside the parent form, which would probably be bad, 'emkay?)

And because I like pictures (and diagrams) here they are:
There are three screenshots in this illustration. On the left is a diagram of the windows, subwindows and controls., In the center is my modified masterindex object for the NPCs library. Note the similarly to the current standard dialog, though there is some "blank real estate" at the bottom, which is the statically sized windowlist. The right panel shows how the "Type" field filter is relocated when the "CR" field filter's combobox is clicked. Room for the dropdown list is had by resizing the "CR" field filter's container.
Untitled.png

It would really be nice if I could just have the dropdown list splash over the top of the other controls and not have to resize some and relocate the others.

[celestian]

Try using UP, not DOWN.

[Nickademus]

No it can't.

[Minty23185Fresh]

Try using UP, not DOWN.

Celestian, I may not have made myself clear, I guess. Just changing the drop direction won't help.

In the graphic you included, the filter and filter value controls are "encapsulated" by the form (the default CoreRPG behavior), so there is plenty of real estate for the combo box drop downs to drop "up" into. If you were to change the drop direction to "down" for those controls, the drop downs for those controls near the bottom of the form would get "chopped off" because their full height would fall outside the form.

In my case, the controls are encapsulated by two additional layers of windows/controls. The filter and the filter value controls are encapsulated by a windowclass (name="...item"). The dimensions of the window are just large enough to contain the two controls (roughly w=365, h=25). Furthermore, the items, one for each pair of controls, are encapsulated, by a windowlist, which is large enough to contain seven item windows (roughly w=the form's width, h=180).

So in my case, the drop down (or drop up) can't display outside the item window, without programmatically resizing the height of the item window. And then, the drop down (or up) as well as the item window, can't display outside the confines of the windowlist, therefore a scrollbar.

I could demonstrate this with more screenshots but I'm hoping this verbose explanation will do.

[Minty23185Fresh]

No it can't.

Nickademus, I suspect that is directed at me. Thanks for confirming.

An opinion please: if I construct, instantiate, and anchor the drop down (or drop up) at form level rather than at control level, it seems to me that my issue of "splashing" over the top of other controls would be solved. Binding to the control, yet "living" at form level might prove problematic.

[Moon Wizard]

The convolutions and coding you are describing would seem that they would lead to brittleness (ie easy to break when updating or modifying).

This discussion jogs my memory as one of the reasons why I implemented the solution the way I did, so that combo box up would work.

Perhaps a better solution would be to allow people to add/remove which filters to use, but to cap at 3-4 to reduce clutter. This also keeps everything visible by default.

Regards,
JPG

[Nickademus]

Nickademus, I suspect that is directed at me. Thanks for confirming.

An opinion please: if I construct, instantiate, and anchor the drop down (or drop up) at form level rather than at control level, it seems to me that my issue of "splashing" over the top of other controls would be solved. Binding to the control, yet "living" at form level might prove problematic.

I had thought of this, but it does have its own issues. You would have to get the size and position of the parent button to know where to build the dropdown list. You might also have to institute a control mechanism to ensure the user doesn't interact with other controls while the list is active, or that the list disappears when they do (which is actually already done in the current dropdown). All in all, it is complex and suggests being problematic as JPG has stated, but it's something that I would try to do. And thus I feel it is something that you would try to do. Let me know if get it working. I can't remember if I have any code in my Adventurer's Journal extension that might help, but you are welcome to it if you want. The extension is still in Alpha and hasn't been released to the public, though it contains a set of custom dropdown classes. Might find something useful in there.

[Minty23185Fresh]

Perhaps a better solution would be to allow people to add/remove which filters to use, but to cap at 3-4 to reduce clutter. This also keeps everything visible by default.

That's the ultimate goal. For me, baby steps to get there. And actually the detour is worth it. After this latest exercise, I believe I have a real understanding of and confidence with anchoring.

[Minty23185Fresh]

Thanks Moon Wizard and Nickademus for your input and hints at the possible problems.

As it turns out the most complicated issue was programmatically calculating the offsets. Creating the dropdown list control at form level was easy. There is an invisible <genericcontrol>, an anchor for other controls on the form, just below the central items/records list. I dropped the following script into it:

   <script>
      function getCustomFilterControl(sType, sName)
         return window.createControl(sType, sName);
      end
   </script>

The custom filter list is anchored to that form level <genericcontrol> so offset calculation from it to the combobox isn't horrible.

As you both warn, there is a bit of window.windowlist.window "spaghetti coding" going on but most of that is inherent to the custom filter list itself rather than the "re-scoped" dropdown list.

Here is a screenshot. It looks just like the ruleset's masterindex doesn't it? Except for the tiny bit of clipping of the magnifying glasses due to the subwindows of the custom filter list. The custom filter list caps out at five, and then the user is provided with a scroll bar for the rest.
Untitled.png

And again thanks for the pointers.

[Nickademus]

Glad you got it working. Looks good.