DIALOG SHOW MODAL not showing up

[Christopher Becker]

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

[Michael Mattias]

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

[Christopher Becker]

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 Becker]

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.

[Dave Biggs]

Using something like this in your callback can help prevent odd GUI effects..

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.

[Charles Dietz]

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.

[Michael Mattias]

> [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