Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Help with logic



  • I know what I want to target aim of what I want to achieve I just don't know how to do it. My understanding of templates is still sketchy.

    What I want to do is:

    1. Connect signal to slot
    2. In the slot I emit another signal
    3. Connect the new signal to a lambda slot

    I can do all of the above, thats simple. However as an example, I have:

    if ( strSignal.compare(clsQtPushBtn::mscszQtSignalClicked) == 0 ) {
        cnSignal = QObject::connect(this, &clsQtPushBtn::clicked
                                   ,this, &clsQtPushBtn::rptrClicked);
    } else if ( strSignal.compare(clsQtPushBtn::mscszQtSignalPressed) == 0 ) {
        cnSignal = QObject::connect(this, &clsQtPushBtn::pressed
                                   ,this, &clsQtPushBtn::rptrPressed);
    } else if ( strSignal.compare(clsQtPushBtn::mscszQtSignalReleased) == 0 ) {
        cnSignal = QObject::connect(this, &clsQtPushBtn::released
                                   ,this, &clsQtPushBtn::rptrReleased);
    } else if ( strSignal.compare(clsQtPushBtn::mscszQtSignalToggled) == 0 ) {
        cnSignal = QObject::connect(this, &clsQtPushBtn::toggled
                                   ,this, &clsQtPushBtn::rptrToggled);
    }
    

    The above represents #1, now instead of a second lot of if conditions to achieve #2, what I would like to do is set-up pointers to the 4 parameters above, e.g.

    if ( strSignal.compare(clsQtPushBtn::mscszQtSignalClicked) == 0 ) {
            pSource = this;
            pfnSource = &clsQtPushBtn::clicked;
            pDest = this;
            pfnDest =  &clsQtPushBtn::rptrClicked;
    }
    if ( pSource ) {
    //This would connect the original signal to the signal specific slot
            cnSignal = QObject::connect(pSource, pfnSource, pDest, pfnDest);
    //The about slot emits the commonRptdSignal 
            QObject::connect(this,  commonRptdSignal, lamdbaSlot);
    }
    

    Its coming up with the types of pSource, pfnSource, pDest, pfnDest that I'm struggling with such that I can assign these in the "if" conditions.

    Can this be cone?



  • @mrjj the repeater slot isn't Lambda, the connection is as follows, using QPushButton clicked as an example:

     clicked -> rptrClicked
    

    The clicked signal originates directly from the QPushButton widget, the rptrClicked slot is defined in my derived QPushButton widget.

    rptClicked, constructs a JSON object and emits a common signal which is used by all repeater slots with a member array variable containing the original slot specific parameters.

    Then all I do is connect the common signal to anything that is interested in it.


  • Moderators

    @SPlatten said in Help with logic:

    Its coming up with the types of pSource, pfnSource, pDest, pfnDest that I'm struggling with such that I can assign these in the "if" conditions.
    Can this be cone?

    auto is your friend. See https://www.learncpp.com/cpp-tutorial/the-auto-keyword/ for example.

    My understanding of templates is still sketchy.

    How do templates fit into the equation?


  • Lifetime Qt Champion

    Hi
    I dont see how this can be possible with one lambda since some of the signals have parameters
    like

    connect(ui->pushButton, &QPushButton::toggled, this, [](bool p1){
    
    });
    
    


  • @mrjj , thats why I am connecting the original signal to a slot which has the specific arguments and acts as a repeater because it builds a common object and then emits a signal which is connected to the lambda slot.



  • @JKSH , I tried that before posting, it didn't help because the auto keyword has to be used when assigning, I cannot defined an auto outside of a conditional block, assign the auto variables then use them after the conditional block.


  • Lifetime Qt Champion

    @SPlatten said in Help with logic:

    @mrjj , thats why I am connecting the original signal to a slot which has the specific arguments and acts as a repeater because it builds a common object and then emits a signal which is connected to the lambda slot.

    So the repeater lambda wont have any parameters ?



  • Actually, I think I was thinking about it all wrong, there isn't actually a problem, since the original signals are connected to a slot that matches up with the signal in terms of parameters then all or those slots emit a common signal with the same parameters.

    Sorry, I was not giving it enough thought.


  • Lifetime Qt Champion

    @SPlatten
    Ah ok then it makes more sense.
    So normal signal to slot and then it also sends the signal to same lambda not using any parameters ?



  • @mrjj the repeater slot isn't Lambda, the connection is as follows, using QPushButton clicked as an example:

     clicked -> rptrClicked
    

    The clicked signal originates directly from the QPushButton widget, the rptrClicked slot is defined in my derived QPushButton widget.

    rptClicked, constructs a JSON object and emits a common signal which is used by all repeater slots with a member array variable containing the original slot specific parameters.

    Then all I do is connect the common signal to anything that is interested in it.


  • Lifetime Qt Champion

    @SPlatten `
    aha, i think i get it.
    So what you currently struggling with is saving the original connect paramters?
    And since you want a lambda, we cant just use SIGNAL and SLOT macros and store as char * ?



  • @mrjj , its taken a while but now I think I've got a solution which is easy to replicate and will provide me with a mechanism which is reusable for any and all signals.


  • Lifetime Qt Champion

    @SPlatten
    Ok cool :)



  • @JKSH , @mrjj , thanks for your help, I now have a working solution that I think is a big step forward.

    What I'm doing is:

    1. Create a class based on a Qt control, e.g. QPushButton
    2. In my derived class I connect all signals to internal repeater slots. Each repeater then creates a JSON object with the parameter differences that exist in each signal, the JSON also contains a timestamp of when the signal was received and the name of the signal.
    3. The repeater slot then emits a common signal with the JSON object as the sole parameter.
    4. The common signal is connected in the application is connected to all subscribers interested in the original control signals.

    This works great and now all I need to do is replicate this process for all the controls.

    Here is a sample of the Application Output from my rather verbose debug information:

    S00000000000000000087 Debug:simon2.js L00000049:-----clicked()-----
    S00000000000000000088 Debug:simon2.js L00000022:id(string): btn1
    S00000000000000000089 Debug:simon2.js L00000022:checked(boolean): true
    S00000000000000000090 Debug:simon2.js L00000022:sid(string): win1
    S00000000000000000091 Debug:simon2.js L00000022:signal(string): clicked
    S00000000000000000092 Debug:simon2.js L00000022:timestamp(string): 1595322480381

    The S number at the start of the line is the sequence number, always incrementing, then the type of message, the name of the script file, line number in the script file, then finally the message content itself, which in this case is just a dump of the JSON object received.


Log in to reply