No announcement yet.

Mystery of Shrinking Resources

  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Thanks, Russ. There seem to be a lot of possibilities. I don't
    use the timer in my program, so that's probably not my bug.

    I think I've narrowed down the problem similar to the one you
    describe, though, but I'm still trying to find a way to trap or
    prevent it. It seems that when a child dialog (call it Dialog2
    Dialog3) is left open at the time I exit the program, if I exit
    the program by clicking on my "QUIT" button or "EXIT" on the
    File Menu, I can successfully trap that situation by using
    DIALOG END Dialog2, etc., so that the program terminates cleanly.

    However, if I exit by double-clicking the System Menu box while
    Dialog2 or Dialog3 is open, I get the same kind of "dirty" exit
    you describe. Strange. I've tried trapping the %WM_CLOSE
    message, inserting a "Are you sure you want to quit?" message
    box, and, if confirmed, using DIALOG END for any open child
    dialogs, such as Dialog2, but that seems to have no effect.

    Yet another mystery for a newbie programmer, who's only been
    at this about 8 months. I'm tempted to just get rid of the
    System Menu boxes, although that's probably considered to be
    non-kosher, and seems a bit like throwing out the baby with the



    • #22

      Some messages for closing a Dialog come through the WM_SYSCOMMAND
      (%SC_CLOSE) message rather than the WM_CLOSE message. Try checking
      it too.

      Also, if a Dialog is a Child (floats above its parent) then when its
      parent Dialog is closed, Windows should automatically close the child.

      Also, assuming the main dialog is modeless, you should have a message
      pump loop in PBMain that tests for the number of active Dialogs, so
      the app doesn't terminate until all the Dialogs have been destroyed.

          ' use this code in PBMain
              DIALOG DOEVENTS TO Count&
          LOOP UNTIL Count&=0
          ' app can now terminate by exiting PBMain

      Chris Boss
      Computer Workshop
      Developer of "EZGUI"


      • #23
        ' use this code in PBMain
        LOOP UNTIL Count&=0
        ' app can now terminate by exiting PBMain

        Ah, got it, finally. (Cogito.) However, I've been using a
        modal main dialog, since I contrived to use a (hidden) modeless
        dialog to run the moving stock ticker in my simulation, until a
        user clicks on something and triggers an exit from the DOEVENTS
        loop, and thus halts the ticker.

        I was hesitant to try to use a second DOEVENTS loop in my main
        dialog, since I was unsure of whether it was possible to have
        two DOEVENTS loops running at once. But I assume you mean to
        put the above loop in PBMAIN to run only AFTER ending the main
        dialog? (Or does that cause a problem if all dialogs are closed
        at that point, as the PB/DLL manual suggests? "DO NOT call
        DIALOG DOEVENTS unless at lest one dialog created with DIALOG
        NEW is active." I.e., meaning it must be part of the main
        dialog itself?)



        • #24

          A Windows app only needs one Message Loop !

          Following SDK style message loop coding, I use the simple Doevents
          loop described above, the same way I do a message loop in SDK style

          You create your main dialog first (in PBMain) and then execute the
          doevents loop (see above). You don't need any more doevents loops.

          You should (IMO) make the first Dialog modeless and then others can
          be either modeless or modal. When you use a modal dialog, it won't use
          the Doevents loop in PBMain. It will use a separate message loop
          generated by Windows itself (if DDT uses the Window modal engine).

          Chris Boss
          Computer Workshop
          Developer of "EZGUI"


          • #25
            Mystery solved.... Sort of. I "fixed" the disappearing resources
            problem (or at least reduced the "leakage" to virtually nil, even
            after 4 or 5 hours of running the simulation hard). But don't
            really have a good explanation for the fix. All I changed was
            as follows:

            Before I changed it, my stock market/takeover simulation ran
            a simulated stock ticker, which it "printed" to a label control
            on all 3 of the main program screens, whether or not all of them
            were visible to the user. I simply modified the code that
            updates the ticker controls so that only the VISIBLE screens
            (usually 1, sometimes 2) are updated several times per second,
            to create the illusion of a moving stock ticker on each.

            It seems that updating all 3 screens (dialogs), even when some
            were no longer in existence, somehow caused a steady and major
            loss of Windows resources (of all 3 types, GDI, User, and System).
            Updating only the visible dialogs seems to have halted about
            99% of the "leakage." Wish I had a clearer answer, but thanks
            for all the input, anyway, guys.



            • #26
              I couldn't tell from your post whether the other dialogs were just
              hidden or they didn't exist, when not visible.

              If the they didn't exist, when not visible, you would definitely have a
              problem, since the handles no longer are valid (for the Dialog).

              You would be sending erroneous messages to handles which could
              now possibly be assigned to a new window or control (I am sure Windows
              reuses handle numbers once they are available again).

              It is possible to send messages to hidden Dialogs/Controls so I doubt
              that would be a problem, unless the label control doesn't like
              being inundated with messages when it is hidden.

              Chris Boss
              Computer Workshop
              Developer of "EZGUI"


              • #27
                That all sounds logical Chris. Good programming practice indicates that you should track your active and destroyed controls, and only send messages to the active ones.

                For example, suppose that you use global variables to track the handles of these controls, it is a simple matter to set these variables to zero when the controls are destroyed (say, during %WM_DESTROY in the dialog callback) and test the variable before sending a message.
                GLOBAL hControl1 AS LONG
                GLOBAL hControl2 AS LONG
                GLOBAL hControl3 AS LONG
                IF hControl1 THEN _
                  SetWindowText hControl1, "the text" ' or send %WM_SETTEXT, etc
                CASE %WM_INITDIALOG
                  CONTROL GET HANDLE CBHNDL, %ID_CONTROL1 to hControl1 
                CASE %WM_DESTROY
                  hControl1 = 0
                BTW, a little tip for you:
                when sending messages to a control using it's handle (rather than CONTROL SEND using it's ID), you can use DIALOG SEND:

                For example:
                CONTROL ADD LABEL, hDlg&, 100, "Btn1", 10, 10, 80, 14
                CONTROL HANDLE CBHNDL, 100 TO hCtl&
                a$ = "new text"
                DIALOG SEND hCtl&, %WM_SETTEXT, 0, STRPTR(a$)
                PowerBASIC Support
                mailto:[email protected][email protected]</A>
                mailto:[email protected]


                • #28
                  Ah, yes, thanks Chris, and Lance.

                  As you point out, Chris, that's probably what was wrong
                  in my program, as I was not bothering to determine if the
                  2nd and 3rd dialogs I was simultaneously sending stock ticker
                  strings to were active, destroyed, or not even created yet for
                  a first time. The remedy I used was as you suggested, Lance,
                  to use GLOBAL on/off variables to keep track of the 3 dialogs,
                  and only send text to the "live" ones from my stock ticker SUB.
                  Which seems to have cured the problem.

                  In any case, thanks for all your help and suggestions. The
                  "bleeding" has stopped, and the torpedoes are running hot,
                  straight, and normal now, so to speak.