Erik Hofman wrote:
I think I'm on to something so I'll hold back reverting the patch to the
dialogs code until I got this sorted out.
I've fixed the removeChild() problem now. The problem was that the
(previous) node was returned if the path wass still available in the
path cache.
I've also rev
Andy Ross wrote:
Erik Hofman wrote:
The way the code works is like this (I show it only
for "width", but it's almost the same for "x", "y",
and "height":
Er... no. I wrote it (the layout support we are talking about),
remember? :)
Alright, I get the picture now. It's not how I would have done it,
Le lundi 16 mai 2005 Ã 17:52 +0200, Gerard ROBIN a Ãcrit :
> With the last CVS update It still continu working:
> difficulties seem mainly with
> Rendering option,
> Autopilot,
> Weather scenario
>
> Temporary, the solution is to add and property in the
> GUI .xml files .
>
> The second usag
With the last CVS update It still continu working:
difficulties seem mainly with
Rendering option,
Autopilot,
Weather scenario
Temporary, the solution is to add and property in the
GUI .xml files .
The second usage is correct but not centred (down-left)
--
Gerard
___
Erik Hofman wrote:
> The way the code works is like this (I show it only
> for "width", but it's almost the same for "x", "y",
> and "height":
Er... no. I wrote it (the layout support we are talking about),
remember? :)
The layout manager is a preprocessor. It takes the
x/y/width/height propert
Andy Ross wrote:
Indeed this patch (below) doesn't work the way you want it to. It is
not impossible to have a dialog element with a user defined width or
height. The layout management code will clobber that value -- you
should be able to see this by deleting and recreating the dialog
repeatedly.
I wrote:
> > Erik Hofman wrote:
> > The removeChild() code was used because "we" wanted the dialog to appear
> > with the same dimension and location after loading the configuration
> > file again. But we don't do that anymore, the settings remain in the
> > property tree so the removeChild calls s
Erik Hofman wrote:
> No, removeChild isn't broken, the GUI code was broken.
Erik, you seem to have missed the point. Sorry, but this call is
definitely bugged. Call removeChild() on a node, fetch the node
again, it should return null, but you get the old node even after it
was removed.
> The re
Melchior FRANZ wrote:
* Erik Hofman -- Monday 16 May 2005 10:40:
No, removeChild isn't broken, the GUI code was broken.
So you have a good explanation for getNode() on a removed node not returning 0?
I'd say, removeChild() *is* broken, no matter how many other bugs there are in
the dialog code.
I
Melchior FRANZ wrote:
* Erik Hofman -- Saturday 14 May 2005 23:18:
I get the feeling we might be better off reverting that particular patch.
Yes, no problem. But please, all of you: stay away from the crap that is
called "removeChild()". It's broken. Better add a bug message there, or
even abort()
Melchior FRANZ wrote:
> Sure. I was you who said we'd be better off reverting. I'm all for
> fixing it. I just don't know how to do this without breaking
> everything. Or I would have fixed it already.
Give the attached patch a try. It removed the whole idea of "saving"
removed nodes for future
Andy Ross wrote:
Well, yeah, or just, y'know, fix it. :)
It shouldn't be hard: just rewrite removeChild to actually remove it,
and we're done. I have a hard time seeing why we should want to write
around this API: this is a sane call with a very clear meaning, it
just has a bug. Bugs are meant to
Melchior FRANZ wrote:
> (0) removeChild() didn't *really* remove the node, but only mark it as REMOVED
> (which is OK and done for performance reasons)
Well, that's the bug certainly. In fact, a quick grep through the
property code shows that flagging the node as removed is, in fact, the
sole
Melchior FRANZ wrote:
So, should we sweep the ... worms ... under the rug, again? And pretend
everything is fine? Carelessly reading from removed nodes, as we always
did?
I think this might have something to do with a recent GUI code change.
In the past the dialogs got read every time the dialog s
Melchior FRANZ wrote:
> For example, the removed "x" value on second display is read again:
Both of those circumstances have a default value specified, for
precicely the reason that the nodes may not exist.
Calling getIntValue(node, default) on a node that had previously been
deleted with removeC
Melchior FRANZ wrote:
> Only Nasal dialogs are generated new every time. The ones in
> $FG_ROOT/gui/dialogs/ are only read once and then remain in the
> property tree, no? When such a dialog is displayed next time, it will
> again read x/y/width/height ... which were removed at the end of the
> fi
Andy Ross a écrit :
Melchior FRANZ wrote:
I've found the bug already. In dialog.cxx:
// Remove automatically generated properties, so the layout looks
// the same next time around.
if(!userx) props->removeChild("x");
if(!usery) props->removeChild("y");
if(!userw) props->removeChil
Melchior FRANZ wrote:
> I've found the bug already. In dialog.cxx:
>
> // Remove automatically generated properties, so the layout looks
> // the same next time around.
> if(!userx) props->removeChild("x");
> if(!usery) props->removeChild("y");
> if(!userw) props->removeChild("w
On Saturday 14 May 2005 14:56, Melchior FRANZ wrote:
> * Melchior FRANZ -- Saturday 14 May 2005 14:29:
> > * Harald JOHNSEN -- Saturday 14 May 2005 14:11:
> > > The last commit on props.cxx and prios_io.cxx has a side effect on
> > > dialogs. They appear correctly the first time you invoke them, bu
19 matches
Mail list logo
