PDA

View Full Version : how to refer a dynamically added table widget inside a scroll area widget?



aurora
2nd February 2012, 06:48
I have created a scroll area , inside that scroll area added a QToolBox...
And in run time i'm adding pages to QToolBox....
Each page contains a scroll area, inside that scroll area , number of QCheckBoxes are present....
Now i want to get pointer to particular QCheckBox...by passing pagename and CheckBox name...

Is that possible? If so please give some hint...
my ui file


<?xml version="1.0" encoding="UTF-8"?>
<ui version="4.0">
<class>FilterColl</class>
<widget class="QDialog" name="FilterColl">
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
<width>686</width>
<height>615</height>
</rect>
</property>
<property name="sizePolicy">
<sizepolicy hsizetype="Expanding" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="windowTitle">
<string>Dialog</string>
</property>
<layout class="QGridLayout" name="gridLayout">
<item row="0" column="0" colspan="4">
<widget class="QScrollArea" name="scrollArea">
<property name="widgetResizable">
<bool>true</bool>
</property>
<widget class="QWidget" name="scrollAreaWidgetContents">
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
<width>666</width>
<height>566</height>
</rect>
</property>
<layout class="QGridLayout" name="gridLayout_2">
<item row="0" column="0">
<widget class="QToolBox" name="toolBox">
<property name="sizePolicy">
<sizepolicy hsizetype="Expanding" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="currentIndex">
<number>0</number>
</property>
<widget class="QWidget" name="page_2">
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
<width>648</width>
<height>521</height>
</rect>
</property>
<attribute name="label">
<string>STATUS</string>
</attribute>
</widget>
</widget>
</item>
</layout>
</widget>
</widget>
</item>
<item row="1" column="3">
<spacer name="horizontalSpacer">
<property name="orientation">
<enum>Qt::Horizontal</enum>
</property>
<property name="sizeHint" stdset="0">
<size>
<width>40</width>
<height>20</height>
</size>
</property>
</spacer>
</item>
<item row="1" column="1">
<widget class="QPushButton" name="pushButton_OK">
<property name="text">
<string>OK</string>
</property>
</widget>
</item>
<item row="1" column="2">
<widget class="QPushButton" name="pushButton_CANCEL">
<property name="text">
<string>CANCEL</string>
</property>
</widget>
</item>
<item row="1" column="0">
<spacer name="horizontalSpacer_2">
<property name="orientation">
<enum>Qt::Horizontal</enum>
</property>
<property name="sizeHint" stdset="0">
<size>
<width>40</width>
<height>20</height>
</size>
</property>
</spacer>
</item>
</layout>
</widget>
<resources/>
<connections/>
</ui>

KillGabio
2nd February 2012, 12:19
In my case i suggest you to use SIGNAL`s and SLOT`s they are very useful for your purpose i guess.

http://developer.qt.nokia.com/forums/viewthread/4646

take a look at that, i think there is a variety of solutions

wysota
2nd February 2012, 12:38
It's a classic OOP problem that has nothing to do with Qt. If you encapsulate one object inside another one, you need to provide means (e.g. methods) in the external object to access the internal one.

Spitfire
2nd February 2012, 16:40
Qt provides such means.


QWidget* find( const QString& pageTitle, const QString& childName )
{
QCheckBox* ret = NULL;
for( int i = 0; i < tool_box_widget->count(); ++i )
{
if( tool_box_widget->itemText( i ) == pageTitle )
{
ret = tool_box_widget->widget( i ).findChild( childName );
}
}
return ret;
}It's not a working solution but should push you in a right direction.

wysota
2nd February 2012, 16:48
Never use findChild() unless you have no other choice (and almost always you do). Besides it only works for QObjects parented to the external object which is not always the case.


class Ext {
public:
Int* intObj() const { return m_internalObject; }
private:
Int* m_internalObject;
};

Spitfire
2nd February 2012, 16:58
What's wrong with findChild(), doc doesn't mention anything?

Anyway, my point was that Qt already provides means of traversing widgets hierarchy, and knowing what you're looking for you don't need anything else.

wysota
2nd February 2012, 17:07
What's wrong with findChild(), doc doesn't mention anything?
Consider the following two samples and try to come up with your own conclusions.



Object * Cls::goodWay() const {
return m_obj;
};


template<class T> QObject *findChildSimulationHelper(QObject *parent, QString name) {
QObjectList list = parent->children();
foreach(QObject *obj, list) {
if(qobject_cast<T*>(obj) && obj->objectName()==name) return obj;
QObject *found = findChildSimulationHelper(obj);
if(found) return found;
}
return 0;
}

QObject *Cls::badWay() const {
return findChildSimulationHelper<SomeClass>("someName");
};

If you still don't get it, I'll give you a hint. Imagine the external object holds 100 widgets each of which holds 100 more widgets.


Anyway, my point was that Qt already provides means of traversing widgets hierarchy, and knowing what you're looking for you don't need anything else.
qFindChild() is not a way to traverse widget hierarchy.

Spitfire
2nd February 2012, 17:20
It's a slow, semi-acurate method of finding a child you're looking for - I know that.

I wouldn't use it on a widget containing 100 widgets containing 100 widgets each, but when you have a 5 tabs, 10 boxes each, why not?
It will do the job, will not do any harm (unless I'm missing something), and performance is not an issue either.
There's assumption there that names are unique though.

wysota
2nd February 2012, 20:52
I wouldn't use it on a widget containing 100 widgets containing 100 widgets each, but when you have a 5 tabs, 10 boxes each, why not?
Because if you do that 10 times per second for two consecutive hours it's still hell slower than just returning a stored pointer which costs at most three machine instructions.


It will do the job,
That's not so certain. What if you have two or more objects with the same name (which can easily happen if your widget contains other widgets composed from some more widgets)? What if the object you are looking for is not a QObject subclass?


and performance is not an issue either.
That's true if your application doesn't do much besides looking for items. However such applications are very boring.


There's assumption there that names are unique though.
Why assume anything if you have a perfectly good solution that doesn't need any assumptions?