TCL(Tool Command Language) Scripting :: Add frame(s) to existing window?


	Add frame(s) to existing window? I currently invoke a window with a set of radio buttons to select a project, a text widget to enter a name and a set of checkbuttons to add properties to a file. So far so good. However, the file to which I want to add properties, may already have some added from an earlier run of my script, so I want to grey out those checkbuttons with -state disabled. This gives me a catch 22 situation because the project radio button & text widget are needed to point to the file to which the properties are to be added. So, I would like to declare the project & label as " " or something like that, and then test them to ensure I have a valid radio selection and text widget; this would then allow a action button to be pressed which then reads the file to discover which properties are already set; this would then add more frame(s) to the window (if is this possible), with the checkbutton choices, but with already selected ones greyed out. Can all this be done, or do I need to invoke another subsiduary window? TIA, Niv. On 21 May 2007 07:17:00 -0700, Niv <kev.pars@mbda.co.uk> wrote: - Hide quoted text - >I currently invoke a window with a set of radio buttons to select a >project, a text widget to enter a name and a set of checkbuttons to >add properties to a file. So far so good. >However, the file to which I want to add properties, may already have >some added from an earlier run of my script, so I want to grey out >those checkbuttons with -state disabled. >This gives me a catch 22 situation because the project radio button & >text widget are needed to point to the file to which the properties >are to be added. >So, I would like to declare the project & label as " " or something >like that, and then test them to ensure I have a valid radio selection >and text widget; this would then allow a action button to be pressed >which then reads the file to discover which properties are already >set; this would then add more frame(s) to the window (if is this >possible), with the checkbutton choices, but with already selected >ones greyed out. >Can all this be done, or do I need to invoke another subsiduary >window? >TIA, Niv. This can certainly be done. A small example of a button that will create a new frame is shown below. In general Tk widgets can be created (text, label, frame etc), shown (pack, grid and place), hidden (pack forget, grid forget etc) and destroyed (destroy $widget) dynamically. Mark proc createFrame {} { frame .f text .f.t pack .f pack .f.t .b configure -state disabled } button .b -text "create frame" -command createFrame pack .b On 22 May, 14:22, Mark Janssen <mpc.jans@gmail.com> wrote: - Hide quoted text - > On 21 May 2007 07:17:00 -0700, Niv <kev.pars@mbda.co.uk> wrote: > >I currently invoke a window with a set of radio buttons to select a > >project, a text widget to enter a name and a set of checkbuttons to > >add properties to a file. So far so good. > >However, the file to which I want to add properties, may already have > >some added from an earlier run of my script, so I want to grey out > >those checkbuttons with -state disabled. > >This gives me a catch 22 situation because the project radio button & > >text widget are needed to point to the file to which the properties > >are to be added. > >So, I would like to declare the project & label as " " or something > >like that, and then test them to ensure I have a valid radio selection > >and text widget; this would then allow a action button to be pressed > >which then reads the file to discover which properties are already > >set; this would then add more frame(s) to the window (if is this > >possible), with the checkbutton choices, but with already selected > >ones greyed out. > >Can all this be done, or do I need to invoke another subsiduary > >window? > >TIA, Niv. > This can certainly be done. A small example of a button that will > create a new frame is shown below. In general Tk widgets can be > created (text, label, frame etc), shown (pack, grid and place), hidden > (pack forget, grid forget etc) and destroyed (destroy $widget) > dynamically. > Mark > proc createFrame {} { > frame .f > text .f.t > pack .f > pack .f.t > .b configure -state disabled > } > button .b -text "create frame" -command createFrame > pack .b- Hide quoted text - > That sort of makes sense, however, what I'm trying to do (and failing miserably) is to open a new window with a button, (which works OK), this new window has a set of radio buttons and text entry widget, and another button, say "X", (there are other buttons to return or quit). Now pressing "X" tests that a radiobutton is selected, the text entry is not empty, AND the radio button and text entered map to an existing file, (this all works so far); assuming this all passes, I then want to remove the radio buttons & txt entry widget, rename the "X" button and give it a different command, and finally add in a new set of check buttons (possibly several sets). The bit I'm struggling with is modifying the existing window so it re- maps button "X" with new text and new associated command. TIA, Niv (Kev Parsons). On May 24, 2:05 pm, Niv <kev.pars@mbda.co.uk> wrote: - Hide quoted text - > On 22 May, 14:22, Mark Janssen <mpc.jans@gmail.com> wrote: > > On 21 May 2007 07:17:00 -0700, Niv <kev.pars@mbda.co.uk> wrote: > > >I currently invoke a window with a set of radio buttons to select a > > >project, a text widget to enter a name and a set of checkbuttons to > > >add properties to a file. So far so good. > > >However, the file to which I want to add properties, may already have > > >some added from an earlier run of my script, so I want to grey out > > >those checkbuttons with -state disabled. > > >This gives me a catch 22 situation because the project radio button & > > >text widget are needed to point to the file to which the properties > > >are to be added. > > >So, I would like to declare the project & label as " " or something > > >like that, and then test them to ensure I have a valid radio selection > > >and text widget; this would then allow a action button to be pressed > > >which then reads the file to discover which properties are already > > >set; this would then add more frame(s) to the window (if is this > > >possible), with the checkbutton choices, but with already selected > > >ones greyed out. > > >Can all this be done, or do I need to invoke another subsiduary > > >window? > > >TIA, Niv. > > This can certainly be done. A small example of a button that will > > create a new frame is shown below. In general Tk widgets can be > > created (text, label, frame etc), shown (pack, grid and place), hidden > > (pack forget, grid forget etc) and destroyed (destroy $widget) > > dynamically. > > Mark > > proc createFrame {} { > > frame .f > > text .f.t > > pack .f > > pack .f.t > > .b configure -state disabled > > } > > button .b -text "create frame" -command createFrame > > pack .b- Hide quoted text - > > > That sort of makes sense, however, what I'm trying to do (and failing > miserably) is to open a new window with a button, (which works OK), > this new window has a set of radio buttons and text entry widget, and > another button, say "X", (there are other buttons to return or quit). > Now pressing "X" tests that a radiobutton is selected, the text entry > is not empty, AND the radio button and text entered map to an existing > file, (this all works so far); assuming this all passes, I then want > to remove the radio buttons & txt entry widget, rename the "X" button > and give it a different command, and finally add in a new set of check > buttons (possibly several sets). > The bit I'm struggling with is modifying the existing window so it re- > maps button "X" with new text and new associated command. > TIA, Niv (Kev Parsons).- Hide quoted text - > You don't have to remap the button to change the text or command. Instead you can use (assumming .b is the X button) .b configure -text $newText -command $newCommand Mark - Hide quoted text - Niv wrote: > On 22 May, 14:22, Mark Janssen <mpc.jans@gmail.com> wrote: >> On 21 May 2007 07:17:00 -0700, Niv <kev.pars@mbda.co.uk> wrote: >>> I currently invoke a window with a set of radio buttons to select a >>> project, a text widget to enter a name and a set of checkbuttons to >>> add properties to a file. So far so good. >>> However, the file to which I want to add properties, may already have >>> some added from an earlier run of my script, so I want to grey out >>> those checkbuttons with -state disabled. >>> This gives me a catch 22 situation because the project radio button & >>> text widget are needed to point to the file to which the properties >>> are to be added. >>> So, I would like to declare the project & label as " " or something >>> like that, and then test them to ensure I have a valid radio selection >>> and text widget; this would then allow a action button to be pressed >>> which then reads the file to discover which properties are already >>> set; this would then add more frame(s) to the window (if is this >>> possible), with the checkbutton choices, but with already selected >>> ones greyed out. >>> Can all this be done, or do I need to invoke another subsiduary >>> window? >>> TIA, Niv. >> This can certainly be done. A small example of a button that will >> create a new frame is shown below. In general Tk widgets can be >> created (text, label, frame etc), shown (pack, grid and place), hidden >> (pack forget, grid forget etc) and destroyed (destroy $widget) >> dynamically. >> Mark >> proc createFrame {} { >> frame .f >> text .f.t >> pack .f >> pack .f.t >> .b configure -state disabled >> } >> button .b -text "create frame" -command createFrame >> pack .b- Hide quoted text - >> > That sort of makes sense, however, what I'm trying to do (and failing > miserably) is to open a new window with a button, (which works OK), > this new window has a set of radio buttons and text entry widget, and > another button, say "X", (there are other buttons to return or quit). > Now pressing "X" tests that a radiobutton is selected, the text entry > is not empty, AND the radio button and text entered map to an existing > file, (this all works so far); assuming this all passes, I then want > to remove the radio buttons & txt entry widget, rename the "X" button > and give it a different command, and finally add in a new set of check > buttons (possibly several sets). > The bit I'm struggling with is modifying the existing window so it re- > maps button "X" with new text and new associated command. > TIA, Niv (Kev Parsons). You don't need to rename a widget (nor is that even possible). There are a couple of easy solutions. One, simply reconfigure the button: .xbutton configure -text "new Label" -command "newCommand" The second, which I personally think is better, is to have two buttons. Then, unmap one and map the other: button .b1 -text "Button 1" -command "command1" button .b2 -text "Button 2" -command "command2" ... if {$someCondition} { grid remove .b1 grid .b2 } It's a tiny bit more complicated than that, but that's the gist. You can grid two widgets in the same place, then "grid remove" one or the other and it will remember where to go when you re-grid it. Of course, if they are both the same size and both in the same place you can simply raise one over the other. We can give a more specific example if you wish, but I recommend you give it a try yourself first. -- Bryan Oakley http://www.tclscripting.com On 24 May, 17:42, Bryan Oakley <oak@bardo.clearlight.com> wrote: - Hide quoted text - > Niv wrote: > > On 22 May, 14:22, Mark Janssen <mpc.jans@gmail.com> wrote: > >> On 21 May 2007 07:17:00 -0700, Niv <kev.pars@mbda.co.uk> wrote: > >>> I currently invoke a window with a set of radio buttons to select a > >>> project, a text widget to enter a name and a set of checkbuttons to > >>> add properties to a file. So far so good. > >>> However, the file to which I want to add properties, may already have > >>> some added from an earlier run of my script, so I want to grey out > >>> those checkbuttons with -state disabled. > >>> This gives me a catch 22 situation because the project radio button & > >>> text widget are needed to point to the file to which the properties > >>> are to be added. > >>> So, I would like to declare the project & label as " " or something > >>> like that, and then test them to ensure I have a valid radio selection > >>> and text widget; this would then allow a action button to be pressed > >>> which then reads the file to discover which properties are already > >>> set; this would then add more frame(s) to the window (if is this > >>> possible), with the checkbutton choices, but with already selected > >>> ones greyed out. > >>> Can all this be done, or do I need to invoke another subsiduary > >>> window? > >>> TIA, Niv. > >> This can certainly be done. A small example of a button that will > >> create a new frame is shown below. In general Tk widgets can be > >> created (text, label, frame etc), shown (pack, grid and place), hidden > >> (pack forget, grid forget etc) and destroyed (destroy $widget) > >> dynamically. > >> Mark > >> proc createFrame {} { > >> frame .f > >> text .f.t > >> pack .f > >> pack .f.t > >> .b configure -state disabled > >> } > >> button .b -text "create frame" -command createFrame > >> pack .b- Hide quoted text - > >> > > That sort of makes sense, however, what I'm trying to do (and failing > > miserably) is to open a new window with a button, (which works OK), > > this new window has a set of radio buttons and text entry widget, and > > another button, say "X", (there are other buttons to return or quit). > > Now pressing "X" tests that a radiobutton is selected, the text entry > > is not empty, AND the radio button and text entered map to an existing > > file, (this all works so far); assuming this all passes, I then want > > to remove the radio buttons & txt entry widget, rename the "X" button > > and give it a different command, and finally add in a new set of check > > buttons (possibly several sets). > > The bit I'm struggling with is modifying the existing window so it re- > > maps button "X" with new text and new associated command. > > TIA, Niv (Kev Parsons). > You don't need to rename a widget (nor is that even possible). There are > a couple of easy solutions. > One, simply reconfigure the button: > .xbutton configure -text "new Label" -command "newCommand" > The second, which I personally think is better, is to have two buttons. > Then, unmap one and map the other: > button .b1 -text "Button 1" -command "command1" > button .b2 -text "Button 2" -command "command2" > ... > if {$someCondition} { > grid remove .b1 > grid .b2 > } > It's a tiny bit more complicated than that, but that's the gist. You can > grid two widgets in the same place, then "grid remove" one or the other > and it will remember where to go when you re-grid it. > Of course, if they are both the same size and both in the same place you > can simply raise one over the other. > We can give a more specific example if you wish, but I recommend you > give it a try yourself first. > -- > Bryan Oakleyhttp://www.tclscripting.com- Hide quoted text - > Thanks a lot Brian, I'll give it a whirl and see how I get on. Kev P. - Hide quoted text - Bryan Oakley wrote: > Niv wrote: >> On 22 May, 14:22, Mark Janssen <mpc.jans@gmail.com> wrote: >>> On 21 May 2007 07:17:00 -0700, Niv <kev.pars@mbda.co.uk> wrote: >>>> I currently invoke a window with a set of radio buttons to select a >>>> project, a text widget to enter a name and a set of checkbuttons to >>>> add properties to a file. So far so good. >>>> However, the file to which I want to add properties, may already have >>>> some added from an earlier run of my script, so I want to grey out >>>> those checkbuttons with -state disabled. >>>> This gives me a catch 22 situation because the project radio button & >>>> text widget are needed to point to the file to which the properties >>>> are to be added. >>>> So, I would like to declare the project & label as " " or something >>>> like that, and then test them to ensure I have a valid radio selection >>>> and text widget; this would then allow a action button to be pressed >>>> which then reads the file to discover which properties are already >>>> set; this would then add more frame(s) to the window (if is this >>>> possible), with the checkbutton choices, but with already selected >>>> ones greyed out. >>>> Can all this be done, or do I need to invoke another subsiduary >>>> window? >>>> TIA, Niv. >>> This can certainly be done. A small example of a button that will >>> create a new frame is shown below. In general Tk widgets can be >>> created (text, label, frame etc), shown (pack, grid and place), hidden >>> (pack forget, grid forget etc) and destroyed (destroy $widget) >>> dynamically. >>> Mark >>> proc createFrame {} { >>> frame .f >>> text .f.t >>> pack .f >>> pack .f.t >>> .b configure -state disabled >>> } >>> button .b -text "create frame" -command createFrame >>> pack .b- Hide quoted text - >>> >> That sort of makes sense, however, what I'm trying to do (and failing >> miserably) is to open a new window with a button, (which works OK), >> this new window has a set of radio buttons and text entry widget, and >> another button, say "X", (there are other buttons to return or quit). >> Now pressing "X" tests that a radiobutton is selected, the text entry >> is not empty, AND the radio button and text entered map to an existing >> file, (this all works so far); assuming this all passes, I then want >> to remove the radio buttons & txt entry widget, rename the "X" button >> and give it a different command, and finally add in a new set of check >> buttons (possibly several sets). >> The bit I'm struggling with is modifying the existing window so it re- >> maps button "X" with new text and new associated command. >> TIA, Niv (Kev Parsons). > You don't need to rename a widget (nor is that even possible). There are > a couple of easy solutions. > One, simply reconfigure the button: > .xbutton configure -text "new Label" -command "newCommand" > The second, which I personally think is better, is to have two buttons. > Then, unmap one and map the other: > button .b1 -text "Button 1" -command "command1" > button .b2 -text "Button 2" -command "command2" > ... > if {$someCondition} { > grid remove .b1 > grid .b2 > } > It's a tiny bit more complicated than that, but that's the gist. You can > grid two widgets in the same place, then "grid remove" one or the other > and it will remember where to go when you re-grid it. > Of course, if they are both the same size and both in the same place you > can simply raise one over the other. > We can give a more specific example if you wish, but I recommend you > give it a try yourself first. Brian, I am curious to know why you would think the two widget approach is better. Maybe because of debugging? (one button always has the same command) Mark Mark Janssen wrote: > Bryan Oakley wrote: >> Niv wrote: <snip> > Brian, <snip> Sorry, Bryan - Hide quoted text - Mark Janssen wrote: > Bryan Oakley wrote: >> You don't need to rename a widget (nor is that even possible). There >> are a couple of easy solutions. >> One, simply reconfigure the button: >> .xbutton configure -text "new Label" -command "newCommand" >> The second, which I personally think is better, is to have two >> buttons. Then, unmap one and map the other: >>... > Brian, > I am curious to know why you would think the two widget approach is > better. Maybe because of debugging? (one button always has the same > command) I'm not sure I could describe my reasoning in a short paragraph. I just think it's cleaner to have 1 button -> 1 function. Consider a scenario where you may need to disable feature A but leave feature B. If both features share the same button you can't just do ".button configure -state disabled" because you may be disabling the wrong thing. You would have to first check which feature is tied to the button then decide whether to change the state or not. -- Bryan Oakley http://www.tclscripting.com On 24 May, 19:19, Bryan Oakley <oak@bardo.clearlight.com> wrote: - Hide quoted text - > Mark Janssen wrote: > > Bryan Oakley wrote: > >> You don't need to rename a widget (nor is that even possible). There > >> are a couple of easy solutions. > >> One, simply reconfigure the button: > >> .xbutton configure -text "new Label" -command "newCommand" > >> The second, which I personally think is better, is to have two > >> buttons. Then, unmap one and map the other: > >>... > > Brian, > > I am curious to know why you would think the two widget approach is > > better. Maybe because of debugging? (one button always has the same > > command) > I'm not sure I could describe my reasoning in a short paragraph. I just > think it's cleaner to have 1 button -> 1 function. > Consider a scenario where you may need to disable feature A but leave > feature B. If both features share the same button you can't just do > ".button configure -state disabled" because you may be disabling the > wrong thing. You would have to first check which feature is tied to the > button then decide whether to change the state or not. > -- > Bryan Oakleyhttp://www.tclscripting.com- Hide quoted text - > I'm having great difficulty getting this working completely: I have two buttons, declared as $k6.b1 & $k6.b2 (where k6 is set as follows: set k2 [frame .reuse.frm2 -bd 2 - relief groove]) The .b1 appears OK and invokes a proc which tests if a radiobutton and text-entry are a valid pair, and then, if OK, overwrites .b1 with .b2 , which works fine. However at this point I also want the proc to remove frames .k1 & .k2 which hold the radio buttons and the text-entry widgets, and place a set of already defined frames with check-buttons: k3a, k3b etc, into the window. .k1 & .k2 do disappear, but .k3a etc do not appear. Can you offer any further help please? TIA , Kev P. On 25 May, 13:05, Niv <kev.pars@mbda.co.uk> wrote: - Hide quoted text - > On 24 May, 19:19, Bryan Oakley <oak@bardo.clearlight.com> wrote: > > Mark Janssen wrote: > > > Bryan Oakley wrote: > > >> You don't need to rename a widget (nor is that even possible). There > > >> are a couple of easy solutions. > > >> One, simply reconfigure the button: > > >> .xbutton configure -text "new Label" -command "newCommand" > > >> The second, which I personally think is better, is to have two > > >> buttons. Then, unmap one and map the other: > > >>... > > > Brian, > > > I am curious to know why you would think the two widget approach is > > > better. Maybe because of debugging? (one button always has the same > > > command) > > I'm not sure I could describe my reasoning in a short paragraph. I just > > think it's cleaner to have 1 button -> 1 function. > > Consider a scenario where you may need to disable feature A but leave > > feature B. If both features share the same button you can't just do > > ".button configure -state disabled" because you may be disabling the > > wrong thing. You would have to first check which feature is tied to the > > button then decide whether to change the state or not. > > -- > > Bryan Oakleyhttp://www.tclscripting.com-Hide quoted text - > > > I'm having great difficulty getting this working completely: > I have two buttons, declared as $k6.b1 & $k6.b2 > (where k6 is set as follows: set k2 [frame .reuse.frm2 -bd 2 - > relief groove]) > The .b1 appears OK and invokes a proc which tests if a radiobutton and > text-entry are a valid pair, and then, if OK, overwrites .b1 > with .b2 , which works fine. > However at this point I also want the proc to remove frames .k1 & .k2 > which hold the radio buttons and the text-entry widgets, and place a > set of already defined frames with check-buttons: k3a, k3b etc, into > the window. .k1 & .k2 do disappear, but .k3a etc do not appear. > Can you offer any further help please? > TIA , Kev P.- Hide quoted text - > Ignore last post please. I was not placing the frames k3a, k3b etc with grid before placingthe buttons within the frame. DOH! Kev P.