Announcement

Collapse
No announcement yet.

Multiple dialogs and minimizing

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Multiple dialogs and minimizing

    I have a program that shows several different screens as it proceeds to scan for certain records. If it is known to probably run a long time the user can minimize the program and each following screen will honor that minimized state.

    The problem is that when I go to return the screen to it's normal size the only option I get is 'Maximize' when I right-click. Left clicking on it doesn't do anything, it stays minimized.

    No place in the program do I specifically minimize any of the dialogs.

    None of the dialogs are child windows. The scanning progress dialog uses DS_CONTROL AND DS_CENTER so that it minimizes when it's parent does.

    How do I minimize a long running program that displays several dialogs and when it gets to the results screen have a way for it to come back to normal size only when the user is ready to deal with it. Right now the only option is to right-click and select maximize.

    Thanks,

    Bob Mechler

  • #2
    Sorry, I'm working kind of blind, no tools in front of me a the moment, so I will use some of my old brain cells... What are the window Styles of these dialogs? I think if set correctly, you should have the "Restore" menu item enabled on the popup menu from the taskbar if that is your only choice at the moment. (I think)
    Best regards
    Jules
    www.rpmarchildon.com

    Comment


    • #3
      Thanks, I'll research that.

      Bob Mechler

      Comment


      • #4
        Figured it out. Having two dialogs in the same exe both minimized at the same time where one of them was hidden caused the problem. I made the code simpler and the problem went away.

        Bob Mechler

        Comment


        • #5
          Mixing of DDT and SDK could be a problem? (Code not shown) but guessing its the best bet?????
          Engineer's Motto: If it aint broke take it apart and fix it

          "If at 1st you don't succeed... call it version 1.0"

          "Half of Programming is coding"....."The other 90% is DEBUGGING"

          "Document my code????" .... "WHYYY??? do you think they call it CODE? "

          Comment


          • #6
            Answer to problem of multiple minimized dialogs

            Three dialogs
            1. One that reports the progress of a query scan
            2. The first one ends and a second dialog comes up showing that it's loading data into a temp file for later viewing in a listview and our output to Excel or a text file.
            3. The third dialog is a results grid showing the subset of the records that matched the query criteria.

            I had a problem if I minimized the first dialog, the second and the third would stay minimized. When it got to the third I could not restore to a normal size only maximize and then only by right-clicking.

            To fix the problem I used IsIconic just before dialog's end on each of the dialogs to restore before ending it and moving onto the next one. This way, when the results screen was ready, it popped up as normal size on it's own.

            Bottom line, before ending a dialog under program control, check to see if it's minimized (IsIconic) and if so use Dialog Show State hWindow,%SW_RESTORE. Then create the next dialog in the series and optionally minimize it if that is what you want.

            Long running queries caused the user to want to minimize it and do something else. Yet they do want to know the progress and when it is done.

            The small scan progress windows can now be minimized and popped anytime to see where they are in the process. They can then be minimized again and stay minimized as they go to the next step. Only when the results grid is finished does it pop up.

            Bob Mechler

            Comment


            • #7
              The scanning progress dialog uses DS_CONTROL AND DS_CENTER so that it minimizes when it's parent does.
              This miight make things a bit easier to handle for a widnow which is just a 'progress' window...
              Progress Bar Dialog for PB/CC programs October 24, 2002
              (Ignore the "PB/CC" in the thread title. This will work in a GUI program exactly the same way).

              MCM
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                Hadn't seen that example before. Nice example of coding. Do you have an example of doing that type of progress bar on a status bar control. That would be nice instead of using a dialog to show progress.

                An update to my use of %SW_RESTORE just before ending a dialog so that dialogs don't get stuck on the task bar when minimized. I'm now using the following code to do the same thing but not interrupt other tasks the operator may be doing like doing a spreadsheet or entering data into another program. This turns off the minimized flag or something and doesn't interrupt typing into another program as I found the %SW_RESTORE was doing.

                Code:
                MACRO DO_QUERY
                     ACTUAL_RECS& = 0
                     ABORT_KEY$ = ""
                     GOSUB RUNQUERY 'progress window is here and can be min or restored
                     'query is done, now see if the progress bar is minimized and deal
                     'with it accordingly. Doing nothing here causes the next dialog to be stuck
                     'on the task bar with the only option being a right-click and maximize
                     IF IsIconic(hWindow) THEN                     
                       DIALOG SHOW STATE hWindow,%SW_SHOWNOACTIVATE
                       Scan_Window_Stat = -1 'if true tell next dialog to minimize itself on start
                     END IF
                     DIALOG END hWindow
                     RESULTSCHK  ' macro to check results after query
                END MACRO
                By using %SW_SHOWNOACTIVATE here I can do the same thing as %SW_RESTORE but not affect which window has the focus. Using %SW_RESTORE and typing into Notepad I noticed it would interrupt the typing. By using %SW_SHOWNOACTIVATE I could type as fast as I wanted to in notepad and when the other process was switching to the next progress dialog my typing was not affected at all.

                Bob Mechler

                Comment


                • #9
                  The problem with doing it in a status bar is, presumably the status bar is attached to a window which was created in the context of the 'main activity' thread, and therefore must itself execute in that thread's context.

                  That demo was designed primarily for PB/CC users, who generally don't have a "GUI" to worry about, and putting the "GUI" (the progress bar) in a 'seconday' thread of execution makes sense. ('secondary" here is in the eye of the beholder of course... in a non-multi-threaded PB/CC app, there is no GUI and there are no THREAD CREATE statements)

                  That said, there is no reason you could not create a progress bar as a child of a status bar control.... just make it's the same size as the GetClientRect() of the status bar (or the status bar part if you are using a partioned status bar - a very cool effect, by the way) and you will be just fine.

                  i.e in DDT-pseudo-speak..
                  Code:
                     CONTROL ADD STATUSBAR  hDlg, id, size and stuff to  hStatus 
                     GetClientRect    hStatus, RectVar 
                     Convert RectVar to dialog units
                     CONTROL ADD PROGRESSBAR ,  hStatus, id, (size determined above from RectVar)
                  Personally I think the 'size' thing might be easier to do using pure SDK techniques, but that's probably only because I can always find the correct code to mess up the dialog units/pixel conversions.

                  MCM
                  Last edited by Michael Mattias; 21 Mar 2009, 01:04 PM.
                  Michael Mattias
                  Tal Systems (retired)
                  Port Washington WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment

                  Working...
                  X