• (disco)

    I guess it's better than

    Last message repeated 0 times
    

    and having to click through hundreds of those...

    Filed under: Just give me the error log

  • (disco)

    Oh I just love the smell of race conditions in the morning.... (rimshot)

  • (disco) in reply to Yazeran
    Yazeran:
    I just love the smell of race conditions in the morning
    Ah yes; the scent of the morning dew infused with a hint of petrol-

    Oh, wait, you're not talking about that sort of racing.

  • (disco) in reply to RaceProUK
    RaceProUK:
    Ah yes; the scent of the morning dew infused with a hint of petrol-

    don't forget that subtle petrichor of damp tarmac.

    that's important too!

  • (disco)

    So close yet so far away

  • (disco)
    SomeClass::eventHandler(Event e) {
    

    Ok...

    QMessageBox::warning(this, tr("App"), tr("Error message"));
    

    Wait... Is that a custom Event class, poor anonymization, or is my knowledge of Qt worse than I thought? There's a QEvent that represents a OS event but it's fairly useless in its base form. Is this supposed to be a slot modified to look more .NET-ish for general public?


    Filed under: :pendant:

  • (disco) in reply to Yazeran

    The smell, you know that gasoline smell, the whole hill. Smelled like... victory.

  • (disco)

    I have no idea why the code is failing. Can someone explain to me what went wrong?

  • (disco) in reply to Gaska

    My bet is on the static bool in there.

  • (disco) in reply to Rhywden

    And what's wrong with it?

  • (disco) in reply to Gaska

    Multiple events at the same time?

  • (disco) in reply to Rhywden
    Rhywden:
    My bet is on the `static` bool in there.

    I'm no expert in.... C++ i think? whatever...

    anyway, I won't claim to be an expert but that static bool looks suspiciously like a function local variable to me....

  • (disco) in reply to Rhywden
    Rhywden:
    Multiple events at the same time?
    Single-threaded or multi-threaded? Because in the former case, everything should work as expected, and in the latter case, it should be very rare for two popups to show, and virtually impossible for three. I must be missing something here.
  • (disco) in reply to accalia
    accalia:
    Rhywden:
    My bet is on the `static` bool in there.
    I'm no expert in.... C++ i think? whatever...

    anyway, I won't claim to be an expert but that static bool looks suspiciously like a function local variable to me....

    If this was Java, then `static` would preserve the value of the variable between method calls; I don't know if it does the same in C++.

    Of course, if QMessageBox::warning() is async, the whole static thing is :cow: anyway.

  • (disco)
    Gaska:
    I have no idea why the code is failing. Can someone explain to me what went wrong?

    E_NOT_ENOUGH_INFO

    As I said, the prototype seems heavily anonymized. I never played with anything other than auto connections but

    Gaska:
    Single-threaded or multi-threaded?

    Might be very important, given this:

    http://doc.qt.io/qt-5.5/qt.html#ConnectionType-enum

    Then again, we don't even know if it's a slot at all. If the prototype is verbatim that would indicate some kind of custom event handling, and in that case it's all up in the air at that point.

  • (disco) in reply to Rhywden

    Shoulnd't a queue serialise stuff ? (ok, its depends on the queue, o know)

  • (disco)

    Uh oh.... did someone apply TLS?

  • (disco) in reply to Gaska
    Gaska:
    I have no idea why the code is failing. Can someone explain to me what went wrong?

    The dev wants the message box to pop up only when the function is called the first time. He initializes a static bool to false. If it's false, the message box will pop up; if it is true, it won't. After this check, he sets it to true so that the message box will not pop up in the future. The bug is that he sets it back to false, so that the message box will pop up every time.

  • (disco)

    It really depends on weather this runs single or multi-threaded. If it's single, then there will be a popup for every message because the event will only be called for the next queued message after the user dismisses the existing popup. If it's multi, then the static bool should me marked volatile, so that multiple simultaneous calls to the function don't get a cached (wrong) value, which would also cause multiple popups.

  • (disco) in reply to Zybex

    static volatile just sounds really weird to me

  • (disco) in reply to NedFodder
    NedFodder:
    The dev wants the message box to pop up only when the function is called the first time. He initializes a static bool to false. If it's false, the message box will pop up; if it is true, it won't. After this check, he sets it to true so that the message box will not pop up in the future. The bug is that he sets it back to false, so that the message box will pop up every time.
    Correct me if I'm wrong, but doesn't showing up a message box in Qt pauses execution of current thread until the box is closed? I'm pretty sure it does, since I think I did it myself several times.
  • (disco) in reply to Zybex
    Zybex:
    It really depends on weather this runs
    Good luck trying to debug the weather!
  • (disco)

    The static bool is actually a pretty standard way to prevent reentrancy, where you don't want the function to call itself and potentially recurse infinitely.

    For example, when I was doing development for console games, we had a custom assertion handler that went into its own little modal rendering loop to render a red screen with the assertion text on it. So if an assertion failed somewhere in the game, QA would be able to see the failure on their screen (and not have to deal with terminal output or log files) and report the bug. In the unlikely event that another assertion failed while the modal rendering loop was running (say, due to out-of-memory), then it would avoid going into another modal loop on top of that and just do its normal logging behavior before halting. It looked roughly like this:

    void OnAssertionFailed(const char *expression, const char *filename, int line) {
        // Logging etc.
        fprintf(logFile, "Assertion failed...");
        OutputDebugString("Assertion failed...");
        
        static bool inOnAssertionFailed = false;
        if (!inOnAssertionFailed) {
            inOnAssertionFailed = true;
            while (!buttonHasBeenPressed()) {
                RenderRedScreen("Assertion failed...");
            }
            inOnAssertionFailed = false;
        }
        
        abort();
    }
    

    Of course, assertion failures are always synchronous. In the case of this article though, I'd assume that events can be async, in which case multiple copies of the event can be queued up before the event handler runs. Since the event handler runs completely before handling the next queued event, the static bool doesn't stop those subsequent queued events from being handled — it would only work properly if QMessageBox::warning() triggered more events and dispatched them synchronously (which would be an even bigger :wtf:).

  • (disco) in reply to Gaska
    Gaska:
    Correct me if I'm wrong, but doesn't showing up a message box in Qt pauses execution of current thread until the box is closed? I'm pretty sure it does, since I think I did it myself several times.

    I think you're right there. I need to play more with widgets in Qt, my knowledge of its UI layer is fairly basic. I just write backend stuff in it, and I poked around Quick a bit..

  • (disco) in reply to Gaska
    Gaska:
    Good luck trying to debug the weather!

    It's not too hard if you have the right gadget:

    https://what.thedailywtf.com/t/weather-simulator-wtf/51581/1

  • (disco)
    this, tr("App")
    

    This is a trap!

  • (disco) in reply to Maurizio_De_Cecco

    Shoulnd't a queue serialise stuff ? (ok, its depends on the queue, o know)

    I guess that's exactly the problem. The event handler blocks until the user closes the message box. Then 'showingError' is set back to false and the handler returns. The next event will then be handled. And since the 'showingError' boolean is now false again, it shows the box again.

  • (disco) in reply to littlefreaky36

    So TRWTF is lack of even basic testing. Even in form of manual, one-time exercise to see if the code works as expected.

  • (disco) in reply to Gaska

    Oh, they probably did test it.

    With a queue of one.

  • (disco) in reply to RaceProUK

    Ok, Sorry, but you (sorta) asked for it...........

    If you are getting the smell of burnt rubber in the morning, then you are..... wait for it.....Doing It Too Fast™ :rimshot: :grimacing:

  • (disco) in reply to pittsfield

    Obligatory meme with added :wtf: [image]

    ...or is it?

  • (disco) in reply to RaceProUK
    RaceProUK:
    If this was Java, then static would preserve the value of the variable between method calls; I don't know if it does the same in C++.

    It does. You'll should never get 2 errors up at the same time!

  • (disco) in reply to Gaska

    Looks like C++, so assuming that's the case:

    When a function local variable is declared static, this means that the variable persists across calls. The initialization only runs the first time the function is called. So you could initialize the variable as false, set it to true, and then when you next call the function its value will be true.

    NedFodder:
    The bug is that he sets it back to false, so that the message box will pop up every time.
    Mostly. If you removed setting it to false, then you would only ever show the message box *once* in the whole run of the program. There's no way to alter the state of a static local variable outside of the function, so you have no way to signal "ok, the user saw the message for all these errors, reset so we can show a message the next time something happens".

    Which is why I would imagine it is reset at the end in the first place. The genius here probably saw that he was only ever showing one message and realized he had to reset the flag for the next message.

    The bug is using a local static in the first place. The flag should be stored somewhere you can get at when you want to flip it.

    Zybex:
    It really depends on weather this runs single or multi-threaded.
    Not at all. Race conditions could cause a handful of message boxes to pop up, but not four minutes worth of them. A single threaded app with this bug will queue every warning instead of collapsing them.
  • (disco) in reply to RaceProUK
    RaceProUK:
    If this was Java, then static would preserve the value of the variable between method calls; I don't know if it does the same in C++.

    It does; but it doesn't do it in Java.

  • (disco) in reply to Spectre

    Huh. Musta been thinking of something else then.

  • (disco) in reply to RaceProUK
    RaceProUK:
    If this was Java, then `static` would preserve the value of the variable between method calls; I don't know if it does the same in C++.

    If this was Java, it wouldn't compile. C++ allows static to be used in 3 different contexts:

    1. In front of a class member or method declaration (making the member/method effectively have global scope but within the class's namespace)
    2. In front of a global function (giving it internal linkage instead of external linkage)
    3. In front of a local variable declaration (giving it static storage duration instead of automatic storage duration)

    The usage here is context #3, but Java only allows static to be used in context #1.

  • (disco) in reply to Protoman

    Hello Mister Fifteen-Minutes-Late! :wave:

Leave a comment on “A Handle on Events”

Log In or post as a guest

Replying to comment #:

« Return to Article