[bt-devel] SegFault in 2.3.3 during navigation
Eeli Kaikkonen
eekaikko at mail.student.oulu.fi
Wed Nov 4 14:48:15 MST 2009
On Wed, 4 Nov 2009, Martin Gruner wrote:
> Gary,
>
> I am not sure about this. There are instances where it makes sense that
> different objects share the same key. That is because the key also holds a
> reference to a particular module, which is important for versification schemes
> and localization of bible booknames. At least that's the idea behind the
> current implementation, we might come up with something better, of course. One
> display window has one main key which is also used by the keychooser and its
> widgets etc. I keep forgetting the implementation details. :-(
The answer might be to create and delete the pointer in the text window
class because it always exists before the parts and is deleted last.
When subwidgets are created they can set their m_keys each to the same
pointer value than the window m_key, if the per-widget m_key is needed
at all. The window could act as a signal router. If needed, the
subwidgets could send their own address as signal argument. Then a
subwidget can check whether the signal from the window came originally
from itself.
Is the m_key needed for each widget? What if we had a class
"BtKeyHandler" which would have only methods to get and set the key
reference? All widgets which handle the key would subclass it so it
couldn't be an QObject and unfortunately signal handling couldn't be
automatic. If we want more automatic signal handling there could be
BtKeyHandlerWidget class which subclasses QWidget. Then each widget
would have:
signals: void keyEdited(BtKeyHandlerWidget*);
slots: void keyWasChanged(BtKeyHandlerWidget*);
void SomeClass::keyWasChanged(BtKeyHandlerWidget* w){
if (w != this) {
//update the visible value
}
}
Yours,
Eeli Kaikkonen (Mr.), Oulu, Finland
e-mail: eekaikko at mailx.studentx.oulux.fix (with no x)
More information about the bt-devel
mailing list