PerlTk - [ANNOUNCE] Tk-JComboBox 1.06

Author

[ANNOUNCE] Tk-JComboBox 1.06

Rob Seegel

2005-05-10, 8:57 am

Tk-JComboBox version 1.06
=======================

Notes for 1.06 release:

This release includes a fix for a bug where JComboBox could interfere
with DialogBox's or any other widget that needed to use grab/grabGlobal.
Ken Prows discovered the bug, and provided a patch for the problem. I
added a test case to test that the new code works as expected.

I've taken another crack at repairing the test cases (I'm cautiously
optimistic that they will work.) The Test suite may have been a bit
ambitious and maybe even a bit overzealous, but I'm trying to make it
work. See Changes for more details.

I'd like to say thank you to Ken Prows (for bug reports, scripts that
show the problem, and patches!), Todd Beverly, Paul Allen, Zentara,
Corion, Saper, and any others who have run the tests on different
machines for me, and were helpful in tracking down the problems.

Feel free to post comments, suggestions, and complaints to this list,
private email.

Thanks!

Rob
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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 majordomo@lists.stanford.edu

Jack D.

2005-05-10, 3:57 pm

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.

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?

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.

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.

Jack
PS - Sorry for the top-post :)

> -----Original Message-----
> From: owner-ptk@lists.Stanford.EDU
> [mailto:owner-ptk@lists.Stanford.EDU] On Behalf Of Rob Seegel
> Sent: May 10, 2005 1:53 AM
> To: PerlTk List
> Subject: [ANNOUNCE] Tk-JComboBox 1.06
>
> Tk-JComboBox version 1.06
> =======================
>
> Notes for 1.06 release:
>
> This release includes a fix for a bug where JComboBox could
> interfere with DialogBox's or any other widget that needed to
> use grab/grabGlobal.
> Ken Prows discovered the bug, and provided a patch for the
> problem. I added a test case to test that the new code works
> as expected.
>
> I've taken another crack at repairing the test cases (I'm
> cautiously optimistic that they will work.) The Test suite
> may have been a bit ambitious and maybe even a bit
> overzealous, but I'm trying to make it work. See Changes for
> more details.
>
> I'd like to say thank you to Ken Prows (for bug reports,
> scripts that show the problem, and patches!), Todd Beverly,
> Paul Allen, Zentara, Corion, Saper, and any others who have
> run the tests on different machines for me, and were helpful
> in tracking down the problems.
>
> Feel free to post comments, suggestions, and complaints to
> this list, private email.
>
> Thanks!
>
> Rob
> -++**==--++**==--++**==--++**==--++**==--++**==--++**==
> 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
> majordomo@lists.stanford.edu
>
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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 majordomo@lists.stanford.edu

RobSeegel@comcast.net

2005-05-10, 8:57 pm

-- NextPart_Webmail_9m3u9jl4l_12821_1115746
083_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

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 m
ost 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 interfe
red 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
-- NextPart_Webmail_9m3u9jl4l_12821_1115746
083_0
Content-Type: text/html
Content-Transfer-Encoding: 8bit

<html><body>
<DIV>Jack wrote:<BR>> This is the module I've been looking for (I think). I want to use the <BR>> -autofind option but I have one request. Please add another autofind option <BR>> which would search m/any/ part of the string as opposed to just fr
om the <BR>> m/^beginning/. I can think of numerous applications that I have written that <BR>> indeed search "within" the string. <BR></DIV>
<DIV>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.</DIV>
<DIV><BR>> I haven't tested it yet - but it sounds as if this module has the same <BR>> drawback (my word choice) as Tk::MatchEntry. If I give a reference to a <BR>> simple array as the -choices option, and then I change the array by adding <BR>&
gt; or deleting or what-have-you, does your module automatically see this? Or <BR>> must one reconfigure the widget? Are we forced to use your add and delete <BR>> methods thereafter? <BR></DIV>
<DIV>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. </DIV>
<DIV><BR>> Maybe I'm thinking of this all wrong. Even Tk::Optionmenu -options has to be <BR>> reconfigured if the list changes. Obviously - I *will* use your methods to <BR>> add and delete items if need be. But I guess I look at it this way; I'm
<BR>> already adjusting the array in another part of my program and it would be <BR>> nice if the Combobox just "knew" about it. </DIV>
<DIV> </DIV>
<DIV>I'll take a crack at implementing it -- feel free to take a stab at it yourself if you'd like. </DIV>
<DIV><BR>> One more thing: I'm curious as to the exact details of the bug with <BR>> grab/grabGlobal. I think you monitor c.l.p.t.? Just recently I posted a <BR>> work-in-progress which uses grabGlobal for a popup window. I would certainly like t
o avoid any bugs if I can. </DIV>
<DIV> </DIV>
<DIV>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).</DIV>
<DIV> </DIV>
<DIV>Now let's say that the JComboBox instance resides within a Dialog Box -- or some other frame that may also does a grab. </DIV>
<DIV> </DIV>
<DIV>The sequence would go something like this:</DIV>
<DIV> </DIV>
<DIV>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).</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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&nbs
p;could have interfered with other components.</DIV>
<DIV> </DIV>
<DIV>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.&nb
sp;</DIV>
<DIV> </DIV>
<DIV>Rob</DIV>
<DIV> </DIV></body></html>

