parent wnd and gui
I been avoiding having a pointer to the parent window from the child (i am not sure why) and i wanted to know if you guys think i should have it in there.
The only reason i can find is ease of logic. If i do childWnd->setFocus(); it would need the parentWnd bc the parentWnd internals control what is in focus. This and maybe set x,y are the only case i can think of requiring the parentWnd. But for xy i been doing it in the parentWnd bc it keeps track of the changes for painting reasons so i dont actually need the class to know the parentWnd in this case, i was just considering it.
Doing parentWnd->setFocus(childWnd); is not as easy for the programmer to write as childWnd->setFocus(); so, should i be doing parentWnd->setFocus(childWnd);? or should i have the child know its parentWnd and for what other reasons if you know any?
I had the same problem a while ago when designing my gui library. I tried 2 different methods. The first was the parent > child relationship where the child knew who its parent was. The second was using callbacks. When child->setFocus() was called, an event was triggered which the parent subscribed to. Hence, the parent was notified automatically, without the child's knowledge, and took an appropriate response. This was done using a delegate system.
But I settled on using the first method. Mainly because .NET, Borland's VCL, Trolltech's QT, and many other well established gui libraries do the same. There's no point in trying to reinvent something if a standard has already been established.
But I settled on using the first method. Mainly because .NET, Borland's VCL, Trolltech's QT, and many other well established gui libraries do the same. There's no point in trying to reinvent something if a standard has already been established.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement