Hey there! Let's break down the key differences between the two signal-slot connection approaches you're using, and why one might be working reliably while the other isn't.

1. Compile-Time vs Runtime Type Checking #

• Regular member function connections (whether using the old SIGNAL()/SLOT() macros or the newer function pointer syntax) depend on Qt's Meta-Object System (MOC). Macro-based connections only validate signatures at runtime—so subtle mismatches (like a missing const qualifier, or parameter types MOC doesn't flag) can lead to intermittent failures even if the connection returns a valid QMetaObject::Connection.
• Lambda-based connections are checked at compile time. The compiler will throw an error if the lambda's logic doesn't align with the signal's signature, eliminating runtime-only bugs. Since your lambda works, this confirms your Run() function's logic is solid—so the issue is tied to how the regular connection interacts with Qt's meta-object system or object lifetimes.

2. Handling Overloaded Signals #

QAction's triggered signal has two overloads: void triggered() and void triggered(bool checked).

• If you're using function pointer syntax for your regular connection without explicitly disambiguating the overload (e.g., connect(myAction, &QAction::triggered, classXInst, &ClassX::Run)), the compiler might accidentally pick the bool overload. While Qt will create a valid connection, the signal will only fire when the action's checked state changes—not on every click. That perfectly explains the "not always triggering" behavior.
• With a lambda, you explicitly handle the signal's parameters (even if you ignore them, like [this](bool){ classX->Run(); }), so there's no ambiguity about which overload you're connecting to.

3. Object Lifetime & Connection Context #

• Regular connections tie validity to the receiver object (your ClassX instance). If the ClassX instance is temporarily destroyed or moved (even if recreated later), the connection auto-disconnects. If your app has logic that invalidates the ClassX pointer between setup and the action click, this causes intermittent failures.
• Lambda connections give you more control over context. If you capture a smart pointer to your ClassX instance (e.g., [classXPtr](){ classXPtr->Run(); }) instead of a raw pointer, you ensure the object is alive when the lambda runs. Alternatively, if you don't specify a receiver, the connection is tied to the sender's lifetime, which might be more stable in your case.

4. Meta-Object System Dependencies #

For regular member function connections to work reliably, ClassX must have the Q_OBJECT macro in its header, and MOC must run correctly during compilation. Build issues (like MOC not picking up ClassX changes, or missing header includes) can lead to incomplete meta-object data—resulting in connections that look valid but fail to dispatch signals intermittently.

• Lambda connections don't require the receiver to have meta-object information (unless you specify a receiver), so they're far less sensitive to MOC-related build glitches.

Testing Your Scenario #

Given your lambda works consistently, the most likely fixes are:

1. Disambiguate the triggered overload in your regular connection:

   // Explicitly select the parameterless overload of triggered()
   connect(myAction, static_cast<void(QAction::*)()>(&QAction::triggered), 
           classXInstance, &ClassX::Run);
   

2. Double-check that ClassX includes the Q_OBJECT macro and that your build system runs MOC properly.
3. Verify your ClassX instance stays alive for the entire lifetime of the myAction menu item.

内容的提问来源于stack exchange，提问作者Don-Umbro