Reputation: 125
I read documentation but I am still unable to guess the correct strategy because I don't find "high level" documentation that could help so I reuse stuff without knowing if it is the correct strategy.
I need to create a windows that has a scrollbar (x and y) because content of the windows is a checkbox list that could contains hundred of elements.
I need this windows to be a blocking windows (other windows and process need to be stopped as this windows is here). this is why first I had a dialog box but I can't add a scrollbar on it.
then I discovered it is not possible to add a scrollbar on a dialog box so I have now this kind of windows :
one frame that contains a canva that contain one frame for the check button list and another frame for the buttons (ok, cancel, etc.)
in brief :
$w.frAlles.c.frSimu => upper frame that will be huge $w.frAlles.c.frButtons => botton frame
the scrollbar is ok, but as I need to place each frame in the canva with :
$w.frAlles.c create window 0 0 -anchor nw -window $w.frAlles.c.frSimu
$w.frAlles.c create window 200 650 -anchor c -window $w.frAlles.c.frButtons
Then, the size of each frame is limited because second frame frButtons will be placed at 200/650 and frSimu won't be able to be as long as possible.
is there a way to configure the frames so that frSimu is upper the frButtons or frSimu to be left and frButtons to be right but without precising the exact place because size of frSimu could be huge ?
for instance now I have :
optional question : is there a way to have this existing windows to be a "blocking one" meaning that user can't do anything as long as the user don't close this windows ?
optionnal question 2 : is my GUi strategy correct ? I mean the usage of one frame, that contains one canva and then 2 frames... is it "smart" ? or is there a clever way ?
Upvotes: 0
Views: 41
Reputation: 137797
I'm not 100% sure what you mean by "blocking", but the answer likely involves grab
or, maybe, tk busy
. Be very careful with global grabs; you can lock yourself out of your user session with them if you don't get the unlock right. (Local grabs and busy windows don't pose such a risk; breaking your own program is just an irritant.) Also note that the overall window manager might not let you get a true global grab; Tk can ask for one but can't force the request to be granted.
Making the checkbuttons be (indirectly) managed children of a canvas
is indeed the easiest way to make them scrollable. Whether this is a good idea for hundreds of checkbuttons... now that I have a number of concerns about. It's very easy to present too much information to users; they might think they want to see it all, but it's much more likely that they stop paying attention to most of it.
What to use instead?
I can't remember if a ttk::treeview
can contain checkbutton
children. Maybe you'd be better looking at the power of the tktable or tktreectrl extensions; I've never done much with either so can't guide you, but tktreectrl has examples that include the capability so it's definitely possible there.
Upvotes: 0