[Qt-interest] adressing something to the mainWindow from adialog

[John McClurkin]

	Use of Qt's signals and slots is what makes it possible for the child 
to have no knowledge of its parent... or any siblings. From what I 
understand of the OP's question, the dialog allows the user to change 
values that are to be used beyond the dialog, even globally. The dialog 
should know what values it can manipulate and thus, what values it can 
export. When the dialog emits a signal that carries its values, it does 
not need to know or care what other objects are receiving those signals, 
  only that these values may be of interest to other objects.
	While the child object does not need to know about its ancestors or 
siblings, a parent object does need to know about its children. To post 
a dialog, the parent must know what the dialog is supposed to do, and it 
should know what signals the dialog can emit. Thus, when the parent 
creates an instance of a dialog, it can connect the dialog's signals to 
its own slots, or to its signals. Then, when the user interacts with the 
dialog, the dialog can say..."To whom it may concern, this just 
happened". The parent can then act on the information or emit its own 
signal saying..."To whom it may concern, this is what my child just 
did". Thus, no object needs to know about its parents or siblings. This 
is completely in accordance with Qt best practices as I understand them, 
and is also completely in accordance with OOP encapsulation.

> You are ABSOLUTELY correct...
> 
> A child, except in some limited cased (like tree widget items) should
> basically have no knowledge of its parents...
> 
> Do so, limits the childs usefulness, since it can only be used for that
> parent..
> 
> Scott
> 
>> -----Original Message-----
>> From: qt-interest-bounces at trolltech.com [mailto:qt-interest-
>> bounces at trolltech.com] On Behalf Of Andrea Franceschini
>> Sent: Tuesday, April 07, 2009 7:17 AM
>> To: qt-interest at trolltech.com
>> Subject: Re: [Qt-interest] adressing something to the mainWindow from
> adialog
>> Now that I've been staring at the whole discussion for like five
>> minutes, and since I'm
>>  going to graduate in CS and will probably apply for a PhD course ;)
>>  I'd like to understand one little thing (which of course best fits
>>  into the "C++ best practices" than "Qt" category, so feel free to
>>  ignore my question): isn't it in the first place somehow wrong to
> give
>>  a "conceptually child" class permission to access its parent? If this
>>  is true, I'd better go the way I first suggested, i.e. to define
>>  appropriate pointers inside the dialog and make the parent class make
>>  them point to its appropriate variables so that the child has
> "limited
>>  knowledge" of its surrounding environment.
>>
>>  Under this light, the whole parent()/global qApp ideas look like
> dirty
>>  workarounds, am I wrong? I usually try to avoid child->parent access
>>  when it's possible, although I agree it's mostly useful, instead
> going
>>  for parent->child which sounds to me much better in terms of
> elegance.
>> _______________________________________________
>> Qt-interest mailing list
>> Qt-interest at trolltech.com
>> http://lists.trolltech.com/mailman/listinfo/qt-interest