Updating progress indicators during heavy processing

  1. ‹ Older
  2. last week

    Julian S

    Sep 11 Pre-Release Testers, Xojo Pro UK

    This is due to the portion of code:

    While PeekMessageW(Msg, 0, WM_NULL, WM_NULL, PM_REMOVE) > 0
      Call DispatchMessageW(Msg)
    Wend

    processing ALL queued messages due to 0 (WM_NULL) being passed to the Filter Min and Max. This will also include paints, so the portion of code above that is redundant as the paints will be processed by this loop anyway.

    I'd be interested to hear the result if you commented out the WM_PAINT while if you see any difference.

  3. Edited last week

    @Julian Samphire

    The MS-documentation is rather ambiguous about the use of the WM_NULL -type message.

    I suspect that the second while-loop still has a function to filter out WM_NULL -type messages,
    althought this contradicts the text in (some of) the documentation.

    However, it would make more sense that only when "Filtermin" is set to 0 (NULL) and "Filtermax" to
    the maximum allowed value, all messages would pass true.

    However, in the case as presented, still the Paint-type messages are processed (and removed)
    first.

    Perhaps I'll look at this in the debugger later.

  4. Julian S

    Sep 11 Pre-Release Testers, Xojo Pro UK

    "If wMsgFilterMin and wMsgFilterMax are both zero, PeekMessage returns all available messages (that is, no range filtering is performed)."

  5. Julian S

    Sep 11 Pre-Release Testers, Xojo Pro UK

    Just for clarity for anyone else reading this at a later date, you can cause similar issues using this PeekMessage method than you can using DoEvents especially with a hWnd of 0, I'd suggest its used with caution unless you know exactly what you're doing.

  6. @Julian S

    Sorry for the late reply, but It proved to be a bit tricky to start the relevant debuggers (Delphi and OpenWatcom) to have a closer look at what happens at the assembly level for the different methods (ProcessPaintRequests, (Delphi: ProcessMessages and HandleMessage) etc.).

    It look likes the two loops in ProcessPaintRequests only form a subset of the low-level procs called in the two other situations.

    As I am quite sure that veteran Peter would have only presented a method that has been proven to work during long time, I have confidence in it.

    But, as always, the proof of the pudding is eating it !

  7. Julian S

    Sep 12 Pre-Release Testers, Xojo Pro UK

    @J HTimmerman So it is unlikely that it will cause instability-issues like DoEvents and the like.

    Just because some "veteran" guy posts this on a forum on the internet for a different language doesn't mean that its the best fit for everyone in this language, it CLEARLY processes the whole message queue with its double 0 min/max filter which seems contrary to what this "veteran" internet guy claims or thinks it does. It does NOT clear off or process off the WM_NULL events from the queue which it seems he is thinking it does (as is documented in his comment on that link you posted), it processes the entire queue. It is bad form for this internet guy to share code like this without knowing what it does, its even worse to post it on saying it must be good because some random guy says its good. People also used to drink from lead pipes until they knew better.

    Processing a message queue in this way could allow the user to reenter the same piece of code that is currently running potentially causing a variety of issues including race conditions, out of sequence states or stack overflows.

    As with DoEvents, use this code with EXTREME caution, it most certainly isn't a silver bullet but if it works for you and you haven't come across any issues yet then happy days I guess :)

  8. Michel B

    Sep 12 Pre-Release Testers, Xojo Pro RubberViews.com
    Edited last week

    We have two tried and true methods to update the UI from intensive processing that are cross platform described here.

    That should be enough, without amazingly enough, some Delphi unproven advice coming from nowhere.

  9. Robert B

    Sep 12 Pre-Release Testers, Xojo Pro University of Connecticut

    Since I was the one who recommended using DoEvents I should also admit to not using it anymore in those applications that are not internal. But I have never, ever had an app crash on me for using it. During a previous discussion of app.doevents in this forum, someone explained why it could be used safely under various circumstances. What we need is a refresh statement that actually works so we are not forced to use threads to do something an intelligent framework could do for us.

  10. Michel B

    Sep 12 Pre-Release Testers, Xojo Pro RubberViews.com
    Edited last week

    I believe the interdiction to use UI from a thread stems from the future implementation of multi core threads.

    But in the instance described here, the issue is not the thread, it is the fact that the UI precisely could not be refreshed until an event had completed.

    I frankly don't know if bypassing that limitation is even possible.

    I do know that breaking up execution in a timer, or putting the unchanged code in a thread works, with a minimum of fuss.

  11. Tim P

    Sep 12 Pre-Release Testers Rochester, NY

    @Robert B During a previous discussion of app.doevents in this forum, someone explained why it could be used safely under various circumstances.

    Do you have a link to this post? As far as I can remember, Xojo Staff have said never to use App.DoEvents in desktop apps.

  12. Robert B

    Sep 12 Pre-Release Testers, Xojo Pro University of Connecticut

    @Tim P Do you have a link to this post? As far as I can remember, Xojo Staff have said never to use App.DoEvents in desktop apps

    I am looking for it now.

  13. Michel B

    Sep 12 Pre-Release Testers, Xojo Pro RubberViews.com
    Edited last week

    All I could find is

    https://forum.xojo.com/10498-making-the-case-to-remove-app-doevents

    Among other discussions of the same nature.

  14. Michael D

    Sep 12 Pre-Release Testers, Xojo Pro
    Edited last week

    I solved this problem in a much easier way: I made thread-safe version of the ProgressBar control. It basically has methods or properties that override the built-in ones, and has logic to hangdle thread vs. non-thread context.

    It's super easy, and a great solution for when you need to update existing code.

    Here's an outline of how it works:

    Class cProgressBar
    funciton Value(assigns newValue as integer) 
        if newValue = mValue then
           return ' nothing changed
       end if
       if app.currentThread = nil then 
             Super(me).value = newValue  ' in the main thread, so just assign it directly
            return
       end if
       ' otherwise, we are in a thread, so do this using our timer
       mValue = newValue
       mTimerUpdate.mode = Timer.ModeSingle
    end

    WIth this in place, you can do things like this:

    Thread1.Run
       for i as integer = 1 to 100000
          self.ProgressBar1.Value = i
       next
    End
  15. Robert B

    Sep 12 Pre-Release Testers, Xojo Pro University of Connecticut

    Tim, Here is the discussion I was looking for. Do a search for "Cases where App.DoEvents would be used" in General.

  16. Sascha S

    Sep 12 Pre-Release Testers, Xojo Pro Germany, Lower Saxonary

    @Robert B Tim, Here is the discussion I was looking for. Do a search for "Cases where App.DoEvents would be used" in General.

    Or click here ? ;)

  17. Tim P

    Sep 12 Pre-Release Testers Rochester, NY

    @Robert B Tim, Here is the discussion I was looking for. Do a search for "Cases where App.DoEvents would be used" in General.

    I appreciate the information, I really do. I spend all day working with Xojo, so I have an interest in knowing the ins-and outs of the framework. However, I'm not quite sure how you got the idea that App.DoEvents was safe from that discussion.

  18. Norman P

    Sep 12 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    @Tim P Do you have a link to this post? As far as I can remember, Xojo Staff have said never to use App.DoEvents in desktop apps.

    I believe Tim Jobes once described a usage to Joe Ranieri about how he was using DoEvents and it was actually determined that this limited case was OK
    I believe, but could be misremembering, that using DoEvents when you are already showing a modal dialog is ok since that does not call the main event loop but runs the modal dialogs event loop

    Damned if I can find the conversation though

  19. 7 days ago

    @Michel B

    Simple methods like Peter's are usefull and can be tested easily.
    If undesirable side-effects are detected, one can be sure they will appear on this or related fora soon. But, until a practical case is shown that disproves the usability it should be tested...

    Unlike in mathematics, in information science only very simple algorithms/procedures can be proven to be correct;
    know your Knuth ! On a logical level only algorithms like Dijkstra's ... Certainly not any of the procedures given in discussion fora ...

    The source of the Delphi forum is a renowned veteran user, who certainly would not present a method he wouldn't have tested long ago and exhaustively.

    On a low level (translation to assembler, and even more, the dependency on API-functions of the OS) different programming languages on the same platform are still quite similar. So if the procedure "works" in one language, it it quite likely to work
    in other situations to, if adapted. But a counterexample could prove this to be false of course.

    You are certainly right that the method, as presented, is not cross-platform. But that doesn't mean it should be (theoretically) impossible to adapt it to other platforms, as there is a similarity in underlying mechanisms of message-processing.
    The question is more: is the need there, or is it's manifestation (of problems) different?

    (side note: I tested a few small programs that, in Windows, without ProcessPaintRequests, had some problems with updating the UI. But in my trusted OS/2 4.52 -version inside VirtualBox, they had no problem if recompiled for OS/2 there. Go figure ...)

  20. Michel B

    Sep 12 Pre-Release Testers, Xojo Pro RubberViews.com
    Edited 7 days ago

    @J HTimmerman Simple methods like Peter's are usefull and can be tested easily.
    If undesirable side-effects are detected, one can be sure they will appear on this or related fora soon. But, until a practical case is shown that disproves the usability it should be tested...

    You are amazing, Sir. You make allegations based on a post in a forum about Delphi. No matter the respectability of Peter Below, the irrefutable weight of Donald E. Knuth published books, what you are talking about so far is whimsical non existing Xojo code.

    I enjoy a discussion about metaphysics like any other, but until you post here practical, working Xojo code using Peter Below's principle, I am sorry, but I refuse to talk about non existent code, and whether it should be disproved, since it does not exist.

    Please make the effort to implement the principles you believe in, post the result here, and I will be glad to talk about them.

  21. Dana B

    Sep 12 Xojo Inc Austin, Texas
    Edited 7 days ago

    Locking this, if you still have more questions please start a new thread

or Sign Up to reply!