-- NextPart_Webmail_9m3u9jl4l_12821_1115746
083_0--
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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 majordomo@lists.stanford.edu

James D. White

2005-05-10, 8:58 pm

RobSeegel@comcast.net wrote:

> Jack wrote:
>
> that
[color=darkred]
> 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.

Another option would be to explicitly allow a reference to a regular expression

for the autofind option. If it is a regular expression reference, then assume
the
caller knows how to anchor or not as desired. If not a regular expression,
then
assume the anchor, with or without options.

$pattern = (ref $autofind eq 'Regexp') ? $autofind : qr/^$autofind/;

> ...rest of message deleted...
>

--
James D. White (jdw@ou.edu)
Director of Bioinformatics
Department of Chemistry and Biochemistry/ACGT
University of Oklahoma
101 David L. Boren Blvd., SRTC 2100
Norman, OK 73019
Phone: (405) 325-4912, FAX: (405) 325-7762

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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 majordomo@lists.stanford.edu

Jack D.

2005-05-10, 8:58 pm

> -----Original Message-----
> From: RobSeegel@comcast.net [mailto:RobSeegel@comcast.net]
> Sent: May 10, 2005 11:28 AM
> To: Jack D.
> Cc: 'PerlTk List'
> Subject: RE: [ANNOUNCE] Tk-JComboBox 1.06
>
> Jack wrote:
> to use the
> autofind
> opposed to just
>
> 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.

>
> has the same
> reference to
> the array by
>
> 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 :-)

>
> -options has
> *will* use your
> look at 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
:-)

>
> recently I posted
> 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 majordomo@lists.stanford.edu

Rob Seegel

2005-05-10, 8:58 pm

James D. White wrote:

> Another option would be to explicitly allow a reference to a regular expression
>
> for the autofind option. If it is a regular expression reference, then assume
> the
> caller knows how to anchor or not as desired. If not a regular expression,
> then
> assume the anchor, with or without options.
>
> $pattern = (ref $autofind eq 'Regexp') ? $autofind : qr/^$autofind/;

That isn't a bad idea... I was actually considering creating another
CALLBACK option that could be applied to each entry, until a match is
found. I figure that could grant all the flexibility someone could ask
for. There could be a default CALLBACK in place that could implement the
work for -searchanchor. I'm going to experiment with it a bit.
>
> --
> James D. White (jdw@ou.edu)
> Director of Bioinformatics
> Department of Chemistry and Biochemistry/ACGT
> University of Oklahoma
> 101 David L. Boren Blvd., SRTC 2100
> Norman, OK 73019
> Phone: (405) 325-4912, FAX: (405) 325-7762

Huh... small world, my inlaws live in Norman - nice place so long
as you can avoid the occasional class 5 that rips the place up.

Rob

Rob Seegel

2005-05-11, 3:59 am

Jack,

Thanks for the examples you list below! I'm always interested in
different ways people use to similar problems.

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

Yes, this case right here was the driving force between -autofind.

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

Ok.. yes, I can see this one.

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

Huh... sounds interesting enough, but I confess that it seems like a
slightly different spin on my preconceived notions of what a ComboBox
might be used for. I'm not against it by any means, but it might have to
be one of those things I'd have to see to truly "get" it.

It sounds a lot like something I've implemented in the past that
consisted of a composite that consisted of an entry atop of a Listbox
that could display many entries. Both Entry and Listbox were always
visible. The Entry served as a way of limiting what was displayed within
the Listbox, and I could specify arbitrary patterns within the Entry.
Slightly more complex behavior, but fewer moving parts.

>
> 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 :-)

What!? and deprive me of the fun of stumbling around in the dark for a
little while first? I wasn't planning on using Tk::Trace (though truth
to tell, that's a new one to me, so maybe I should take a p

at it).
I'm sure Steve will throw me a rope if I start to drown ;-)

Well, I agree - it WOULD be nice. It's a shame that such a simple
sounding idea is most likely going to require a solution that is
anything but.
[color=darkred]
> 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
> :-)

Could be - but I'm glutton for punishment, and it seems like an
interesting thing to look into. It's similar to the idea of MVC
components in Java, where changes to the model get applied to the View.
Plus it gives me an opportunity to take a closer look at some of the new
perl code in the Listbox widget -- have you looked at it? Interesting
stuff, and something I haven't had a chance to do much with up til now.
Unfortunately, my internal representation of a List item is not the same
as what get's passed in as an array reference, so there may be a bit
more complexity.

If nothing else, I have a fairly decent suite of Test cases to let me
know if I start going to far with the changes...

Rob

Rob Seegel

2005-05-11, 3:59 am

Jack D. wrote:

> 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.
>
>
Well, in all fairness -- it didn't really occur to me either, though now
that I think about it, I can recall seeing code that did this before.
I'm glad that Ken pointed it out. ;-)

Rob
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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 majordomo@lists.stanford.edu

Sponsored Links