dlgModeless won´t work - sometimes

[onkelhotte]

In my QuickWin program I display a dialog by

l=dlgModeless(dlg)

But sometimes the dialog won´t come up. The thread seems to be stuck somewhere inside dlgModeless, no error message is being given. Sometimes the dialog comes up as it should.
Funny thing: It does make a difference if the .exe is opened in the explorer, run by Visual Studio or opened by a third party program.

This is real strange. At first I thought It would help to compile the solution again - which helped indeed in the past. But now a customer complains that he sees the same behavior. But he uses the same .exe for quite some time.

Does anybody knows this and can give me a hint or how I can track down the error? It can´t be something in the code - because my customer proves the opposite.

Markus

[DavidWhite]

Markus,

Has the user changed the resolution of their screen, or changed the graphics options regarding cloned screens or extended desktop?  I have sometime had issues with programs that remember the last location of a dialog, and when the screen settings change, the dialog reopens in what is now an inaccessible screen location.

This describes the kind of scenario you give - the dialog has not crashed, yet you cannot see it.

Regards,

David

[andrew_4619]

Ensure you have a callback set for the dialog name itself. You will then enter this callback in the dialog initialisation phase before it is displayed and can interrogate the dlg structure under debug...

[Paul_Curtis]

Could the modeless dialog be hidden behind another window?  Try forcing the dialog to be on top:

        rval = SetWindowPos (hwnd,HWND_TOPMOST,0,0,0,0,IOR(SWP_NOSIZE,SWP_NOMOVE))

[onkelhotte]

Thanks for the hints!

@David: I don´t know if the customer changed something with his display options. But I didn´t, so this one is gone.

@app4619: I´ll try and set a breakpoint in the callback routine (there is one)

@Paul: Forcing to be on top could be an option. I´ll put it in my code

Have a nice weekend,
Markus

[Greg_T_]

Hi Markus,

Similar to David's comment about display settings changing, we've had "hidden" or "missing" dialog forms when a laptop is undocked from its docking station (while the laptop is running) and there are others monitors connected to the docking station for an extended display.  The laptop display seems to remember the extended display, so when a program starts it may get displayed outside the current laptop monitor in an area where one of the extra monitors was.  In those cases we do see the program icon in the bottom icon tray, so the user can shift-right-click on the icon to select "move", and then use the arrow keys to get the form into the laptop monitor.  I've also seen this happen when connecting or disconnecting a laptop to a projector, depending on how the automatic display gets set.

Regards,
Greg

[dboggs]

For what it's worth: is there good reason to think that it SHOULD work? I ask because you're using Quickwin, as I do. I have very little experience with dialog boxes, but I do know that old documentation from the CVF era--including the well-known book by Lawrence--states quite emphatically that one of the limitations of Quickwin as compared to Windows projects is that only modal dialog boxes are supported. And indeed, if you go to the IVF documentation and look up DLGMODELESS, Quickwin is conspicuously absent from the compatibility list.

I wish it were not true--maybe things have changed--and maybe the users above can find a way to make it work. Then I would probably become more of a dialog user myself.

[andrew_4619]

@dboggs. Modeless dialogs do work in quickwin, I use them a lot and have done so for a long time, I have no problems. There are a couple of things to note, in that you need to have a callbacks that trap all the ways the dialog can exit so that you can tidy up/un-initialise stuff. It might not be properly documented but the Quickwin message loop successfully processes messages for modeless dialogs created with iflogm

[dboggs]

This is great news, if it works--or can be made to work. I haven't even tried it, and never intended to try it, because of the documentation.

Intel: If true, can you correct the documentation? This is an important issue.

[Steven_L_Intel1]

dboggs, where do you see in our documentation that you can't use DLGMODELESS in a QuickWin application? I'm not seeing that in the current documentation. Perhaps you noted that "QuickWin" is not explicitly mentioned in the text and took that as "not supported"? The current text says:

DLGMODELESS is typically used in a Windows application. The application must contain a message loop that processes Windows messages. The message loop must call DLGISDLGMESSAGE for each message. See the example below in the Example section. Multiple modeless dialog boxes can be displayed at the same time. A modal dialog box can be displayed from a modeless dialog box by calling DLGMODAL from a modeless dialog callback. However, DLGMODELESS cannot be called from a modal dialog box callback.

