PLEASE help me with C++ code analysis

[Anonymous_Banned275]

Please accept my apology for this post.
I am looking for somebody who understand " connect" application in C++ code.
I am looking for help in ANALYSIS of my attempt to replace "switch" with "connect".

I am familiar with "passing parameters " to "connect" "receiver'.
It my interpenetrations that i"connect" is similar to "switch".
I have my code working using "switch" and I am trying to learn more about "connect" by replacing the switch.

The attached code should replace SINGLE level switch and provide necessary "connect".

I believe my "problem" is in placing the "connect " into the "index" loop....

PS
keep in mind this is "under construction" code and does contain "some junk" which needs to be ignored.

{// function block
            // main list is NOT an array
            for (index = 0; index < list.size(); ++index)
            {

#ifdef ARRAY
                text = Q_FUNC_INFO;
                text += "  @ line  ";
                text += QString::number(__LINE__);
                text += "  TASK  START main loop...";
                text += " list.size ";
                text += QString::number(list.size() );
                qDebug() << text;

                text = list[index];
                qDebug()<<text;
#endif
                { // // main menu process block
#ifdef ARRAY
                    text = " main menu process block ";
                    qDebug() << text;
#endif
                    // build main submenu TOK
                    subMenu[index]  = m_ui->menuWindow_cpntrol;
                    // adds main menu with arrows
                    subMenu[index] = subMenu[index]
                            ->addMenu(list[index] + " # " + QString::number(index));
                    mainAction[index] = subMenu[index]->menuAction();  // TOK

                } // main menu process block

                // common stuff
                QAction* tempAction = new QAction(); //  text , this);
                tempAction->setCheckable(true);


                { // real connect block
                    // connect to subMenu
                    //connect(subMenu[index], &QMenu::triggered, this ,[=]() { this->processMenu_NoParameters() ;});
                    //    connect(subMenu[1], &QMenu::triggered, this ,[=]() { this->processMenu(index,index_sub) ;});
                }

                { // connect block
                   {// signal mapper code block

                    } //   signal mapper code block
                }// connect block
                { // replace switch
                    connect(subMenu[index],&QMenu::triggered, [=]() {
                    emit  this->ProcessAction_Menu(index,index_sub);});
                    //break;


                } // replace switch
                { // bypass block }
#ifdef BYPASS
//                connect(subAction[index_sub],&QAction::triggered, [=]() {
//                   emit  this->processAction(index,index_sub);});


                // switch block
                switch(index)
                { // switch
                case 0:
                {
   //                 connect(subAction[index_sub],&QAction::triggered, [=]() {
   //                    emit  this->processAction(index,index_sub);});


                    ProcessCase(0); // TOK

   //                 connect(subAction[index_sub],&QAction::triggered, [=]() {
   //                    emit  this->processAction(index,index_sub);});

                    break;
                }// case 0 process block
                case 6:
                {
                    ProcessCase(1); // TOK
                    break;
                }// case 0 process block

                case 5:
                {
                    ProcessCase(1); // TOK
                    break;
                }// case 0 process block


                case 4:
                {
                    ProcessCase(1); // TOK
                    break;
                }// case 0 process block

                case 3:
                {
                    ProcessCase(1); // TOK
                    break;
                }// case 0 process block

                case 2:
                {
                    ProcessCase(1); // TOK
                    break;
                }// case 0 process block

                case 1:
                {
                    ProcessCase(1); // TOK
                    break;
                }// case 1 process block

  //                  connect(subAction[index_sub],&QAction::triggered, [=]() {
  //                     emit  this->processAction(index,index_sub);});


                } // switch

 //               connect(subAction[index_sub],&QAction::triggered, [=]() {
 //                  emit  this->processAction(index,index_sub);});


#endif
  } // bypass block }
            }// main loop
//            connect(subAction[index_sub],&QAction::triggered, [=]() {
//               emit  this->processAction(index,index_sub);});
//            connect(subAction[index_sub],&QAction::triggered, [=]() {
//               emit  this->processAction(index,index_sub);});


        }

