QuickWin and Windows API

[NotThatItMatters]

I have created a Fortran app with QuickWin which makes use of a few user32 Windows API calls.  Why?  The app needs to build a dynamic menu structure where menu items come and go according to the whims of a governing input file.  The app also needs to properly post-process in case the user pushes the red X in the upper right-hand corner of the window.  Anyway, I had thought I would be able to handle these things strictly with QuickWin but have not been able.

The problem I am having with the app is that if any of the menus are active upon program termination, the application hangs as if in an infinite loop.  I am using a few calls to user32.  The final call is to the following skeletal routine which evidently does not work.

[fortran]

SUBROUTINE DESTROY_WINDOW()

INTEGER (KIND = 4) ITEMID

INTEGER (KIND = LRESULT) RESULT

ITEMID = SETACTIVEQQ(0_4)

WIN_HANDLE = GETHWNDQQ(QWIN$FRAMEWINDOW)

IF (WIN_HANDLE /= -1_HANDLE) THEN

IF (GETEXITQQ() == QWIN$EXITNOPERSIST) THEN

RESULT = SendMessage(WIN_HANDLE, WM_DESTROY, 0_fWPARAM, 0_fLPARAM)

END IF

END IF

END SUBROUTINE DESTROY_WINDOW

[/fortran]

[Steven_L_Intel1]

I believe the problem here is that QuickWin has its own message processing loop and it doesn't know how to deal with the messages you are sending. I know there are some forum users more experienced with this sort of thing than I and they may comment, but what you want may not be possible with QuickWin. Perhaps you can use "subclassing", which lets you add on to QuickWin's message processing.  The Poker sample demonstrates this.

[NotThatItMatters]

The main difference between the Poker sample and the app I run is that Poker is purely interactive whereas my app is a glorified status bar. All underlying display is based on the running of a simulation.  I am providing a few pieces of user interaction to allow the user to modify the data display.  The underltying start/stop of the application is usually governed by the simulation, but at times the user may want to terminate the simulation early or to modify what is being illustrated.  This is the need for user interaction.  I have done most coding based on a menu-driven QuickWin app, but the need to have a dynamic menu for data display and the ability to gracefully terminate with the user hitting the red X, have both caused the trouble with inclusion of Win32 API calls. If there is some other method to handle what I am trying to handle, I am all ears.

[Steven_L_Intel1]

You may be able to accomplish what you want with a modeless dialog box.

[NotThatItMatters]

Is there a sample of modeless dialogs within the samples?  Or elsewhere?

[SergeyKostrov]

>>...Is there a sample of modeless dialogs within the samples? Or elsewhere? Are you looking for C/C++ or Fortran samples with modeless dialogs?

[Steven_L_Intel1]

The Whizzy sample shows dialogs. The only difference between modal and modeless is that a modal waits for the user to dismiss it before the program continues, and a modeless effectively runs in parallel with callbacks when the user clicks on a control. These can be used from any kind of application. So you could float a dialog with a cancel button, keep updated status in a text control, etc.

[Paul_Curtis]

You create modeless dialogs by first calling CreateDialogParam(), which returns a handle to the newly created modeless dialog but does not display it, and then calling ShowWindow() to start the display.  CreateDialogParam() requires as an argument the LOC() of the dialog's proc function (which you have written and thus readily know the LOC of), and the proc needs, among its other tasks, to process the standard IDOK and IDCANCEL exit operations.  This is all standard WinAPI programming, easily realized in IVF, but programming at this level of detail may be more difficult in Quickwin.

[Steven_L_Intel1]

You can use the Fortran dialog support in module IFLOGM rather than calling the Windows API - it may meet your needs and is pretty easy to use. You don't need to do anything special to use dialogs in QuickWin. See Creating Fortran Applications that use Windows API, QuickWin or dialog features for the documentation.

[NotThatItMatters]

