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?
> 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?
It is a coding error to use more than one geometry manager in any given
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
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):
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.
On 12 feb, 14:05, Gerhard Reithofer <gerhard.reitho...@tech-edv.co.at>
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 ...
> 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.
>>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 )
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 > propagation for one of the managers, ..
This is Entrapment ;-)
( and will "boil up" sooner or later imho )
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):
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.
> 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 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.
