Re: Funny business with Perl/Tk 804.027-4, Entry and Optionmenuwidgets.

W Knol <[email protected]> writes:
>Some comments on Perl/Tk 804.027-4, recently installed from Debian 
>unstable.
>
>This version broke my code (which worked perfectly with Perl/Tk 800  - 
>Debian Sarge package) in three places.

Tk800 -> Tk804 is quite a major change.

Tk800 has not been under active development for years, last 
patch I have recorded is back in 2002.

Tk804 is much closer to mainstream tk core (but is still slipping).

>
>Using Perl/Tk 800.027, the Entry widget caused me problems:

There is no such thing as Tk800.027 !?

There is a Tk804.027 - and I am probably way overdue doing another release.

I don't know what the -4 suffix might mean.

>
>1. The insert/delete mode byte passed to the '-validatecommand => key' 
>callback is '8' resp. '7'. The docs claim it should be 1 resp. 0. The 
>obvious work-around is to test for 1|8 resp. 0|7.
>
>2. My key validation callback changes keystrokes to upper case as the 
>user types them. It does this through the 'textvariable'. This used 
>to work well. Under 800.027, it works...but only for the the first 
>time. The 'validate' callback is silently disabled once modification 
>of the entry string through the textvariable (or through 
>$entry->insert) has taken place. The docs make no mention of this.
>
>My work-around is to insert 
>  $entryWidget->configure( -validate => key); 
>...at the end of the callback code.
>
>3. Strange behaviour was observed with the Optionmenu widget. Once 
>options had been added to this menu, I used to be able to pre-set a 
>default option from my code through the assigned textvariable. 
>However, the Perl/Tk 800.027 interpreter quietly ignores the 
>textvariable. As a result, the widget defaults to the last option 
>added. Interestingly, the fix was to bring the -textvariable 
>definition out to it's own separate statement:
>
> $sbOptionmenu->configure( -textvariable => \$txtVar );
>
>I am not sure whether these things are bugs, undocumented features or 
>a result of dodgy coding (by me :-)

Neither am I. 

Please clarify _EXACTLY_ what $Tk::VERSION was on version which 
worked and version which doesn't.

If you really meant Tk800 then yes Tk804 it is incompatible in several 
ways with it, but maintaining Tk800 diverged from core Tk was becoming 
impossible.



-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]