in reply to Re^6: Tk::Entry and double-Tab key weirdness
in thread Tk::Entry and double-Tab key weirdness
The -font => '{arial} 18 {bold}' syntax seems pretty clean, but from my experience, setting the font with fontCreate always resulted in fewer glitches. I'm an old timer, and started Tk when you needed to specify fonts with stuff like:
Yuck!. Also see Tk Font Manipulation. When you use fontCreate to create the font, you can more easily manipulate them later.-font => '-Adobe-Courier-Bold-O-Normal--*-120-*-*-*-*-*-*';
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^8: Tk::Entry and double-Tab key weirdness
by atreyu (Sexton) on Jun 01, 2012 at 17:49 UTC | |
got it, thanks, zentara. All,I have changed up the code considerably, though the intent remains the same: validate text input intended for a MAC address. The most significant change is that I did away with using Tk::Entry validation, and instead am using bind subroutines to validate. I did this b/c I didn't like how if the user enters invalid text, it would not appear in the field (and I couldn't figure out how to insert it w/out breaking validation). Not only would users not see the invalid character that was entered, but they would have to back-space and delete the last visible character in the field in order to re-engage validation, even though the last displayed character in the field IS valid. I've also added a Save button which will validate all the individual Entry fields in one fell swoop. If all the MAC input fields validate, then the new MAC is printed in a separate ROText widget. Also, I've added a drop-down (Tk::Optionmenu) widget to allow selecting b/t multiple NICs; whichever is selected is the "current" NIC, as far as the MAC input fields are concerned. For the most part, I happy, but after all my changes, I now have two new Tab issues, neither of which I've been able to solve, so here I am.
Problem 1:
I can't keep the Tab order in the way I want it. It should go: NIC-Oct1->O2->O3->O4->O5->O6->Save but instead, it goes:NIC->Save->Oct1->O2->O3->O4->O5->O6 I have tried using this convention:But that breaks validation. I'm sure it has something to do with the way I am willy nilly disabled/enabling the -state and -takefocus options of the widgets, but I can't see the light. <<<<<<>>>>>>> Here's the new code:
Edit:
| [reply] [d/l] [select] |
by zentara (Cardinal) on Jun 02, 2012 at 10:07 UTC | |
Problem 1: When the app first starts up, I use eventGenerate bindings (to Tab and KeyRelease) to automatically tab thru all the MAC input fields and "auto-validate" the initial values. It works great, but if a bad octet is discovered, it will still continue to validate all the subsequent octets. Instead of eventGenerate, maybe try looping thru all Entries using $entry->focusForce? Problem 2: I can't keep the Tab order in the way I want it. Try this code:
I have a funny feeling that you are the only one still seeing this thread (i.e., the only monk I'm bugging)...maybe i'm just not good w/the forum views. can u tell me how I can view recently updated threads, or how do others know when a thread has been updated, if they aren't currently "subscribed" to it? Or is there no such thing? Monks usually look thru the Notes section, below SOPW, and see if there is a reply which they are interested in. Maybe Perlmonks could do a Facebook-like hack and charge $2 bucks to keep your reply to the top of the list. :-) Your best bet to get more monks to look at your problem, especially after making major code modifications, is to post a new SOPW node, and mention this node as a reference. I mentioned that entry validation is very hard to deal with correctly, and your code now has become quite complex. That probably scares off the casual monk. You should try to make smaller examples which only demonstrate one of the glitches you are running into, if you want more viewers. P.S. As I was considering all your difficulties, and musing how I might tackle it, I came up with an idea which may help you. Instead of relying totally on the validated entry widget to hold all the correct entry data, why not put a parallel set of read-only Entry widgets( or properly packed set of Label widgets ) aligned right on top of your current widget set. The idea would be that as valid entry text is detected, the corresponding Label would change, and you would be focused to the next invalid Label and it's corresponding validation Entry widget. You would put all your -textvariable data into the Labels, and test them for validity with your own routine, and change bg color for each invalid value. Then you would use the validation Entries solely for entering values to be placed in the Labels, if valid. The user would know they are done, when all the Labels have white background instead of hotpink. :-) I hope I got the idea across. It would free you up from being confined to all the internal bindings of the validation Entry. I'm not really a human, but I play one on earth. Old Perl Programmer Haiku ................... flash japh | [reply] [d/l] |
by atreyu (Sexton) on Jun 04, 2012 at 15:53 UTC | |
i tried that before, to no avail - at least the way I implemented it:
It will force the focus thru all 6 fields, to be sure, and will highlight bad input entries, but will not halt the tab on the first (or any) failed input field. Try this code: thanks for that (your tab ordering code), i will test it. Monks usually look thru the Notes section, below SOPW, and see if there is a reply which they are interested in. Maybe Perlmonks could do a Facebook-like hack and charge $2 bucks to keep your reply to the top of the list. :-)hah! thanks for the heads up. i do love this forum, but i do not love the interface. i usually depend on a "perlmonks <question>" google search more than using the actual website. but it is good to know the M.O. of the monks. Your best bet to get more monks to look at your problem, especially after making major code modifications, is to post a new SOPW node, and mention this node as a reference. I mentioned that entry validation is very hard to deal with correctly, and your code now has become quite complex. That probably scares off the casual monk. You should try to make smaller examples which only demonstrate one of the glitches you are running into, if you want more viewers.yes, you're right, of course. btw, i included the whole code as a reference, in case anybody else was wanting to do something like this (has helped me in the past when others have done so). P.S. As I was considering all your difficulties, and musing how I might tackle it, I came up with an idea which may help you. Instead of relying totally on the validated entry widget to hold all the correct entry data, why not put a parallel set of read-only Entry widgets( or properly packed set of Label widgets ) aligned right on top of your current widget set. The idea would be that as valid entry text is detected, the corresponding Label would change, and you would be focused to the next invalid Label and it's corresponding validation Entry widget. You would put all your -textvariable data into the Labels, and test them for validity with your own routine, and change bg color for each invalid value. Then you would use the validation Entries solely for entering values to be placed in the Labels, if valid. The user would know they are done, when all the Labels have white background instead of hotpink. :-)That's not a bad idea...i'll consider that. Thanks for all you help and suggestions, and sticking w/my tedious problems, zentara! | [reply] [d/l] |