RE: [ANNOUNCE] Tk-JComboBox 1.06

Jack wrote:
> This is the module I've been looking for (I think). I want to use the 
> -autofind option but I have one request. Please add another autofind option 
> which would search m/any/ part of the string as opposed to just from the 
> m/^beginning/. I can think of numerous applications that I have written that 
> indeed search "within" the string. 

Ok, this should be trivial to add support for. Perhaps an option called patternanchor or searchanchor (any other suggestions?) that could take one of the three options:  start, end, any, and would default to "start" which I imagine would be the behavior most would expect, I'm interested to hear of your cases where you would want the search within the String.

> I haven't tested it yet - but it sounds as if this module has the same 
> drawback (my word choice) as Tk::MatchEntry. If I give a reference to a 
> simple array as the -choices option, and then I change the array by adding 
> or deleting or what-have-you, does your module automatically see this? Or 
> must one reconfigure the widget? Are we forced to use your add and delete 
> methods thereafter? 

Currently, it does have the same drawback, but I could probably use a tie to support this. This may take a little time, but let me take a crack at it over the next few days and see what I come up with. 

> Maybe I'm thinking of this all wrong. Even Tk::Optionmenu -options has to be 
> reconfigured if the list changes. Obviously - I *will* use your methods to 
> add and delete items if need be. But I guess I look at it this way; I'm 
> already adjusting the array in another part of my program and it would be 
> nice if the Combobox just "knew" about it. 

I'll take a crack at implementing it -- feel free to take a stab at it yourself if you'd like. 

> One more thing: I'm curious as to the exact details of the bug with 
> grab/grabGlobal. I think you monitor c.l.p.t.? Just recently I posted a 
> work-in-progress which uses grabGlobal for a popup window. I would certainly like to avoid any bugs if I can. 

Ok, it's something like this, whenever the Listbox popup is displayed, it does a global grab to prevent you from interacting with other GUI elements until the popup is hidden again (whether from a selection or some other event).

Now let's say that the JComboBox instance resides within a Dialog Box -- or some other frame that may also does a grab. 

The sequence would go something like this:

1. I press a button that triggers a dialog box, that dialog box is doing a global grab, preventing me from interacting with other components until I dismiss the window (until grabRelease is called).

2. My dialog box happens to contain a JComboBox instance. I perform some action that causes the popup to be displayed. When that occurs, it calls grabGlobal and "steals" the grab from the Dialog box.

3. I select an item or otherwise cause the JComboBox popup to be hidden again. It releases the grab -- but for the entire application, and I can now access other components, even though my Dialog box is still up.  In this way, JComboBox could have interfered with other components.

The new version fixes this by checking to see if any other widget current has a grab, and what type. If so, both pieces of information or stored for when the JComboBox releases its grab, and the previous one is then reinstated. 

Rob