Wow, lots of stuff in this reply. Thanks!.
I'm not trying to be argumentative. I'm definitely a newbie and want to learn important design considerations. So, thank you for patience and continued replies.
I'll try to clarify what I had in mind with answers to your comments.
So HeatRecord instances are purely value based, as their name suggests -- a record is some set of data.
I don't know what you mean by is "purely value based". There are methods in that class too. What else is missing (data + methods) that would make it appropriate to emit a signal?
"Still, no use for signals. An object is constructed and there it is."
Ok, sounds like the conclusion should be a signal that's generated just once is not worth doing? Depends on what you're trying to accomplish with the signal.
The idea was to make records available for consumption by unspecified (unspecified by the HeatMessage class) widgets. Creators of HeatMessage/HeatRecords would decide whether that signal is of interest and to what (if any Widgets). But, alternately, I can add a method that can be used to in effect "poll" after each creation of the entire message instead of doing an event driven approach like emiting a signal when/if a record of interest is accumulated. Either way will work.
Where would that signal be? What would it carry? Who would connect to it? If this signal is to be emitted by HeatMessage
The signal would be in the HeatMessage (or HeatRecord) class. It would carry a HeatRecord object.
emit special_record(HeatMessage hm) ;
emit special_record(HeatMessage hm) ;
To copy to clipboard, switch view to plain text mode
Versus something like:
HeatMessage hm(msg);
emit new_message(hm);
// new code follows:
if (hm.oob_received())
{
emit special_records(hm);
}
HeatMessage hm(msg);
emit new_message(hm);
// new code follows:
if (hm.oob_received())
{
emit special_records(hm);
}
To copy to clipboard, switch view to plain text mode
This code fragment that instantiates the HeatMessage object is already a QWidget, so everything works fine.
But, the same arguments you're providing would apply here too, eg:
it's not like such record would magically appear 10 seconds after the message that contains it has already been parsed.
But, if I don't use signals, I'd have to create a method in the class for the QWidget that will display the data, and call it instead. Which means I need to include the header files for classes that would consume the data, to be able to call them here. That's why I wanted to use a signal instead. Why not?
then why don't you just add a list of those "out of band" records to HeatMessage class just like you have a list of HeatRecord instances?
That was what I planned to do anyway. The only difference was that I was just going to generate a signal in the code that will already know it's one of these new record types rather than having to make a call to a method to see if any exist. They will rarely be present.
Each message either has those OOB records or not, it's not like such record would magically appear 10 seconds after the message that contains it has already been parsed.
True.
So, here's what I'm concluding from this thread. Please correct me if I'm wrong.
1) You cannot pass objects derived from Qbjects (or QObject &) as an argument of a signal.
(This is the one that makes it more hassle than it's worth in this situation). I'd like to confirm that understanding.
2) You're recommending NOT creating signals, except if the signals would occur more times than just at object creation time?
The alternative implementation works fine and requires minimal code change too. A separate method is used to return the list of OOB messages and the code that creates HeatMessage instances can call that method and emit the signal if OOB records exist. I don't see why I would NOT emit a signal on what I think of as a rare event, but I could include the header file for the widget that will consume the data instead of emitting the signal. Again, the motivation for using the signal is to allow the binding to between producer and consumer of that data elsewhere, but it's not a strict requirement.
Thanks again.
Dave Thomas
Bookmarks