What the HELL is wrong with page???? I need to position some items exactly. I type in the EXACT COORDINTATE I NEED BUT PAGE REFUSES IT AND CHANGES IT for example i need a button at X=203, y=674 but page changes my entries to something else, say 208 and 672, or some bs. I tried setting the grid in preferences to 1 , but no difference. Is page ver 8 positioning really this crappy??? I DON'TWANT PAGE TO CHANGE THE COORDINATES I PROVIDE
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok. I'm going to put on my teacher sweater and tennis shoes, like Mr. Rogers and give you a BUNCH of information first. I'm fairly certain you don't know the background and underlying "science" behind the issue you are having. Please read all of the information that I am going to provide and then I'll provide what I think the issue is that you are dealing with and how to "work around it".
First, let me say that yes, there are some positioning issues in PAGE, but this is partially due to Tcl/Tk and partially due to the various windowing managers of the Operating systems that PAGE (and Tcl/Tk) don't have any control over. PAGE supports Windows 7, 8 (if you can find them), 10 and 11, Mac Os X and Linux. Linux has many windowing managers like Gnome, Mate, Cinnamon, XFCE, just plain X11 and not Wayland is thrown into the mix and brings it's own issues for PAGE to try to handle. Each of the Windowing managers have their own quirks and problems.
PAGE is built around the Tcl/Tk Toolkit. Tk was build to ONLY be used on X11 Windowing manager systems (i.e. Unix/Linux). However, the Tcl/Tk group worked very hard to support the Microsoft Windows and the Mac Windowing managers. Not an easy task.
Secondly, I too have been frustrated over the 10+ years that I have been using PAGE. In order to have a button to appear centred (British spelling) within in a frame, I usually need to use a "fudge factor" of 2 or three pixels. It's something I've gotten used to.
So I can understand your frustration, but will ask that you moderate your language. This is a "Rated PG" forum and this WILL continue to be such.
PAGE uses the PLACE geometry manager system within in Tk (Tkinter). There are two other geometry managers within Tk which are PACK and GRID. Each of the three have their own good points and bad points. If you were to use Pack or Grid, you would have almost no control over the placement and/or size of individual widgets within a toplevel form.
To use the Place geometry manager under Python/Tkinter/Tk/Ruby/Perl uses a syntax (depending on the widget) of something like this.
widget.place(x,y,height,width)
(actually height and width can be swapped if you use the parameter names, but we'll stick with the above example.)
Now, if you take a look at the GUI code from an example from PAGE of a simple button placed on an empty Toplevel form, you will see something like this...
The second line is the important one. I'm guessing that if you look at your GUI.py file you will see the same thing.
Instead of a X and Y position, you will see the relx and rely parameter names instead of the more logical straight x and y position parameter names.
(We are getting close to the reason and my attempt at a fix for you now. Hold on.)
Now if you look at your PAGE Main window, you will probably find that in the lower right of the window the word "Relative" . This means that if you (or your user) resize the Toplevel form during runtime, the widgets (at least most of them) will grow and resize along with the form. All the widgets are place and sized in a relative percentage of the entire Toplevel.
Now if you click on the word "Relative" in the PAGE main window, you will notice that it will change to "Absolute".
If you look at the code now, you will see a difference.
Notice that the line now contains not relx and rely, but x and y. AND that the actual x and y values are integers, not floating percentages.
So my guess it that you are trying to fight PAGE and force specific positions while in the relative mode, which you WILL loose.
If you are still not happy, please feel free to request a refund of your purchase price and I will send a request to accounting, once you provide your actual name, address, and credit card information.
T.b.h with you, you're being extremely disrespectful to the very people who give their time, to bring you (us all, in fact) the software that you're trying to use, while asking for nothing in return.
If you want some help, all you need to do is to ask for it, and Greg will reply just as soon as he can. He asks nothing of you, in exchange for his in depth knowledge and experience. In fact, I've even known him to continue to help those who don't even have the common decency to thank him, which make Greg a much better person than I.
Please think about what I've said and have some empathy: manners cost you nothing, and a little thanks, can go a long way.
You would do well to remember that "thank you" and "please" are still magical words; in fact, they just might be the two most important things that any English speaking person can say.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Believe me when I say, I understand the frustration that Mr. or Ms. Anonymous feels. It took me a long time to figure out the difference between the Absolute and Relative modes that PAGE provides. Admittedly, the placement of Widgets is a subject that can take a long time to understand. Don has attempted to document this in the PAGE help file ( /page/docs/html/use.html#relative-placement ), but it's a rather academic discussion and not designed for new users who have no clue how Tcl/Tk/Tkinter/Python/Ruby/Perl actually handles placement. AND even understanding that, as I mentioned above, there needs to be a "fudge factor" depending on the Windowing Manager that you are using. Each is different and requires a different pixel factor.
That having been said, your comments are welcome and something everyone who uses any kind of software, especially free software, needs to keep in mind when "asking for help".
Crazy Uncle Greggie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I too understand the frustration experienced when one is trying to get to grips with something as technically advanced as PAGE. It's all to easy for one to blame the Software, rather than to have to come to terms with the fact that the real issue is, that one lacks the required skills. That kind of insight requires some personnel growth, on behalf of the user, and we can only hope that this particular user, is big enough to take on board what I have said.
Once again, you've provided some valuable information, which I'm sure that every PAGE user should be thanking you for.
Last edit: Rob 2024-09-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-09-30
Sorry for venting I am just trying to make sure things line up .say I want buttons at (150, 248) (200, 248), (250, 248) (300,248) ...etc...Then one copied button refuses to line up & sits at (200, 244) & refuses to move to the same location as the others...ruining the alignment ...WHY?? Or why do all the others on both sides of it line up perfectly?? The buttons are all copies ...the only difference between them is coordinates. The screen size will never be changed.
Now if you click on the word "Relative" in the PAGE main window, you will notice that it will change to "Absolute". Notethis at the TOP of the menu (too siome time to findit)
THIS DOES NOT WORK EITHER
I changed the choice to ABSOLUTE (big button at top)
I enter button one at 22, 22
copy of button one at 142, 22 (move over by120)
next copy of button one SHOULD BE AT 262, 22 ..WHEN I TYPE IN THE XY IT GOES TO 264, 24
This just sucks, if things aren't able to be lined up...am I doing something wrong???
I have not yet generated any python, since things do not look good yet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe you should go to the Discord forum and we can talk in a private message so I can understand what is happening on your end. I've got some errands to run in a little bit, but should be available in a few hours. Look for "thedesignatedgeek1953".
It could be that if you are using the Attributes editor, you are entering the information into the relx/rely entry boxes rather than in the x/y boxes. A VERY easy mistake.
You can use the keyboard arrows to move things around if you want to "tweak" the position just a bit.
PAGE, while easy to use, can be difficult at times.
Crazy Uncle Greggie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-09-30
I found that if instead of using the present "old buttons" in ABS mode and moving them (as noted above, wrongly)...if I delete them all and make fresh copies, then THEY MOVE WHERE THEY SHOULD....why? This is a big mess, since I already have more than 50 buttons in my grid and each will need a new name and var name retyped....arrrrrrrg ...isthere a way to avoid deleteing alll of the previous work?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-09-30
There is truly something ODD with Page!!
First off, I can use the arrow keys to get the exact X& Y I want GREAT!!!!!!!!!
Thereafter if I drag it faraway and type in the xy coordinates, it goes exactly where it should.
However if I don't FIRST use the arrow keys, it does this oddball slightly off coordinates (type 187 get 184). SOMEHOW THE ARROW KEY IS "FIXING" SOMETHING
At least with the arrow keys I don't need to scrap all of my buttons--thanks!!!!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I still suggest that you take advantage of the PAGE Discord forum. Being the guy that set the thing up, I can use a voice/video channel and (assuming you have a microphone) we can chat and share our screens so you can show me what the issue is and I can show you how you might want to handle it.
By the way, 50+ buttons, while doable in PAGE is really pushing the limit.
There are ways around dealing with that, but it takes A LOT of time, pre-planning and coding.
Crazy Uncle Greggie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-09-30
what the issue is and I can show you how you might want to handle it. I've already said it...when you type in x or y the value IMMEDATELY changes to something else ...type in say 204 and it changes to maybe 207, rejecting 204. But the copy of the button next to it accepts it fine...this is even AFTER changing PAGE's control setting from the original relative to absolute mode. Also the grid pref is set to 1.
But if you use the arrows to set it, then it will accept the numbers correctly even if you move the button far away, the numbers will bring it right back exactly. Why is this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I've never seen this happen, and as far as I know you are the only one that it is happening to.
I have PAGE working on a Linux PC as well as Windows 10 and Windows 11.
No one else has even suggested that this is an issue.
I think you might want to reset the grid preference back to 10, which is the default. Many years ago, I did see that when the grid pref was set to such a low value (even at 3-7) there were issues, but I don't remember what the issues were.
Sorry.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do have a conference call with Don tomorrow and I know that he monitors this forum fairly closely. I'll make sure that this is brought up and see if he can remember if there were any reports of this that I'm not aware of. In addition, he does have a Mac, so he could check that to see if it might be an issue on that platform.
If I find anything, I'll be sure to let you know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
open it (using page ver 8) it i s set to ABSolute method
look at button zero Y value it is 14
look at button one Y value ...it is not lined up with button zero, since its Y value is 16
Type in 14 for the Y value so it will match button zero...IT CHANGES RIGHT BACK TO 16, IGNORING YOUR ENTRY
WHY??????????????????????????????????
However then use the arrow keys to move it exactly to 14
Then change Y to move it far away
Now change Y to 14 and it goes exactly back to 14 ...Why does it now work??????????????
There is obviously some problem with Page
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since this is a newly found issue (thank you again), I'm in the process of a workaround that, while not solving the issue, will allow for the user to align widgets fairly quickly.
Please check back in an hour or so.
Crazy Uncle Greggie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is NOT a fix, but simply a way to quickly align a number of widgets using the existing Multiselect function of PAGE.
In the zip file is the original .tcl issue file, a version of the fixed file, a number of screen captures and a PDF file explaining how to use the Multiselect/Context menu.
I sincerely hope this helps, at least in the sort term.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-10-01
Thanks Greg, I'll give a shot.. I'm mostly ok now knowing you can use the arrow buttons to fine to exact position rather thn typing numbers. I spent hours and hours and hours typing values, only to get wavy rows or columns of buttons ...maybe 5 in a row would be fines, then the 6th wouldn't position as expected, or they were good horz, but then were wavy columnwise. All that typing for nothing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
and so on. The second pararmeter is the number of the button or some other information you might want to pass.
Again, it was probably in the early development stage when the positioning problem raised it's ugly head.
Just a thought.
Crazy Uncle Greggie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-10-01
I noticed there seems to be this hidden delta. Type in 14 get 16,type in 20 get 22, type in 100 get 102. But the delta is not always 2 , could be 3, maybe others. I realize now I could have accounted for that oddball when typing my values....except SOME buttons do take the value exactly ...some do, some don't. As soon as you use the arrow keys on a button,the delta becomes zero!!!!! YAY!!! Why?????????????
Maybe some of my buttons got arrowed, without me noticing...so they go exactly where I type, but other don't. I suppose a program workaround would be if a value gets typed,the item gets arrowed 1 step , then the typed value is applied, the user would never see it happen. What is the arrow key wiping out that makes typed values start working??
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-10-01
Hi Greg: The program lambda has been working for a long time, This example was something I whittled down for you.
It uses some calls to extract the button's letter...so every call is the same
def cb_capt_keypad(p1):
try:
print("cb_keypad click")
if not root == root.focus_get():
** thekey = p1.widget.cget("text")
** if thekey=="MISC": return
print("key now: ", thekey)
theKeyState = p1.widget.cget("state")
print("keystate:", theKeyState)
wid = root.focus_get()
if thekey=='.' and '.' in wid.get():return
So I don't need to manually worry to pass anything, it is passing it's own lettering . So if you press button A, thekey is "A" , if you press button 8 the key is "8" , etc. I also look at state, such as double click ,released, disabled (grayed out) whatever they are.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-10-01
The .cget("desired parameter") seems handy to get any aspect of the button object---its text, its bg color, repeat rate, whatever you want. You can also set the parameter which I do in some cases (such as to disable a button under program control). This was my first tkinter program & first page program, so it might have some wackiness!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-10-02
Did anyone figure out what the problem is? Did Don have any inkling? Again, entering a coordinate should use THAT coordinate, not override and change it to some other numbers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What the HELL is wrong with page???? I need to position some items exactly. I type in the EXACT COORDINTATE I NEED BUT PAGE REFUSES IT AND CHANGES IT for example i need a button at X=203, y=674 but page changes my entries to something else, say 208 and 672, or some bs. I tried setting the grid in preferences to 1 , but no difference. Is page ver 8 positioning really this crappy??? I DON'TWANT PAGE TO CHANGE THE COORDINATES I PROVIDE
Ok. I'm going to put on my teacher sweater and tennis shoes, like Mr. Rogers and give you a BUNCH of information first. I'm fairly certain you don't know the background and underlying "science" behind the issue you are having. Please read all of the information that I am going to provide and then I'll provide what I think the issue is that you are dealing with and how to "work around it".
First, let me say that yes, there are some positioning issues in PAGE, but this is partially due to Tcl/Tk and partially due to the various windowing managers of the Operating systems that PAGE (and Tcl/Tk) don't have any control over. PAGE supports Windows 7, 8 (if you can find them), 10 and 11, Mac Os X and Linux. Linux has many windowing managers like Gnome, Mate, Cinnamon, XFCE, just plain X11 and not Wayland is thrown into the mix and brings it's own issues for PAGE to try to handle. Each of the Windowing managers have their own quirks and problems.
PAGE is built around the Tcl/Tk Toolkit. Tk was build to ONLY be used on X11 Windowing manager systems (i.e. Unix/Linux). However, the Tcl/Tk group worked very hard to support the Microsoft Windows and the Mac Windowing managers. Not an easy task.
Secondly, I too have been frustrated over the 10+ years that I have been using PAGE. In order to have a button to appear centred (British spelling) within in a frame, I usually need to use a "fudge factor" of 2 or three pixels. It's something I've gotten used to.
So I can understand your frustration, but will ask that you moderate your language. This is a "Rated PG" forum and this WILL continue to be such.
PAGE uses the PLACE geometry manager system within in Tk (Tkinter). There are two other geometry managers within Tk which are PACK and GRID. Each of the three have their own good points and bad points. If you were to use Pack or Grid, you would have almost no control over the placement and/or size of individual widgets within a toplevel form.
To use the Place geometry manager under Python/Tkinter/Tk/Ruby/Perl uses a syntax (depending on the widget) of something like this.
widget.place(x,y,height,width)(actually height and width can be swapped if you use the parameter names, but we'll stick with the above example.)
Now, if you take a look at the GUI code from an example from PAGE of a simple button placed on an empty Toplevel form, you will see something like this...
The second line is the important one. I'm guessing that if you look at your GUI.py file you will see the same thing.
Instead of a X and Y position, you will see the relx and rely parameter names instead of the more logical straight x and y position parameter names.
(We are getting close to the reason and my attempt at a fix for you now. Hold on.)
Now if you look at your PAGE Main window, you will probably find that in the lower right of the window the word "Relative" . This means that if you (or your user) resize the Toplevel form during runtime, the widgets (at least most of them) will grow and resize along with the form. All the widgets are place and sized in a relative percentage of the entire Toplevel.
Now if you click on the word "Relative" in the PAGE main window, you will notice that it will change to "Absolute".
If you look at the code now, you will see a difference.
Notice that the line now contains not relx and rely, but x and y. AND that the actual x and y values are integers, not floating percentages.
So my guess it that you are trying to fight PAGE and force specific positions while in the relative mode, which you WILL loose.
If you are still not happy, please feel free to request a refund of your purchase price and I will send a request to accounting, once you provide your actual name, address, and credit card information.
...
Oh wait. PAGE is free.
Nevermind.
If you would like to take this to our Discord forum, please use the following link...
https://discord.gg/vm6mTt9FDZ
Of course, you will need to create an account to use Discord.
Crazy Uncle Greggie
T.b.h with you, you're being extremely disrespectful to the very people who give their time, to bring you (us all, in fact) the software that you're trying to use, while asking for nothing in return.
If you want some help, all you need to do is to ask for it, and Greg will reply just as soon as he can. He asks nothing of you, in exchange for his in depth knowledge and experience. In fact, I've even known him to continue to help those who don't even have the common decency to thank him, which make Greg a much better person than I.
Please think about what I've said and have some empathy: manners cost you nothing, and a little thanks, can go a long way.
You would do well to remember that "thank you" and "please" are still magical words; in fact, they just might be the two most important things that any English speaking person can say.
THANK YOU, Rob.
Believe me when I say, I understand the frustration that Mr. or Ms. Anonymous feels. It took me a long time to figure out the difference between the Absolute and Relative modes that PAGE provides. Admittedly, the placement of Widgets is a subject that can take a long time to understand. Don has attempted to document this in the PAGE help file ( /page/docs/html/use.html#relative-placement ), but it's a rather academic discussion and not designed for new users who have no clue how Tcl/Tk/Tkinter/Python/Ruby/Perl actually handles placement. AND even understanding that, as I mentioned above, there needs to be a "fudge factor" depending on the Windowing Manager that you are using. Each is different and requires a different pixel factor.
That having been said, your comments are welcome and something everyone who uses any kind of software, especially free software, needs to keep in mind when "asking for help".
Crazy Uncle Greggie
You are very welcome, Greg, and thank you.
I too understand the frustration experienced when one is trying to get to grips with something as technically advanced as PAGE. It's all to easy for one to blame the Software, rather than to have to come to terms with the fact that the real issue is, that one lacks the required skills. That kind of insight requires some personnel growth, on behalf of the user, and we can only hope that this particular user, is big enough to take on board what I have said.
Once again, you've provided some valuable information, which I'm sure that every PAGE user should be thanking you for.
Last edit: Rob 2024-09-30
Sorry for venting I am just trying to make sure things line up .say I want buttons at (150, 248) (200, 248), (250, 248) (300,248) ...etc...Then one copied button refuses to line up & sits at (200, 244) & refuses to move to the same location as the others...ruining the alignment ...WHY?? Or why do all the others on both sides of it line up perfectly?? The buttons are all copies ...the only difference between them is coordinates. The screen size will never be changed.
Now if you click on the word "Relative" in the PAGE main window, you will notice that it will change to "Absolute". Notethis at the TOP of the menu (too siome time to findit)
THIS DOES NOT WORK EITHER
I changed the choice to ABSOLUTE (big button at top)
I enter button one at 22, 22
copy of button one at 142, 22 (move over by120)
next copy of button one SHOULD BE AT 262, 22 ..WHEN I TYPE IN THE XY IT GOES TO 264, 24
This just sucks, if things aren't able to be lined up...am I doing something wrong???
I have not yet generated any python, since things do not look good yet.
I'm not sure what is going "wrong".
Maybe you should go to the Discord forum and we can talk in a private message so I can understand what is happening on your end. I've got some errands to run in a little bit, but should be available in a few hours. Look for "thedesignatedgeek1953".
It could be that if you are using the Attributes editor, you are entering the information into the relx/rely entry boxes rather than in the x/y boxes. A VERY easy mistake.
You can use the keyboard arrows to move things around if you want to "tweak" the position just a bit.
PAGE, while easy to use, can be difficult at times.
Crazy Uncle Greggie
I found that if instead of using the present "old buttons" in ABS mode and moving them (as noted above, wrongly)...if I delete them all and make fresh copies, then THEY MOVE WHERE THEY SHOULD....why? This is a big mess, since I already have more than 50 buttons in my grid and each will need a new name and var name retyped....arrrrrrrg ...isthere a way to avoid deleteing alll of the previous work?
There is truly something ODD with Page!!
First off, I can use the arrow keys to get the exact X& Y I want GREAT!!!!!!!!!
Thereafter if I drag it faraway and type in the xy coordinates, it goes exactly where it should.
However if I don't FIRST use the arrow keys, it does this oddball slightly off coordinates (type 187 get 184). SOMEHOW THE ARROW KEY IS "FIXING" SOMETHING
At least with the arrow keys I don't need to scrap all of my buttons--thanks!!!!!
Well, I'm glad that you got it somewhat working.
I still suggest that you take advantage of the PAGE Discord forum. Being the guy that set the thing up, I can use a voice/video channel and (assuming you have a microphone) we can chat and share our screens so you can show me what the issue is and I can show you how you might want to handle it.
By the way, 50+ buttons, while doable in PAGE is really pushing the limit.
There are ways around dealing with that, but it takes A LOT of time, pre-planning and coding.
Crazy Uncle Greggie
what the issue is and I can show you how you might want to handle it. I've already said it...when you type in x or y the value IMMEDATELY changes to something else ...type in say 204 and it changes to maybe 207, rejecting 204. But the copy of the button next to it accepts it fine...this is even AFTER changing PAGE's control setting from the original relative to absolute mode. Also the grid pref is set to 1.
But if you use the arrows to set it, then it will accept the numbers correctly even if you move the button far away, the numbers will bring it right back exactly. Why is this?
Well, I've never seen this happen, and as far as I know you are the only one that it is happening to.
I have PAGE working on a Linux PC as well as Windows 10 and Windows 11.
No one else has even suggested that this is an issue.
I think you might want to reset the grid preference back to 10, which is the default. Many years ago, I did see that when the grid pref was set to such a low value (even at 3-7) there were issues, but I don't remember what the issues were.
Sorry.
I do have a conference call with Don tomorrow and I know that he monitors this forum fairly closely. I'll make sure that this is brought up and see if he can remember if there were any reports of this that I'm not aware of. In addition, he does have a Mac, so he could check that to see if it might be an issue on that platform.
If I find anything, I'll be sure to let you know.
Here is a problem.tcl
https://www.dropbox.com/scl/fi/mopoewj8qbwqmw66sxu6r/problem.tcl?rlkey=q1rbhwpy1dl850gtkad89e6wx&dl=0
open it (using page ver 8) it i s set to ABSolute method
look at button zero Y value it is 14
look at button one Y value ...it is not lined up with button zero, since its Y value is 16
Type in 14 for the Y value so it will match button zero...IT CHANGES RIGHT BACK TO 16, IGNORING YOUR ENTRY
WHY??????????????????????????????????
However then use the arrow keys to move it exactly to 14
Then change Y to move it far away
Now change Y to 14 and it goes exactly back to 14 ...Why does it now work??????????????
There is obviously some problem with Page
Very interesting.
Yes, I see what you are saying.
I'll bring it up to Don on tomorrow's call.
Thank you
Since this is a newly found issue (thank you again), I'm in the process of a workaround that, while not solving the issue, will allow for the user to align widgets fairly quickly.
Please check back in an hour or so.
Crazy Uncle Greggie
Please download the "workaround.zip" file.
This is NOT a fix, but simply a way to quickly align a number of widgets using the existing Multiselect function of PAGE.
In the zip file is the original .tcl issue file, a version of the fixed file, a number of screen captures and a PDF file explaining how to use the Multiselect/Context menu.
I sincerely hope this helps, at least in the sort term.
Crazy Uncle Greggie
Thanks Greg, I'll give a shot.. I'm mostly ok now knowing you can use the arrow buttons to fine to exact position rather thn typing numbers. I spent hours and hours and hours typing values, only to get wavy rows or columns of buttons ...maybe 5 in a row would be fines, then the 6th wouldn't position as expected, or they were good horz, but then were wavy columnwise. All that typing for nothing.
I'm just glad that we've finally on a road to getting this figured out and fixed.
I do have an observation.
In your problem demonstration file, I noticed that for almost all of your buttons, you use bind instead of command.
While the bind command is pretty much the command on steroids, your setting to the callback function for all the "numbered" buttons is the same...
lambda e:problem_support.cb_capt_keypad(e)
I'm guessing that the idea behind using the lambda support for the callback is to be able to know what button raised the event.
I'm sure you were just in the middle of your design when you found the positioning problem, but your solution, as it stands won't work.
As it stands, when your callback fires the input to it will return
problem_support.cb_capt_keypad
another arg: <buttonpress event="" state="Mod2" num="1" x="35" y="36">
problem_support.cb_capt_keypad
another arg: <buttonpress event="" state="Mod2" num="1" x="67" y="56"></buttonpress></buttonpress>
It would be better to use...
and so on. The second pararmeter is the number of the button or some other information you might want to pass.
Again, it was probably in the early development stage when the positioning problem raised it's ugly head.
Just a thought.
Crazy Uncle Greggie
I noticed there seems to be this hidden delta. Type in 14 get 16,type in 20 get 22, type in 100 get 102. But the delta is not always 2 , could be 3, maybe others. I realize now I could have accounted for that oddball when typing my values....except SOME buttons do take the value exactly ...some do, some don't. As soon as you use the arrow keys on a button,the delta becomes zero!!!!! YAY!!! Why?????????????
Maybe some of my buttons got arrowed, without me noticing...so they go exactly where I type, but other don't. I suppose a program workaround would be if a value gets typed,the item gets arrowed 1 step , then the typed value is applied, the user would never see it happen. What is the arrow key wiping out that makes typed values start working??
Hi Greg: The program lambda has been working for a long time, This example was something I whittled down for you.
It uses some calls to extract the button's letter...so every call is the same
So I don't need to manually worry to pass anything, it is passing it's own lettering . So if you press button A, thekey is "A" , if you press button 8 the key is "8" , etc. I also look at state, such as double click ,released, disabled (grayed out) whatever they are.
Ahhh. Ok.
The .cget("desired parameter") seems handy to get any aspect of the button object---its text, its bg color, repeat rate, whatever you want. You can also set the parameter which I do in some cases (such as to disable a button under program control). This was my first tkinter program & first page program, so it might have some wackiness!
Did anyone figure out what the problem is? Did Don have any inkling? Again, entering a coordinate should use THAT coordinate, not override and change it to some other numbers.