I have a somewhat fully featured Fortran QuickWin Graphics application that requires a bit more, but as I have noted the results have been unacceptable.  Attached is a screen shot of a running application showing a dynamic menu with multiple items.  I need to be able to do a few things with this application: (1) be able to use a call back for the menu shown which gives me access to which item is picked and a way to change the display based on the item picked; (2) a means for gracefully closing the program when the user chooses the close button.  I already have a "graceful" exit under the Operation menu which will stop the program running and tidy up the output files generated.

[Steven_L_Intel1]

I will admit that I am not an expert in QuickWin, but I'd have thought you could do item 1 through the supported API. For any of the menu items you can designate a routine to be called when that item is selected, and that can do pretty much anything. You will need separate routines for each item, though, since the callback doesn't pass anything more than a checked/unchecked flag. But there's MODIFYMENUFLAGSQQ and MODIFYMENUROUTINEQQ that may be of use.

Item 2 should be able to be done by establishing a routine that gets called when a "Window Close" message is sent. You may need to use "subclassing" to get this to work in a QuickWin app - I'm sure some of the users here will know more than I about this.

P.S. I suggest modifying your forum "display name" to not be your email address.Click on the yellow triangle next to your name near the top of the page, select Dashboard, and you can edit your profile.

[NotThatItMatters]

Perhaps it was not obvious from the screen shot, but the display menu has the default "Field" item, but the other items get appended as the simulation proceeds.  The choice of an item on the menu changes the display to mirror the item.  So, if I pick A5 then item A5 gets displayed both graphically and in the text box ticker at the bottom.  With the simulation shown there are 15 possible items.  With some simulations there may be only one, or 250 or more.  It would be somewhat ridiculous to write 250 callback functions on the off chance that 250 items show up in this dynamic menu.

[andrew_4619]

In QuickWin You don't get any option for the menu selection other than what Steve stated (the checked flag).  It might be better haveing a floating modeless dialog  with a drop down combo box to select these items which you could then handle via a single call back. Either that or you are left with making 250 callbacks for the menu that could be one line routines that call a single routine with the approapriate parameter... not elegant but not that much work either, you could write a 10 line programs that writes the source for the calbacks!

[Steven_L_Intel1]

Yes, app4619's suggestion of a modeless dialog is what I was thinking of earlier. It gives you a lot more flexibility.

[NotThatItMatters]

So, if I am understanding the suggestion, the idea would be to omit the "Display" menu in the QuickWin app and replace it with a second modeless floating dialog which holds the same data as the fixed menu.  How does one manage (marshall?) the two pieces, as in the QuickWin piece for the graphics and display and the "separate" modeless dialog box?

[andrew_4619]

The modeless dialog runs as a separate thread. You can minimise it, if it is in the way or close it and reopen via the menu or indeed you could register a mouse event for clicks on your graphics area to re-pop the dialog when it is closed. Just some ideas. You can still have your other menus or dispense with then and have all the menu interaction via items on the dialog.

[dboggs]

Unless I'm mistaken, the documentation for Quickwin as well as the classic text "Compaq Visual Fortran" by Lawrence, state (emphatically in fact) that modeless dialog boxes are not possible in Quickwin--it's just an inherent limitation of the way Quickwin works. Maybe I misunderstood. But--do you guys know that your suggested solution will actually work, or is it just wishful thinking? If modeless dialog boxes are indeed possible then I need to learn a lot more about Quickwin.

[Steven_L_Intel1]

Hmm - perhaps I was hasty in suggesting a modeless dialog. Upon review, you do need to be able to process messages in a message loop. This may still be possible - I'll see if I can work it out but ity may be a while.

[andrew_4619]

I use modeless dialogs all the time in quickwin... use DlgModeless call rather than dlgmodal !??!?

[andrew_4619]

I use modeless dialogs in quickwin all the time, that is what the call dlgmodeless does....

[Steven_L_Intel1]

Something has to handle the messages for the modeless window - perhaps QuickWin does that automatically.