Signals destroys my pointer

[wysota]

I don't need signal proxys, because (don't hit me) I "#define protected public" before each signal. Works fine, and I don't need emitters.

This behaviour is not documented anywhere (meaning its implementation dependent), so one day your code might just stop working.

But do you have any ideas about the problem?

I'll ask my question again Why don't you use references instead of pointers?

void onFindTextSignal (interfaces::eventArgs::findTextEventArg &searchParameter);

void onFindTextSignal (interfaces::eventArgs::findTextEventArg &searchParameter);

To copy to clipboard, switch view to plain text mode 

BTW. Are the emitter and receiver in the same thread? Which Qt version are you using?

[Jojo]

Hello,

thanks for your answer.
I am using pointers because passing by reference does not work. QObject gives me a warning at runtime, telling me the parameter can not be queued. Registering my custom type to the Qt Metasystem should work, but it doesn't. So I use pointers.
This problem occurs with Qt 4.1.0 and with the previous version too.
I use a single threaded application, the signals are not queued either.
Odd, isn't it ?

[wysota]

Registering my custom type to the Qt Metasystem should work, but it doesn't.

What errors do you get?

[seneca]

What you are trying to do will obviously fail when the signal is queued. You are creating an object 'args' within the method 'onFindButtonSlot' and sending it's address by the signal. However that object is deleted at the end of 'onFindButtonSlot' and when your queued signal is processed later it is allready destroyed.

[Jojo]

Hello,

I have set the signal explicitly to a direct connection, and now my search function works like a charm. I really can't explain why, I am not using threads, and I am always calling connect without any extra connection type parameters.

Now I have another problem. My application will terribly crash if signal connections are not direct. I haven't noticed any strange crash yet, but who knows.

What shall I do now? Explictly set DirectConnection to each connect line? Set a nondocumented flag in QApplication to disable implicit multithreading? I'm again very clueless about Qt's behaviour..

Thanks for advice again

[wysota]

Don't use pointers to temporary objects. Either make those structures heap based or don't use pointers at all. I'm still curious what errors did you get while trying to use a reference... Maybe you forgot the magic "const" keyword? It is possible if you wanted to reference a temporary object.

[Jojo]

Don't use pointers to temporary objects. Either make those structures heap based or don't use pointers at all. I'm still curious what errors did you get while trying to use a reference... Maybe you forgot the magic "const" keyword? It is possible if you wanted to reference a temporary object.

Hello,
I need pointers to objects. As I said before, passing custom types over signals only works when I pass them via pointer.
I don't think passing the pointer as const would help much. As far as I see it, Qt signal parameters are passed by value just like in Java or in .NET. I can't see a constant pointer help much there.
Passing a pointer for a temporary object is fine in my case, because the controller creates a copy of the passed object, so the temporary object pointer is only accessed once, when the object is still well defined.

I don't get any errors when accessing the passed pointer. Since when tells C++ errormessages when you do something wrong
What happens is, that the received pointer is garbage.
Use "int* a; int b = *a+4" for a similar experience. Either your programm crashes or you receive some weird values..

Still the question remains, why does Qt make my signal calls asynchronous? This is poison for my application!

[wysota]

As I said before, passing custom types over signals only works when I pass them via pointer.

But what does "not work" mean?

I can't see a constant pointer help much there.

I meant a constant reference.

Passing a pointer for a temporary object is fine in my case, because the controller creates a copy of the passed object, so the temporary object pointer is only accessed once, when the object is still well defined.

Not with asynchronous calls.