Problem: QValueSpacePublisher using a custom QVariant in setValue

golfnut

I am using the mobility publish/subscribe classes which works nicely. I wanted to publish the address of several class instances. I can do this by casting the address to a long and storing that in a QVariant.

I wanted to use a custom QVariant with pointer type to my object and and was successful in doing so. I know that the custom QVariant functioned properly because I could call setValue() and then a value() on the QVariant and was able to retrieve the proper value.

When I use this custom variant in QValueSpacePublisher.setValue I get the following runtime error: QVariant::save: unable to save type 258.

Any reason that I would not be able to use the custom QVariant as an input parameter to QValueSpacePublisher?

giesbert

Does it really make sense to set a pointer in a system wide variable?

If I understood correctly from reading the docs, QValueSpacePublisher sets the values so they are accessible from multiple apps. pointers are normally only valide inside one app, not outside (or is this different in mobiles?)

golfnut

Thanks for the reply. I believe in my case it makes sense. I am coding a Sudoku game board. It consists of a grid of 81 cells (9x9 )and each cell may contain a value that the user enters. In my class hierarchy, the class that contains the logic to accept the user input for a cell is several layers deep in a containment chain. I need to have one of the outer layers of this containment chain receive a signal when the value is changed. No need for the pointer here and I accomplish this through a publisher/subscriber using an int. The need for the pointer is that this outer layer then checks all values in the current row and column for that cell and if it finds an error it needs to send a message to the cell to change its background color on the screen. To keep cohesion as low as possible between the classes and to not have to march pointers up and down the containment chain, I chose to use publisher subscriber.

I can get around the problem by converting the pointer to an integer value, but did I encounter a bug in QValueSpacePublisher or is this a legitimate constraint of a publisher subscriber? If it is legitimate, it should probably be documented.

Thanks again and any insight you have would be appreciated.

goetz

It sounds like this is all done within one single application. This cries for the use of signals/slots...

golfnut

This may be due to my ignorance of QT since I am a new user. I initially wanted to do this with signal/slots, but when I do the connect a signal from the inner most class (sender) to a slot of the outermost class (receiver), doesn't the inner most class need the address of the receiver for the slot?

If so, trying to keep the innermost class independent of the outermost class, how would it know that address without passing down that address through the containment chain?

Please let me know what I may be missing.

Thanks

goetz

You would do the connect in the outer class, that probably knows of the inner class as it has to be instantiated somewhere. It's irrelevant where the connection is setup.

golfnut

Thanks again for the reply. The class containment has several layers of nesting. I know of no easy way to have the outer layer easily know the address of the inner class or vice versa. The containment consists of a single instance of a class that contains 9 instances of the next level down, each of which contains 9 instances of another class and this gets repeated one more time. To make this clearer, Sudoku consists of a game board, which contains a 3x3 grid of blocks. Each block consists of a 3x3 grid of cells. I need 2 way communication between the gameboard and the cell.

Is there an easy way to provide the addresses to the extreme ends of the containment without passing these down as parameters or a structure to store these addresses all the way down the containment chain?

Thanks.

goetz

Then connect the signals of an inner class instance to the class instance one level up and have the latter re-emit some signal.

Unfortunately beaming has still not been invented, so no, there is no way to avoid parameters.

golfnut

I really appreciate your patience in this discussion. That is precisely why I picked publish/subscribe. Less code, less interclass coupling. In my design when a user changes a value of a cell I want to send a signal to a row class, column class and block class to determine if it is valid and if it is not, have the cell color on the screen change. Publish/Subscribe does this very well. The next best thing to beaming ;-).

Since publish does not accept a QVariant with a pointer type, I will fill out a bug report since I believe it should (based on the manual page).

Thanks for all your help.

goetz

The bug report will be closed immediately, I guess.

As far as I understood the docs, the value space should/can be used for inter process communication, i.e. between applications. Storing pointers there is pure nonsense, as a second app cannot access the data in the first app.

If you hesitate to use signals/slots, create a global object where the inner classes can register themselves; it's basically the same as the value space, but much more lightweight, I would guess.

golfnut

I totally agree with you that if I was trying to do interprocess communication, passing pointers would be disastrous. My bug report essentially will ask that the documentation be updated to state the limitation so that others do not spend time trying to solve a problem that may not exist. My personal feeling is that publish/subscribe should not be limited to "mobile" applications and perhaps could be implemented with a switch in the constructor to allow override of the limitation at the users peril.

By the way, I initially was going to do exactly what you suggested, but thought why reinvent the wheel if QT has been good enough to give me an implementation of the p/s pattern.

I will just cast the pointer for the Variant to an unsigned int, which works nicely in my environment, if not strictly portable.

Once again thanks for you help and suggestions.

goetz

Ah, that's a good point for the bug report. Commentable documentation will "arrive here at Qt DevNet soon":http://developer.qt.nokia.com/blog/view/qt_documentation_our_new_roomie. You might keep that in the mind and be the first one to add a doc comment :-)