Parent, signal and event questions

[frenk_castle]

1. Parent questions

Say that inside my main window constructor I have the following code:




myWidget = new MyWidget(this);
myLayout = new MyLayout(this);

myLayout->addWidget(myWidget);


If I understood the documention correctly layout becomes parent of every widget added to layout with addWidget method. So I could go with out this when I allocate memory for myWidget. I could have wrote myWidget = new MyWidget(). This is trivial example, but I have classes that have layout within layouts and 10 - 20 widget added to those layouts. Is it better practice not to give parents to widget when allocating memory for them and use addWidget methods to give them appropriate parent, or to give them some parent when I allocate memory for them and change the parent later when I have where to add them. Second approach maybe create an overhead but I am not sure which method is better? When I run my code from creator the second approach generate messages like widget already has parent. The first one does not.

2. Signals question

I have an application that have among other things two ComboBoxes. In one are clients and in other are jobs for the selected client. Every time current index in either of those ComboBoxes is changed signal is emited and one of two slots of my bussines logic class handles the signal. Application sometimes crashed I suspect because both functions change the state of my internal data structure, which in turn can cause currentIndex in one or both ComboBoxes to change which in turn emits the signals which in turn causes slot functions to be called while internal data structure is in transit and possibly error state. I am not sure if this is the cause but I added the following code in four methods that change my internal data structure and data in my widget. First method clears everything. Second initialize everything to starting values. Third and fourth are slots that handles the signals.



m_widget->blockSignals(true);
//do what ever method already did
m_widget->blockSignals(false);


Is this approach considered good programing practice using Qt or is there a better way?

3. Event question

Is there a way to make widget not respond to mouse wheel. People which are using my application are getting confused. For example ComboBox reacts if you scroll the mouse wheel while the pointer is above ComboBox even if you didn't clicked on the ComboBox first. When user clicks on one ComboBox makes a selection and just puts mouse pointer above another ComboBox and scroll the second ComboBox reacts and not the first. I want for start to ComboBox ignore mouse wheel. Later I would try to accomodate application to their wishes and make probably only clicked widget respond to mouse wheel but for start I just what a way to make specific widget ignore mouse wheel. I read the documentation but failed to find the way to do this. If you could point the way for me to a class, method, or a link where is described how to do this it would save me great deal of time.

[axeljaeger]

1)
No, the layout does not become the parent of the widgets. We have three involved parties: The container widget, the layout that lays out the children of the container widget and the actual child widgets to be laid out. You set the layout the be the layout manager of the container. When you add child widgets to that layout, the container widget that the layout manager is managing becomes the parent of the childs. I think it is a matter of taste whether to pass the container as parent to the constructor of the childs. I prefer to do so because there is many places in Qt where you have to pass that parent for proper cleanup, for example when using timers. You dont add timers to a layout and because I do not want to decide everytime, I take the safe way and always pass proper parents.

2) No this is not considered good programming style. But ATM I cannot give advise how to do it better. How do you fill your combos with data? Do you use a proper model or do you add items by hand?

3) While Qt usually follows what the plattform does with wheel events (See whether other applications behave the same as the Qt ones) and it is not good practise to differ from the system behavior with a single application, the effect you want to have can be implemented using an "Event filter". That is the keyword to search for.

[frenk_castle]

First thank you for your help.

1. Usually I create some widgets without parents. Then I create a QGroupBox. I then create a layout and pass QGroupBox as a parent of the layout. Then I add widgets to layout. Later I add QGroupBox to some other layout of some other widget. Maybe my methods is not the best. If I understood you correctly when I use QLayout::addWidget the widget that the specific layout is managing becomes the parent of the added widget. Is this also true for addLayout and addItem.

2. For QComboBox I usually create QStringList and then use clear then addItems method. If I understand both methods correctly they both change currentIndex of the QComboBox. Since I do this "cleanup and reseting" close to the begining of my handler methods it caused for signals to be emited by slot methods actions. Again maybe my modus operandi is not considered good Qt programming but I am working on the biggest application I have ever build while still trying to learn Qt. I am probably reinventing the wheel all the time. Hopefully I will publish the source code once I am done and somebody with more experience will show me what I could have done better. I will try to find the better solution once the application is complete.

3. As far as I read Wheel Event documentation the widget below the mouse pointer reacts to the mouse wheel action. This is default linux behaviour. I do most of the development on my notebook under linux but final deployment will be on XP. As far as I can tell under Windows the widget that has the mouse focus reacts to the wheel. And the widget gets focus when user click on it. This is maybe not so Windows default but .NET default behaviour. People that are going to use my application are used to clicking on the widget they want to respond to the wheel so this is little confusing for them. They used only Microsoft applications so far.

I again thank you for your advice. I will read documentation again and try to understand it better with the information you provided to me. I will also try to improve my code so it is safer and less prone to crashes.

[axeljaeger]

1) Your method is fine
2) Usually you would subclass QAbstractListModel to map the basic database operations: Change, Add, Remove from your internal data structure to something that a Qt View, either a List view or a combo box can understand. If you have for example 10 000 items in your combo, removing all of them and fill again clearly takes too much time
3) I guess Qt reacts on windows the right way. You should try this before installing any event filters.