DLGMODELESS also can be used in a Console, DLL, or LIB project. However, the requirements remain that the application must contain a message loop and must call DLGISDLGMESSAGE for each message. For an example of calling DLGMODELESS in a DLL project, see the Dllprgrs sample in the ...\SAMPLES\DIALOGfolder.

While I suppose it may not be obvious, a QuickWin app is a Windows app and as noted above, it has a message loop that does what is needed. What you can't do easily is process your own dialog messages, though it CAN be done.

[Hitoshi]

Using Intel® Visual Fortran to Create and
Build Windows*-Based Applications

Document Number: 324197-001US   (as of 2012)

page 25/125

Comparing QuickWin with Windows*-Based Applications

You need to use Windows-based applications, not QuickWin, if any of the following applies:
   • Your application has an OLE* (Object Linking and Embedding) container.
   • You want direct access to GDI (Graphical Data Interface) functions.
   • You want to add your own customized Help information to QuickWin Help.
   • You want to create something other than a standard SDI (Single Document Interface) or MDI (Multiple
      Document Interface) application. (For example, if you want your application to have a dialog such as Windows
      Calculator in the client area.)
   • You want to use a modeless dialog box rather than a modal dialog box.

...................................................................................................................

Sorry, the last phrase above  was changed to followings as of today.

• You want to use a Using Dialog Boxes for Application Controls Overview rather than a modal dialog box.

[dboggs]

In my experience with the Intel (and Compaq before that) documentation, a Quickwin application is distinctly different from a Windows application. I have seen it so much, and is consistent with my (limited) coding efforts, that I had considered that to be non-contestible: If Quickwin is not specifically mentioned in the supporting documents, then because it is definitely NOT a subset of a Windows app then it cannot be considered to apply.

One obvious place is where you look up DLGMODELESS in the a-z section of Help. At the bottom of the screen for every subroutine or function, under "Compatibility," is a list of all the project types where the procedure can be used. For every procedure I have ever used in a Quickwin application, "Quickwin" is specifically on the list. And for (the few) other procedures I have tried, I get an error.

To quote from the document "Creating_Fortran_Win_Apps_1.pdf:

There are two types of dialog boxes:

• Modal dialog boxes, which you can use with any Fortran project type, including Fortran Windows, Fortran

QuickWin (multiple document), Fortran Standard Graphics (QuickWin single document), Fortran Console,

Fortran DLL, and Fortran Static library project types.

• Modeless dialog boxes, which are typically used with the Fortran Windows Application project type.

In another section of this same document:

Modeless dialog boxes are typically used in a Fortran Windows project. A modeless dialog box can be used in

a Fortran Console, Fortran DLL, or Fortran Static Library application as long as the requirements for using a

modeless dialog box (discussed in the previous paragraphs) are met.

And finally, near the end:

As described in Using Dialog Boxes for Application Controls Overview, Intel Fortran supports two types of

dialog boxes: modal and modeless. You can use a modal dialog box with any Fortran project type. You can

use a modeless dialog box only with the Fortran Windows project types.

And, as I noted above, A FORTRAN WINDOWS PROJECT TYPE IS NOT THE SAME THING AS A FORTRAN QUICKWIN PROJECT TYPE.

Or, am I just hopelessly confused?

This conclusion was reinforced by the classic text Compaq Visual Fortran by Lawrence, which states (p. 55):

"Dialog boxes may be "modal" or "modeless." The modal dialog box style is the most commonly used; currently, it is the only type available for QuickWin applications."

Of course Intel is not responsible for what Lawrence may have written once upon a time. But, with all of this info laying around, is it any wonder that users conclude that modeless dialog boxes are incompatible with Quickwin? If this has changed, then Intel should have made a big deal of it at some point along the line.

Or, if it's just a matter of supplying an un-Quickwin-like message processing loop, is this technique described in any of the sample applications? Shouldn't the documentation indicate that an exception can be made to the Quickwin incompatibility, as demonstrated in such-a-such sample program?