Page 2 of 2 FirstFirst 12
Results 21 to 36 of 36

Thread: Minimum required to emit a signal

  1. #21
    Join Date
    Sep 2011
    Posts
    1,241
    Thanks
    3
    Thanked 127 Times in 126 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Minimum required to emit a signal

    Maybe I misunderstand something, but it seems like your HeatRecord/HeatMessage is not a good construct. As I understand it, you pass data to these things and then the instances may or may not be 'correctly formed' depending on how the bytearray parsing goes. If this is correct then it is not good practice. Can you clarify this?
    If you have a problem, CUT and PASTE your code. Do not retype or simplify it. Give a COMPLETE and COMPILABLE example of your problem. Otherwise we are all guessing the problem from a fabrication where relevant details are often missing.

  2. #22
    Join Date
    Jun 2012
    Posts
    219
    Thanks
    28
    Thanked 3 Times in 3 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Minimum required to emit a signal

    "then the instances may or may not be 'correctly formed'"

    That is not correct. They will always be correctly formed. Occaisonally, there will be additional records (e.g. when a lower level prototocol had to retransmit a packet because it didn't receive the expected ack) that will exist in the input data that aren't logically part of a HeatRecord or HeatMessage. They are of interest and will be displayed in a different widget that shows diagnostic data about the communications channel. So, the HeatMessage/HeatRecord classes know about the data format, they only know enough about these types of records (they match a specified RegExp) to understand they should be interpreted by code encapsulated in a different class.



    But, I can easily execute a public method in the HeatMessage classe that would be something like "bool get_matching_records (RegExp regexp)". If it returned true, the calling method would emit a different signal and pass the HeatMessage object like it does today. Since HeatMessage isn't an Q_OBJECT, there's no issue with passing a copy.
    Last edited by davethomaspilot; 21st February 2013 at 21:22.

  3. #23
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Minimum required to emit a signal

    Quote Originally Posted by davethomaspilot View Post
    The constructor for the HeatMessage looks at the passed QByteArray to see if it looks like a set of valid HeatRecords This includes making sure it has an integral number of 16 bytes, and finding record boundaries for creating HeatRecords.

    HeatRecords are constructed from data passed to the HeatMessage constructor and added to a list of all the HeatRecords found in the HeatMessage.
    So HeatRecord instances are purely value based, as their name suggests -- a record is some set of data. I don't see what sense it makes for data to emit any signals. Even assuming that data in each of those objects might be changed dynamically, who would be interested in connecting to all those objects to monitor those changes?

    The HeatRecord constructor parses the bytes passed and saves data in private data members. Methods of the HeatRecord class allow encapsulate access of things like race number, heat number, win/loss--insulating code that wants that information from having to know the byte layout of a HeatRecord or HeatMessage. Sure, code that creates the HeatMessage could dive right into the data, but knowledge of the data format should be encapsulted in the HeatMessage class. That's the motivation for creating an object, not for simply creating a signal.
    Still, no use for signals. An object is constructed and there it is.

    However, I'm now adding a new record to a communication protocol, that's sort of like "out of band" data. It contains things like "number of retries", RF signal strength, "number of dropped pakets" It isn't a valid HeatRecord (which is a data format I can't modify), and I'd like to show its data in another Widget (to be developed). I'm considering using a signal, so a connect can be used to send these new type records to a widget that extracts data from and displays these new type of records.
    Where would that signal be? What would it carry? Who would connect to it? If this signal is to be emitted by HeatMessage 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? 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.

    Why shouldn't I be emitting any signals?
    I'm not saying you shouldn't be emitting any signals. I'm saying you shouldn't be emitting signals from HeatMessage and HeatRecord objects.

    The way I see it you should have something similar to QNetworkAccessManager -- there is a single "manager" object that spits out HeatRecord objects (and possibly HeatMessage objects however I don't really see a use for them -- who cares whether a particular record was contained in message A or A+1?). When it does that it can emit a "hey, I just created a new HeatRecord object" or a "hey, I just created a new OutOfBandRecord object".
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  4. #24
    Join Date
    Jun 2012
    Posts
    219
    Thanks
    28
    Thanked 3 Times in 3 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Minimum required to emit a signal

    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.

    Qt Code:
    1. emit special_record(HeatMessage hm) ;
    To copy to clipboard, switch view to plain text mode 

    Versus something like:

    Qt Code:
    1. HeatMessage hm(msg);
    2.  
    3. emit new_message(hm);
    4. // new code follows:
    5. if (hm.oob_received())
    6. {
    7. emit special_records(hm);
    8. }
    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

  5. #25
    Join Date
    Sep 2011
    Posts
    1,241
    Thanks
    3
    Thanked 127 Times in 126 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Minimum required to emit a signal

    you can pass QObjects through signal/slots but you should do so by using pointer-to-QObject.

    That is not correct. They will always be correctly formed. Occaisonally, there will be additional records (e.g. when a lower level prototocol had to retransmit a packet because it didn't receive the expected ack) that will exist in the input data that aren't logically part of a HeatRecord or HeatMessage. They are of interest and will be displayed in a different widget
    And now I am more convinced that this data should be encapsulated in a different entity and not grouped with Heat[Record|Message]. You have just said that this data is separate to your record/message AND that it has a different purpose. It seems obvious to me that a new struct/class is desired.

    Creators of HeatMessage/HeatRecords would decide whether that signal is of interest and to what (if any Widgets).
    This dependency is backwards in one sense, and simply not necessary in another. The creator(s) should be agnostic of consumers (the tail should not wag the dog). The creators should make and emit the records. The clients should receive and do what they want with them. A dependency would be injected between the creator and the consumers to form the signal/slot connections - ensuring the creators/consumers are mutually agnostic.
    Last edited by amleto; 22nd February 2013 at 00:43.
    If you have a problem, CUT and PASTE your code. Do not retype or simplify it. Give a COMPLETE and COMPILABLE example of your problem. Otherwise we are all guessing the problem from a fabrication where relevant details are often missing.

  6. #26
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Minimum required to emit a signal

    Quote Originally Posted by davethomaspilot View Post
    I don't know what you mean by is "purely value based".
    I mean it has no identity. If you have two or more objects you can compare their data and say "yes, there are identical" or "no, they are different, because...". With identity-based objects no two objects are identical.

    There are methods in that class too.
    It doesn't matter. QColor also has methods but it is value-based (its role is to carry some value).

    Ok, sounds like the conclusion should be a signal that's generated just once is not worth doing?
    I really don't see any signal here. There is no "hey, I've just been created" signal since nobody has yet a chance to connect to it before it is emitted. If you access an object, it's no surprise it has been created.

    The idea was to make records available for consumption by unspecified (unspecified by the HeatMessage class) widgets.
    Emitting a signal does not make anything "available for consumption". If you have 10 slots connected to this signal, which one will "consume" the argument of the signal? If you want to make objects available for consumption then you provide a getter to fetch that object.

    Creators of HeatMessage/HeatRecords would decide whether that signal is of interest and to what (if any Widgets).
    It is contradictory with the nature of signals. A signal makes an object say "hey, something has happened to me" without checking if anyone cares about it or not.

    The signal would be in the HeatMessage (or HeatRecord) class. It would carry a HeatRecord object.
    So one HeatRecord would emit another HeatRecord? How would that work? Or would the HeatMessage do that? When would it do it? Take a piece of paper, draw a line representing the lifetime of your HeatMessage object, mark the place where the object is born, mark the place where it is emitted from whatever emits it and try to mark a point in time where it would emit information that it contains an OOB record. Then think what is meant to happen (in terms of code) between the time the message is born and the time when it emits this OOB record.

    Qt Code:
    1. emit special_record(HeatMessage hm) ;
    To copy to clipboard, switch view to plain text mode 

    Versus something like:

    Qt Code:
    1. HeatMessage hm(msg);
    2.  
    3. emit new_message(hm);
    4. // new code follows:
    5. if (hm.oob_received())
    6. {
    7. emit special_records(hm);
    8. }
    To copy to clipboard, switch view to plain text mode 
    I don't see HeatMessage emitting any signals here.

    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?
    You still don't get it. I'm not saying you shouldn't inform the environment about existance of a OOB record by emitting a signal, I'm saying you shouldn't be emitting it from HeatMessage because at the time you emit it, nobody has yet a chance to connect to that signal (which is a conclusion you should be reaching as a result of the piece of paper exercise). The OOB record IS or IS NOT, there is no situation that you parse a message and there is no OOB record but 1 CPU tick later it magically appears as part of the message object. It's either there from the very beginning of existance of that message object or it will never be in that object.

    1) You cannot pass objects derived from Qbjects (or QObject &) as an argument of a signal.
    False. You can't pass them by value and you shouldn't pass them by reference. You can pass by pointer but you have to make sure no slot connected to such signal tries to delete this object.

    2) You're recommending NOT creating signals, except if the signals would occur more times than just at object creation time?
    False. QThread::finished() is a one-time signal yet it's a perfectly valid one. I'm recommending not to emit signals from objects which are value-based (as opposed to identity-based).
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  7. #27
    Join Date
    Jun 2012
    Posts
    219
    Thanks
    28
    Thanked 3 Times in 3 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Minimum required to emit a signal

    you can pass QObjects through signal/slots but you should do so by using pointer-to-QObject.
    Yes, that's what I was trying to say. Which puts limitations on using them as arguments of signals, due to the private assignment operater in the Qobject as detailed earlier in the post

    And now I am more convinced that this data should be encapsulated in a different entity and not grouped with Heat[Record|Message]. You have just said that this data is separate to your record/message AND that it has a different purpose. It seems obvious to me that a new struct/class is desired.
    .

    Well, they are encapsulated in a separate list contained in the same HeatMessage classe. It just made sense to identify them as these "special" or "not mine" records in the same code that is categorizing each of the various HeatRecord types. (I still do). Sure, I could make that list in a different class, but that really isn't relevant to the signal/no-signal topic we're focusing on here. The records are available in the separate list, the signal was just a means to create an event that could be connected by anything interested in the fact these records were available.

    This dependency is backwards in one sense, and simply not necessary in another. The creator(s) should be agnostic of consumers (the tail should not wag the dog). The creators should make and emit the records. The clients should receive and do what they want with them. A dependency would be injected between the creator and the consumers to form the signal/slot connections - ensuring the creators/consumers are mutually agnostic.
    Hmm, nearly every Qt example I've seen does something like instance objects then connect signals from those objects. That's what I was doing. Versus making a direct call in the HeatMessage class. So, using a signal just sets "special records are in this HeatMessage, for anyone interested. Connection to be made by the code instancing the object (or anywhere else). The point is NOT to use a direct call in the HeatMessage class.


    Added after 10 minutes:


    Emitting a signal does not make anything "available for consumption". If you have 10 slots connected to this signal, which one will "consume" the argument of the signal? If you want to make objects available for consumption then you provide a getter to fetch that object.
    All 10. Getter methods are part of the object passed for any/all connected slots.

    1) You cannot pass objects derived from Qbjects (or QObject &) as an argument of a signal.
    False. You can't pass them by value and you shouldn't pass them by reference. You can pass by pointer but you have to make sure no slot connected to such signal tries to delete this object.[/QUOTE]

    Ok, understood. Not by reference since the referenced data may go out of scope before the slot code has a chance to access it, right?

    You still don't get it. I'm not saying you shouldn't inform the environment about existance of a OOB record by emitting a signal, I'm saying you shouldn't be emitting it from HeatMessage because at the time you emit it, nobody has yet a chance to connect to that signal (which is a conclusion you should be reaching as a result of the piece of paper exercise). The OOB record IS or IS NOT, there is no situation that you parse a message and there is no OOB record but 1 CPU tick later it magically appears as part of the message object. It's either there from the very beginning of existance of that message object or it will never be in that object.
    I'm saying you shouldn't be emitting it from HeatMessage because at the time you emit it, nobody has yet a chance to connect to that signa.
    Yes, I understood/understand that. Stating it differently, the issue is that the connect needs a pointer which isn't available until after the object is created.

    But what I'm doing now works and still creates a signal passing a value based object after that alue based object gets created. And, conditionally another signal is generated if the object has records matching a specified RegExp. Why signals? To be agnostic of what code (if any) is interested in that data.

    Why not?
    Last edited by davethomaspilot; 22nd February 2013 at 01:54.

  8. #28
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Minimum required to emit a signal

    Quote Originally Posted by davethomaspilot View Post
    All 10. Getter methods are part of the object passed for any/all connected slots.
    I do not understand this statement.


    Ok, understood. Not by reference since the referenced data may go out of scope before the slot code has a chance to access it, right?
    That's one of the cases, yes. Another is simply that you can't store a copy of a reference (which is what is required with cross-thread signal-slot connections) --- you'd get and modify a copy of the object (and we already know QObject can't be copied anyway).

    Yes, I understood/understand that. Stating it differently, the issue is that the connect needs a pointer which isn't available until after the object is created.
    I'm focusing more on logical issues, not technical ones. Even if you could get this pointer somehow (I believe the whole construction is possible to achieve), it simply wouldn't make any sense because the signal would have to be emitted right after the object was constructed because that's when it gets its info about the embedded OOB record. Since we already have a pointer to that object (because we just connected to it), we can simply query the object directly.

    But what I'm doing now works
    My favourite answer to that is that this works too:

    Qt Code:
    1. const char *txt = QByteArray("abc").constData();
    2. printf("%s\n", txt);
    To copy to clipboard, switch view to plain text mode 

    but it is not correct.

    Why signals? To be agnostic of what code (if any) is interested in that data.
    You are not becoming data agnostic just by putting signals here and there. With signals being agnostic means that one object doesn't care what other objects might do with a signal it emits and it has to work both ways -- the receiver can't care where its input data comes from. In your case you're emitting a signal for a specific purpose, so it is not agnostic.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  9. #29
    Join Date
    Jun 2012
    Posts
    219
    Thanks
    28
    Thanked 3 Times in 3 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Minimum required to emit a signal

    All 10. Getter methods are part of the object passed for any/all connected slots.
    I do not understand this statement.
    The HeatMessage class will have a method to get the list that contains records that match the specified Regexp. The HeatMessage object is passed as an argument of the signal. Slot code won't have to know about the byte layout of the HeatMessage, they execute methods of the passed object to get what they need and use to populate their own standard widgets, for example.

    You are not becoming data agnostic just by putting signals here and there. With signals being agnostic means that one object doesn't care what other objects might do with a signal it emits and it has to work both ways -- the receiver can't care where its input data comes from. In your case you're emitting a signal for a specific purpose, so it is not agnostic.
    Hmm, it seems to me there is value in the signal creator to not what is done (if anything) when that signal is emitted.
    being agnostic means that one object doesn't care what other objects might do with a signal it emits...
    I think emitting a signal does that and it's useful. If for no other reason, I can complete and test the code that instances the object and creates the signal before the data that processes the data sent by the signal is completed. Just because it "doesn't work both ways" doesn't mean it's no value to emit a signal, does it?

    And, the receiver (slot code) doesn't care where the data came from either. The same HeatMessage could come (and does) from a text file instead of a class data from a QSerialPort.

  10. #30
    Join Date
    Dec 2012
    Posts
    90
    Thanks
    5
    Thanked 20 Times in 18 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: Minimum required to emit a signal

    Your design is incorrect at a higher level, so you're trying to solve wrong problem.
    wysota suggests (as I have understood) more clean design:
    Qt Code:
    1. class NetworkManager {
    2. ...
    3. signals:
    4. void NewHeatMessage (HeatMessage msg);
    5. ...
    6. void ParseStream (QByteArray *data) {
    7. HeatMessage hm = form_message (data);
    8. emit NewHeatMessage (hm);
    9. };
    10. };
    11.  
    12. class DataConsumer {
    13. ...
    14. public slots:
    15. void ProcessHeatMessage(HeatMessage msg){
    16. while (msg.has_records ()) {
    17. HeatRecord hr = msg.TakeRecord ();
    18. do_stuff (hr);
    19. };
    20. };
    21. };
    22.  
    23. class DebugWidget {
    24. ...
    25. public slots:
    26. void DisplayOOB (HeatMessage msg) {
    27. if (msg.hasOOB ()) {
    28. do_display (msg.GetOOB ());
    29. };
    30. };
    31. };
    To copy to clipboard, switch view to plain text mode 

  11. #31
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Minimum required to emit a signal

    Quote Originally Posted by davethomaspilot View Post
    I think emitting a signal does that and it's useful
    You wanted to create an object, emit it and then delete it in a slot. It is everything but being agnostic.

    Nevertheless we still haven't seen what signals you wanted to emit from HeatMessage and when. I suggest you just try to do that and see for yourself if it works for you or not. So far you were just emitting HeatMessage and not emitting from HeatMessage.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  12. #32
    Join Date
    Jun 2012
    Posts
    219
    Thanks
    28
    Thanked 3 Times in 3 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Minimum required to emit a signal

    The design indicated by Lantz is close to what I have. The difference being that I issue two different signals, one for ALL heat messages that is connected to the equivalent of Data Consumer. The other signal is generated ONLY when these OOB records were discovered in the message during construction. This second signal may be connected to one or more different consumers.


    Qt Code:
    1. HeatMessage hm(msg);
    2. emit new_heat(hm);
    3.  
    4. if(hm.extra_records())
    5. emit extra_records(hm);
    To copy to clipboard, switch view to plain text mode 


    I was thinking I create the second, relatively rare signal in the HeatMessage constructor after a HeatRecord was added to the list, IFF the record matched a RegExp that was set up as class static data before construction any HeatMessages. (That's still possible, but clumsy, I think), Instead, what I have now looks at the HeatMessage after construction and sends the second signal only if those new type of records were seen in the HeatMessage.

    So, my original design (pre-new record types introduced) is unchanged, except new code is added to HeatMessage to recognize and save records of the new type, and a second signal is conditionally sent by the code that instances the HeatMessage.

    Yes, I was thinking of emiting the signal IN the HeatMessage construction, instead of after it was created. I agree it's better to do it after the object has been constructed. Wysota, does that adequately answer "Nevertheless we still haven't seen what signals you wanted to emit from HeatMessage and when?". Not sure how else to explain it.

    As far as being "everything but agnostic". Fine. So, what's the right term to use? A signal is available for connection by any interested client. Using a signal to that make sense to me for the reasons I've detailed. Having a second signal seems much better than sending EVERY message to clients who are only interested in record types that will very rarely be present in the message.

    Anyway, thanks for all the feedback.
    Last edited by davethomaspilot; 22nd February 2013 at 13:09.

  13. #33
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Minimum required to emit a signal

    Quote Originally Posted by davethomaspilot View Post
    Wysota, does that adequately answer "Nevertheless we still haven't seen what signals you wanted to emit from HeatMessage and when?".
    No, it doesn't explain it at all. I don't see any practical (or even theoretical) sense of emitting a signal from within a constructor.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  14. #34
    Join Date
    Jun 2012
    Posts
    219
    Thanks
    28
    Thanked 3 Times in 3 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Minimum required to emit a signal

    Ok, you don't see a good reason to do it "from a constructor" and I don't disagree. I was just trying to make sure I didn't leave out something you wished to see:


    "Nevertheless we still haven't seen what signals you wanted to emit from HeatMessage and when?".
    That seemed a little different than convincing you that it makes practical or theoretical sense of doing so.

    I agree, it's not a good idea.

    Your comment:

    being agnostic means that one object doesn't care what other objects might do with a signal it emits...
    Was that specific to when I was considering emitting the signal in the HeatMessage/HeatRecord constructor? Or, do you still think what I'm now doing is still not "agnostic"?



    Thanks,

    Dave Thomas
    Last edited by davethomaspilot; 22nd February 2013 at 13:40.

  15. #35
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: Minimum required to emit a signal

    Quote Originally Posted by davethomaspilot View Post
    I was just trying to make sure I didn't leave out something you wished to see:
    I thought this was the subject of this thread -- that you wanted to emit a signal from HeatMessage. If it is just an academic discussion, I don't see why we should waste more time on this.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  16. #36
    Join Date
    Jun 2012
    Posts
    219
    Thanks
    28
    Thanked 3 Times in 3 Posts
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: Minimum required to emit a signal

    Yes, that was the main thrust and what I was considering. I just wanted to make sure I wasn't missing something else important about my design. The comment about bad design, not agnostic, etc were specific to trying to emit a signal in the constructor.

    Thanks again.

Similar Threads

  1. Emit signal outside run() in QThread
    By naturalpsychic in forum Qt Programming
    Replies: 4
    Last Post: 26th March 2012, 17:31
  2. How to decide which SIGNAL to emit?
    By TheIndependentAquarius in forum Qt Programming
    Replies: 2
    Last Post: 22nd November 2011, 16:09
  3. Replies: 2
    Last Post: 3rd May 2011, 21:22
  4. how to know which button emit the signal?
    By coder1985 in forum Qt Programming
    Replies: 2
    Last Post: 12th January 2008, 15:26
  5. emit a signal
    By Morea in forum Qt Programming
    Replies: 2
    Last Post: 27th February 2006, 12:14

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.