> There are ways around it. Specifically removing your object from the > hierarchy before the object is destructed will do it. It is provided as a > service. It is bad enough that we have to write code to explicitly allocate > every single GUI widget. Deleting them explicitly, too, just piles code on > top of code. True, although I would have to opt for deleting everything explicitly because it provides consistency and it reduces the likelihood of having bugs. With having to explicitly delete widgets the only bug you'd have to be concerned with is forgetting to destroy the widget. Since this is implied in the design used this becomes a small issue. > > You would have to manually destroy objects you created dynamically. Which, > > of course could be done by using FindView() or a stored pointer. For, the > > few cases where it would be more convenient to create a object dynamically > it > > would also be more convenient to store the pointer rather then repeated use > > if FindView(). For the majority of the time your could just create objects > > on the stack and they will be implicitly destroyed when the parent is > > destroyed. > > IIRC, there is a huge issue with R5 and static object creation of GUI > components. I don't think you can do it (but I am going on a vague memory and > not enough sleep). That would be a good thing to fix - it would make a lot of > stuff easier. Yea, the problem is they delete themself. You can the object on the stack. Then they go out of scope, their destructor is called, they try to delete themselves and the program suddenly crashes. Yea, I agree this would be a nice thing to fix. Later, Scott MacMaster