Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Well known error "cannot use geometry manager pack inside ..."
255 views
Skip to first unread message
Gerhard Reithofer
Feb 12, 2012, 12:05:46 PM2/12/12
to
Hi,
I think that this topic has already been discussed and I'm afraid that
the behavior will not be changed in future versions (8.6x).
But I have now the problem, that long running code is affected.
My famous application where I was thrown back is the great editor ASED
(http://www.tcl-home.de/ased), but also several older self written
pragrams break.
Code which use pack inside grid does not fail dependable, only specific
situations end in an endless loop (I also reported such a failure many
years ago).
Even tcl tips have been refused for the sake of compatibility and a
complete turndown seems radical to me.
This refused the general upgrade to 8.6 in my projects.
I'd like to ask therefore for a migration possibility to avoid this
error - not to forget that some of my older apps, which are working for
years get this error.
Is "manual recoding" the only possibilty to circumevent this situation?
PS: Has someone ported ASED to 8.6 or ist someone working on that?
--
Gerhard Reithofer
Tech-EDV Support Forum - http://support.tech-edv.co.at
I think that this topic has already been discussed and I'm afraid that
the behavior will not be changed in future versions (8.6x).
But I have now the problem, that long running code is affected.
My famous application where I was thrown back is the great editor ASED
(http://www.tcl-home.de/ased), but also several older self written
pragrams break.
Code which use pack inside grid does not fail dependable, only specific
situations end in an endless loop (I also reported such a failure many
years ago).
Even tcl tips have been refused for the sake of compatibility and a
complete turndown seems radical to me.
This refused the general upgrade to 8.6 in my projects.
I'd like to ask therefore for a migration possibility to avoid this
error - not to forget that some of my older apps, which are working for
years get this error.
Is "manual recoding" the only possibilty to circumevent this situation?
PS: Has someone ported ASED to 8.6 or ist someone working on that?
--
Gerhard Reithofer
Tech-EDV Support Forum - http://support.tech-edv.co.at
Robert Heller
Feb 12, 2012, 3:07:36 PM2/12/12
to
container. It *sounds* like what is happening here is something in the
*application* code is using both grid and pack to managing children of
a container. It might be that some meta-widget extension has changed
and is now packing (or griding) its children and your code is also
packing/griding additional children, and your code is using the wrong
geometry manager OR is simply mis-using the meta-widget extension (eg
not using the meta-widget's code to pack/grid stuff in the
meta-widget's container or attempting to re-pack/re-grid children that
have already been grided/packed). All of these cases imply that there
are real live bugs in *your* application code and the problem is NOT a
problem with Tcl/Tk, other than maybe Tcl/Tk is now catching bugs it
failed to catch before.
>
--
Robert Heller -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software -- http://www.deepsoft.com/
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
Schelte Bron
Feb 12, 2012, 4:42:47 PM2/12/12
to
Robert Heller wrote:
> It is a coding error to use more than one geometry manager in any
> given container.
This statement is false. There are definitly proper uses of more
> It is a coding error to use more than one geometry manager in any
> given container.
than one geometry manager in a single container. For example, to
make a toplevel window that matches the ttk style I usually place a
ttk::frame in the toplevel and subsequently grid other widgets in
the toplevel. This works perfectly. And there is no reason why the
same thing couldn't be done with pack instead of place.
It is however a coding error to have two geometry managers dictate
the size of the master at the same time. But if you switch off
propagation for one of the managers, it is no problem to use both
pack and grid in the same container. So this works (even in Tk 8.6):
pack propagate . 0
pack [ttk::frame .bg] -fill both -expand 1
grid [ttk::label .l -text "Hello World"] -padx 20 -pady 20
Without seeing the code, the fact that the OP had some code in an
older Tk version that did not freeze the display suggests that this
is what the code was doing all along, but probaly not in that order.
Propagation only kicks in when the event loop is allowed to run. So
in the older Tk it was possible to first grid and pack widgets and
then turn off propagation. Tk 8.6 will produce the error mentioned
in the subject before the code gets to the statement that turns off
propagation.
If my understanding of the problem is correct, the simple fix will
be to find the [grid propagate 0] or [pack propagate 0] commands and
move them up a few lines.
Schelte.
Emiliano
Feb 12, 2012, 4:55:57 PM2/12/12
to
On 12 feb, 14:05, Gerhard Reithofer <gerhard.reitho...@tech-edv.co.at>
wrote:
>
> My famous application where I was thrown back is the great editor ASED
> (http://www.tcl-home.de/ased), but also several older self written
> pragrams break.
ASED can be fixed commenting out the two offending [pack]s.
> Code which use pack inside grid does not fail dependable, only specific
> situations end in an endless loop (I also reported such a failure many
> years ago).
> Even tcl tips have been refused for the sake of compatibility and a
> complete turndown seems radical to me.
>
> This refused the general upgrade to 8.6 in my projects.
>
> I'd like to ask therefore for a migration possibility to avoid this
> error - not to forget that some of my older apps, which are working for
> years get this error.
> Is "manual recoding" the only possibilty to circumevent this situation?
>
> PS: Has someone ported ASED to 8.6 or ist someone working on that?
Most affected code I've seen so far is due to a misuse of
Bwidget's ScrolledWindow. The code is supposed to create a child of
the
SW and use the setwidget method to map the managed window. But ASED
(and other software I've seen in the wild) also tries to [pack] the
child, which is a bug.
As stated above, ASED can be made to work commenting out the two
[pack]s
that breaks on 8.6.
There are other problems with the bundled tools (tkcon and tkdiff).
Both can be made to work by upgrading to their respective latest
versions.
Regards
Emiliano
wrote:
> Hi,
> I think that this topic has already been discussed and I'm afraid that
> the behavior will not be changed in future versions (8.6x).
>
> But I have now the problem, that long running code is affected.
The affected code is buggy; please read on ...
> I think that this topic has already been discussed and I'm afraid that
> the behavior will not be changed in future versions (8.6x).
>
> But I have now the problem, that long running code is affected.
>
> My famous application where I was thrown back is the great editor ASED
> (http://www.tcl-home.de/ased), but also several older self written
> pragrams break.
> Code which use pack inside grid does not fail dependable, only specific
> situations end in an endless loop (I also reported such a failure many
> years ago).
> Even tcl tips have been refused for the sake of compatibility and a
> complete turndown seems radical to me.
>
> This refused the general upgrade to 8.6 in my projects.
>
> I'd like to ask therefore for a migration possibility to avoid this
> error - not to forget that some of my older apps, which are working for
> years get this error.
> Is "manual recoding" the only possibilty to circumevent this situation?
>
> PS: Has someone ported ASED to 8.6 or ist someone working on that?
Bwidget's ScrolledWindow. The code is supposed to create a child of
the
SW and use the setwidget method to map the managed window. But ASED
(and other software I've seen in the wild) also tries to [pack] the
child, which is a bug.
As stated above, ASED can be made to work commenting out the two
[pack]s
that breaks on 8.6.
There are other problems with the bundled tools (tkcon and tkdiff).
Both can be made to work by upgrading to their respective latest
versions.
Regards
Emiliano
Uwe Klein
Feb 13, 2012, 3:00:35 AM2/13/12
to
Schelte Bron wrote:
> Robert Heller wrote:
>
>>It is a coding error to use more than one geometry manager in any
>>given container.
>
>
> This statement is false. There are definitly proper uses of more
> than one geometry manager in a single container. For example, to
> make a toplevel window that matches the ttk style I usually place a
> ttk::frame in the toplevel and subsequently grid other widgets in
> the toplevel. This works perfectly. And there is no reason why the
> same thing couldn't be done with pack instead of place.
( haven't used ttk yet )
> Robert Heller wrote:
>
>>It is a coding error to use more than one geometry manager in any
>>given container.
>
>
> This statement is false. There are definitly proper uses of more
> than one geometry manager in a single container. For example, to
> make a toplevel window that matches the ttk style I usually place a
> ttk::frame in the toplevel and subsequently grid other widgets in
> the toplevel. This works perfectly. And there is no reason why the
> same thing couldn't be done with pack instead of place.
What visual effect does that achieve?
> It is however a coding error to have two geometry managers dictate
> the size of the master at the same time. But if you switch off
This is Entrapment ;-)
( and will "boil up" sooner or later imho )
uwe
Gerhard Reithofer
Feb 13, 2012, 1:01:28 PM2/13/12
to
Hi Bron, hi all,
On Sun, 12 Feb 2012, Schelte Bron wrote:
> Robert Heller wrote:
> > It is a coding error to use more than one geometry manager in any
> > given container.
>
> This statement is false. There are definitly proper uses of more
> than one geometry manager in a single container. For example, to
> make a toplevel window that matches the ttk style I usually place a
> ttk::frame in the toplevel and subsequently grid other widgets in
> the toplevel. This works perfectly. And there is no reason why the
> same thing couldn't be done with pack instead of place.
>
> It is however a coding error to have two geometry managers dictate
> the size of the master at the same time. But if you switch off
> propagation for one of the managers, it is no problem to use both
> pack and grid in the same container. So this works (even in Tk 8.6):
>
> pack propagate . 0
> pack [ttk::frame .bg] -fill both -expand 1
> grid [ttk::label .l -text "Hello World"] -padx 20 -pady 20
thanks, that's definitely new to me - exact explanation.
> Without seeing the code, the fact that the OP had some code in an
> older Tk version that did not freeze the display suggests that this
> is what the code was doing all along, but probaly not in that order.
That's right, also some old programs of mine are effected.
It's a fact, that mixing geometry managers sometimes work and sometime
the application freezes (depending on propagation . as you describe very
soundly).
Repairing the apps usually is also no big work - I've commented out the
2 lines in ASED - but my question was more about changed behaviors, if
it is not own code.
I.e. if you deliver a software with the described "bug".
If the customer upgrades his tcl version, the existing "well working"
program can't be run anymore!
If there would be an automatic check and/or repair solution, you could
give all users that tool to repair the software if affected.
At least one company I know has reduced tcl usage because of such a
problem.
[..]
Thank you for all you answers.
On Sun, 12 Feb 2012, Schelte Bron wrote:
> Robert Heller wrote:
> > It is a coding error to use more than one geometry manager in any
> > given container.
>
> This statement is false. There are definitly proper uses of more
> than one geometry manager in a single container. For example, to
> make a toplevel window that matches the ttk style I usually place a
> ttk::frame in the toplevel and subsequently grid other widgets in
> the toplevel. This works perfectly. And there is no reason why the
> same thing couldn't be done with pack instead of place.
>
> It is however a coding error to have two geometry managers dictate
> the size of the master at the same time. But if you switch off
> propagation for one of the managers, it is no problem to use both
> pack and grid in the same container. So this works (even in Tk 8.6):
>
> pack propagate . 0
> pack [ttk::frame .bg] -fill both -expand 1
> grid [ttk::label .l -text "Hello World"] -padx 20 -pady 20
> Without seeing the code, the fact that the OP had some code in an
> older Tk version that did not freeze the display suggests that this
> is what the code was doing all along, but probaly not in that order.
It's a fact, that mixing geometry managers sometimes work and sometime
the application freezes (depending on propagation . as you describe very
soundly).
Repairing the apps usually is also no big work - I've commented out the
2 lines in ASED - but my question was more about changed behaviors, if
it is not own code.
I.e. if you deliver a software with the described "bug".
If the customer upgrades his tcl version, the existing "well working"
program can't be run anymore!
If there would be an automatic check and/or repair solution, you could
give all users that tool to repair the software if affected.
At least one company I know has reduced tcl usage because of such a
problem.
[..]
Thank you for all you answers.
Christian Gollwitzer
Feb 13, 2012, 4:23:02 PM2/13/12
to
Am 13.02.12 19:01, schrieb Gerhard Reithofer:
with a packaged version aka starpack. Otherwise it's quite hard to
ensure stability.
> If there would be an automatic check and/or repair solution, you could
> give all users that tool to repair the software if affected.
>
> At least one company I know has reduced tcl usage because of such a
> problem.
this seems very strange to me. After all, Tcl is indeed quite
conservative. Compare that to Java...
That one - pack and grid together - was a long standing issue while
developping, and a corner case beforehand.
Christian
> I.e. if you deliver a software with the described "bug".
> If the customer upgrades his tcl version, the existing "well working"
> program can't be run anymore!
Well if the end user doesn't know he uses Tcl, he would be better off
> If the customer upgrades his tcl version, the existing "well working"
> program can't be run anymore!
with a packaged version aka starpack. Otherwise it's quite hard to
ensure stability.
> If there would be an automatic check and/or repair solution, you could
> give all users that tool to repair the software if affected.
>
> At least one company I know has reduced tcl usage because of such a
> problem.
conservative. Compare that to Java...
That one - pack and grid together - was a long standing issue while
developping, and a corner case beforehand.
Christian
0 new messages