[Pl45m4]

@AnneRanch said in PLEASE help me with C++ code analysis:

"switch" and I am trying to learn more about "connect" by replacing the switch.

switch-case and connect are two diffeerent things and I don't know how one should replace the other?!

[Axel Spoerl]

@AnneRanch
Please do not ask the same question in multiple posts.
Instead of this, please stay responsive to those posts, where people are actually trying to help you solve your issue.

https://forum.qt.io/post/787973
https://forum.qt.io/post/787937
https://forum.qt.io/post/787630
https://forum.qt.io/post/787561
https://forum.qt.io/post/787267
https://forum.qt.io/post/787203
https://forum.qt.io/post/787126
https://forum.qt.io/post/786835

[Axel Spoerl]

@AnneRanch
...and can you tell us, why you delete those of your previous posts, where you elected, not to answer questions of voluntary contributors who tried to help you?

[Anonymous_Banned275]

@AnneRanch UPDATE

Here is my current ,working code.
It works in two steps
connect detect the trigger and ProccessAction _Menu uses "case" to process desired object.

What I am asking is

how can I "improve the code by replacing the case".

I was going to use "signal mapping" but
a) it is deprecated
b) I do not see how it would make for less code lines.

Basically each desired object is activated with "hard codded" , not vairiable code.

                                        connect(subMenu[0],&QMenu::triggered, [=]() {
                                            emit  this->ProcessAction_Menu(0,0);});

                                        connect(subMenu[0],&QMenu::triggered, [=]() {
                                            emit  this->ProcessAction_Menu(0,1);});

                                        connect(subMenu[0],&QMenu::triggered, [=]() {
                                            emit  this->ProcessAction_Menu(0,2);});

[Axel Spoerl]

@AnneRanch said in PLEASE help me with C++ code analysis:

What I am asking is
how can I "improve the code by replacing the case".

There is no "case" to be replaced in the code you posted.
As said many times before, you are not handling the iteration over your arrays correctly, which is why it works when you hard code the array index and it doesn't when you don't.

As for the code analysis:

• The emitkeyword in your lambda is redundant.
• The parts of the code where you populate the array and the broken iteration are missing. If you don't show all relevant code, you won't get help.

[JonB]

@AnneRanch
The code, as shown, cannot be right, because it attaches 3 different lambdas --- each passing a different number for the second parameter --- all to the same subMenu[0] item being triggered.

I believe your case is that you have several menu/submenus/actions, which can be triggered and you want to act on which one was triggered. You have just two "and a half" basic choices as to how to achieve this:

• You can pass parameters to the lambda which give the index(es) of the item/action being triggered. There will only be one ProcessAction_Menu(...) method to handle all these cases, but you will connect() each one with the correct parameters to indicate the index(es). You must get this code right. Then when your slot receives these parameter(s) you will likely have a switch statement or two so you can go "if it is the 2nd item on the top menu and the 3rd item on its submenu then perform such and such".

• "Half choice" (similar-ish in principle to first point): instead of passing the *indexes", use something like setProperty() on the QAction to associate a "meaningful string" with each QAction. Examine that in the (single) slot attached to all items and decide what to do accordingly. Again, this routes all action triggers through a single method, so you will have a lot of ifs (like a switch) to handle each case.

• If you say you want to eliminate such switch statement(s) then do away with passing parameters about which index(es) or a string-property completely. Write a separate slot method, with a suitable name, on behalf of each individual action, no matter where it is the menus. connect() each menu action trigger to the exact, individual slot you want it to execute. Now you don't have to use switch-type code (but you have multiple slots instead).

[Anonymous_Banned275]

@JonB Sorry, the code is a TEST "pointing" to same task... It looks as there is no way to skip "two level" code - either using "connect " and "switch" or multi slot approach with each "connect" a slot to task.
Actually the idea was silly from get go. It is just a matter which will be easier to add / maintain.
Thanks for your comments, appreciate your very constructive help.