RE: [ANNOUNCE] Tk-JComboBox 1.06

 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 
> Sent: May 10, 2005 11:28 AM
> To: Jack D.
> Cc: 'PerlTk List'
> Subject: 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 like -searchanchor.

In one application I have a list of GEONAME places in Canada. So I might
have cities, lakes, rivers, unincorporated places, etc. I have a built in
checkbutton filter based on these groups. One of the filters is just "water
bodies" for simplicity. However - this could be lakes, rivers or bogs. The
names of the lakes all end with "Lake" as you might expect. Such as
"Jackfish Lake" - so there will be times I just want to type in "Lake" to
see all the lakes - say - within Alberta. Same thing for mountains ...

In another application I'm working on right now (which is what I want this
module for). I have a list of BMX riders - thus -
"Firstname_LastName_Class". I might have 10 "Tylers" or "Dylans" or
what-have-you. But if I could just type in the first few letters of their
last name into the box - bingo - autofind finds it quickly.

In yet another application - I have airport identifiers, names, elevation
etc. - in a string. Without using any filters - I can type in either an
identifier OR name criteria and it quickly gets found.

The first and last apps I mention here were written a number of years ago -
and there was no widget to do this sort of thing back then. So I just used
an Entry and a scrolled Listbox to do the trick. Beside the entry I had one
checkbutton - "From beginning". I changed my regexp based on the boolean
value of that checkbutton.

> 
> > 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.

I think you might want to get Mr. Lidie's opinion on this first! It took me
3 hours to track down a bug in a new module I wrote. Without getting in to a
bunch of details - if you put a "trace" on a variable then you cannot get at
the changed data without going through the methods in Tk::Trace. This
defeats the purpose. I would rather use a JComboBox method :-)

> 
> > 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.

I'm thinking that it might be more hassle than it's worth. But there must be
a way? This is what the -textvariable option is all about - so the
programmer can change the variable and boom - instant GUI update. I have
just become so used to that nice functionality that it is hard to give it up
:-)

> 
> > 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.

Thank you for explaining this in detail. Indeed I never would have thought
of that. I saw that Tk::DateEntry has similar "grab-saving" code. I was
wondering why - now I know.

Jack
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ptk" to [email protected]