PDA

View Full Version : best way to connect QGraphicsTextItem to a QEditLine



mooreaa
2nd August 2008, 02:46
Hello,

I have a property editor window for a QGraphicsScene. When I select an object, the proprety editor is populated with the objects properties and I want to be able to modify things like its lables and such.

The problem is, the underlying mechenism for the objects are all QGraphicsItems..

My object has a QGraphicsTextItem called label, but I can't connect the "textChanged" signal from my QLineEdit... Since I have MANY parameters, if I have to have a seperate function for each type of parameter I'm editing, I'd go nuts... Is there a clean way to handle these?

In particular, the textChanged signal is great, but it would also be better if I could get a pointer to the QLineEdit object or something that changed rather than just the string that changed.

I feel like I'm overlooking something here and would appreciate any pointers.

Thanks

mooreaa
2nd August 2008, 03:08
As a side note I tried to add a signal/slot to recieve the text changed message on my object. From MyNode, when I try to wire it up as such:

QObject::connect(node_name_edit, SIGNAL(textChanged(QString)), this, SLOT(setLabelText(QString)));


I got this error message:

1>.\MyNode.cpp(209) : error C2665: 'QObject::connect' : none of the 2 overloads could convert all the argument types
1> c:\qt\4.4.0\include\qtcore\../../src/corelib/kernel/qobject.h(170): could be 'bool QObject::connect(const QObject *,const char *,const QObject *,const char *,Qt::ConnectionType)'
1> c:\qt\4.4.0\include\qtcore\../../src/corelib/kernel/qobject.h(178): or 'bool QObject::connect(const QObject *,const char *,const char *,Qt::ConnectionType) const'
1> while trying to match the argument list '(QLineEdit *, const char [22], MyNode*const , const char [23])'

caduel
2nd August 2008, 09:07
i) a QGraphicsItem (or QGraphicsTextItem) is not a QObject; so you can not use them with signal/slots.

ii) If you need to use signals etc with the items, you can subclass them: subclass from both QObject and the relevant QGraphicsXXXItem class.

ii) I suggest to store data in some custom data structure, derive your items from QGraphicsXXXItem, give them a function 'updateFromData' or so that redraws them based on the values in your data structure.
You can make that data structure available as a QAbstractItemModel (for the property editor) Then you 'just' have to make sure to update the relevant items when the model gets modified.

HTH

mooreaa
2nd August 2008, 10:41
caduel thanks for the reply.

I got things fucntioning by deriving from QObject but I would like to look more into the QAbstractItemModel and see how it might work for my system.

In particular, the paramters are a mix of strings, enums, bools, and somtimes combinations of them.

For example, I have some dynamic "pin" connectors, and each pin has "name" label as well as a "type" enum and some others.

This kind of system would work well with a table view, system

On the other hand, most of my params are just a single input item...

Can I mix/match these kind of different parameters into a simple QAbstractItemModel? Or will I have several QAbstractItemModel types?

Benne Gesserit
2nd August 2008, 11:56
i) a QGraphicsItem (or QGraphicsTextItem) is not a QObject; so you can not use them with signal/slots.

(...)

QGraphicsTextItem is a QObject .It inherits QGraphicsItem and QObject .I agree with the other things .Your items wont be QObjects (and so they wont be able to have thair own signals and slots) unless the inherit QObject or another class that is a Qobject.

caduel
2nd August 2008, 12:33
Ok, a QGraphicsTextItem indeed is a QObject, my bad.

For the model... I would make a tree model:
* for each 'item' on row
* for each property of that item: child rows

Then you can show only the properties of a specific item by calling QAbstractItemView::setRootIndex() on your view.

Read up on model/view in the Qt docs. There are some helpful examples.

[Alternatively, if the set of properties is rather small (and fix), you might wish to make the properties available as additional columns in a table model.]

HTH