Announcement

Collapse
No announcement yet.

DIALOG SHOW MODAL not showing up

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

  • DIALOG SHOW MODAL not showing up

    Hello all,

    I'm running into a strange problem. I'm hoping that someone out there might have a general idea of what's happening. I'll post code if necessary, but, again, I'm really just looking for a tip.

    I'm using PB/Win 8.0. I made an application that uses a DIALOG NEW UNITS block ending with DIALOG SHOW MODAL hDlg TO Result. The application runs fine on three machines in my office. I just e-mailed it to a co-worker at a distant location. He says when he runs the EXE, it shows up in Windows Task Manager (so we know it's running), but he gets no visible window.

    My first thought was that the program was developed on a 2-monitor system and it might be launching off-screen on a 1-monitor system. But I ruled that out by inserting a MSGBOX of the DIALOG's location. The remote user confirms that MSGBOX pops up and reveals the DIALOG's location to be on his monitor. He tried several different PCs and got the same result.

    The first line is #INCLUDE "C:\PBWin80\WinAPI\DDT.inc" The remote user doesn't have that file, but he wouldn't need it if the code were compiled into an EXE, right? The only things in my DIALOG block are CONTROL ADD statements.

    Any ideas?

    Thanks, Christopher
    Christopher P. Becker
    signal engineer in the defense industry
    Abu Dhabi, United Arab Emirates

  • #2
    Things like that can happen sometimes if you have an invalid combination of styles on the dialog itself. Seems that some operating systems ignore the invalid styles and others refuse to create the window at all.

    I think you'll need to post your code and a simple version of the callback function for someone to check it out.

    You are not trying DIALOG END in the WM_INITDIALOG processing are you? I think that, too, can give you an effect similar to what you are experiencing.

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

    Comment


    • #3
      Michael,
      Thanks. It helps sometimes just to get a fresh outlook. I took a second look at my WM_INITDIALOG processing, may have found the problem. Waiting to hear back from the remote users.
      Thanks,
      Christopher
      Christopher P. Becker
      signal engineer in the defense industry
      Abu Dhabi, United Arab Emirates

      Comment


      • #4
        Michael, you nailed it. It was a bad WM_INITDIALOG call. Still is crazy (to me) that it works fine on some Win XP machines, but not others. No consistency.
        Christopher P. Becker
        signal engineer in the defense industry
        Abu Dhabi, United Arab Emirates

        Comment


        • #5
          Using something like this in your callback can help prevent odd GUI effects..
          Code:
          CallBack Function DlgProc()
            Select Case As Long CbMsg
              Case %WM_INITDIALOG
                Dialog Post CbHndl, %WM_USER + 1000, 0, 0     ' e.g.'%WM_USER + >500' prefered - see help DIALOG POST
                                                              '      msg is posted AFTER GUI is prepared
              Case %WM_USER + 1000                            ' Equiv to ShowWindow,
                Dialog Redraw CbHndl                          ' UpDateWindow in SDK style? :)
                'Do GUI related stuff
          This makes sure that the Dialog and it's Controls are in place before your program starts interacting with them.
          Rgds, Dave

          Comment


          • #6
            Dave, that's a really neat idea for any GUI type initializations... even splash screens, I think. I'm going to start using this technique. Thanks.

            Comment


            • #7
              > [posting message to self is ] a really neat idea for any GUI type initializations....

              Depends if you want the screen showing when you do it or not.

              WM_INITDIALOG (and WM_CREATE) stuff if done before the user ever sees the screen; self-posted message processing occurs after the screen is shown.

              So if you have some 'ugly' stuff to do (eg adding, deleting, moving, resizing controls) you might want to do that BEFORE the user ever sees the screen. In these cases you can end up with an annoying flicker.

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

              Comment

              Working...
              X