Can messages be passed from a modeless dialog box to winmain.

[Jones__Robin]

I am attempting to do something I haven’t done before in Quickwin and I can hear it now; you can’t do that in Quickwin!

Can the following be done and If so how?

The position is that I have a main Quickwin program which accepts key presses to control how a graph is plotted; next block of data, expand time scale etc. Not very elegant. I want to replace the keyboard input with a modeless dialog box whose buttons, 12 in all, supply the key-codes to the main program to do the controlling.

I have a modeless dialog box which displays the buttons and responds when one is clicked by setting a global variable to the key-code. If it has the usual message loop in it does not return to the main program. Without the loop it returns to the main program but despite the buttons being acted on there is no communication with the main program of course. With both message pumps included, after the dialog is established the main program proceeds to the point where the message loop holds it up. The code which follows picks up the key-code if not zero and resets it to zero. All is well until I click a button. The main program throws an exception at the call of the subroutine containing the main program message pump. I suspect this is because I don’t know how to receive the message from the dialog properly.

Exception thrown at 0x0114B5F4 in Orictape-SF.exe: 0xC0000005: Access violation reading location 0x00000004.

Can any one help?

[ZlamalJakub]

Your description of problem seems little bit complicated to me. I do not use QuickWin but Win32 interface.

My suggestion:
If you have modeless dialog box, in the main message loop should be implemented call of IsDialogMessage  function. If the message should be passed to dialog box, this function do it. So one message queue can handle messages of main window and even dialog box window. I am not familiar with QuickWin so I cannot give more help.

Problem with exception canbe caused by different reasons, improper memory deallocation, reading from dialog box memory which no longer exists after dialog box end.

Can you provide very simple example to see what are you doing?

[MWind2]

This made my head hurt

https://docs.microsoft.com/en-us/windows/win32/dlgbox/using-dialog-boxes#creating-a-modal-dialog-box

so much I would suggest a winform with a fortran dll might be easier.

[Jones__Robin]

Thank you for the replies.

Jakub,

I have attached a directory which is a Fortran Quickwin program to demonstrate my problem. It consists of two principle files DialogTalk.for and a dialog box file and Control.for. The usual support files are there. I have made it as simple as possible to improve under standing as I know how difficult it can be to suddenly be introduced to someone else's way of working.

mwindham,

Thanks for the link I shall study it. My main problem is that I have 25 years of writing Fortran but very little experience of writing Windows.

[ZlamalJakub · Accepted solution]

Dear Robin,

   I have made changes in your routine PLOTCONTROL and I hope now your code will do what you need. Changed lines are marked with CQ comments.

It is important to understand that there should be only one message handling loop in application.

[Jones__Robin]

Good one Jakub, that's great. Thanks and much appreciated.
However it has spawned questions of course.
1/ The main program circulates the "message loop" and, I assume, drops out when a "done button push" message arrives from the dialog box. Is this so?
2/ What if there is more than one dialog box open at a time? Standard Fortran Graphics Application only perhaps.
3/ I used a common area to pass the requested key code. Can this be passed as a "message" at Quickwin level, or have I got the wrong understanding of a "message".
4/ The second write statement, the one after the dialog box is established spawns another window. I don't understand why?

Anyway thanks again now I have an existence demo I can study mwindham's link again; trouble is, it is all exampled in C.

[ZlamalJakub]

1) Yes. Main message loop should be infinite and exit when "done" button is pressed.

2) There can be more modeless dialog boxes. Function IsDialogMessage pass message to correct dialogbox.

3) I tried to create example with sending messages but I failed. Windows messages are not send to dialogs but to windows (each has its own Handle). But I was not be able to get handle of main window. I also failed to assign calback function to main window, which will manage received messages. So I capitulate to create example. I am not familiar with QuickWin, for my purposes it is too simple.

4)  You used    888      WRITE(*,*) DLGKEYCD

if you use 888      WRITE(WINCH,*)DLGKEYCD

new window will not be created because output will be printed to already opened window

I am so sorry that I am not able to help you more.

You can look at book "Compaq Visual Fortran: A Guide to Creating Windows Applications" by Norman Lawrence. It is very old, but it can give you good introduction how to manage things without studying C language.

[Jones__Robin]

2/ I see you say the same as the literature "Function IsDialogMessage pass message to correct dialogbox". The loop is however in the main program so is not the message passed from the dialog to main program? What you say the literature says which has confused me.

3/ My much dog-eared copy of Lawrence p147 et sec seems to imply otherwise, but I haven't worked it out yet; he examples in WIN32 APP mostly.I do understand that dialog boxes are just windows so all of them have handles even main program.

4/ Yes a brain-fade on my part.

Any way, many thanks for your interaction.

[Steve_Lionel]

The catch with QuickWin apps is that the handle of the main window isn't exposed. For a while I had thought that GetForegroundWindow() would return it, and that often seems to work, but not always. So in the Win32 samples, such as GetOpenFilename, where one of the arguments is a window handle, I changed it to just NULL as that always worked (even though it was not optimal.)

QuickWin can be very handy to get you going, but it is ultimately limiting. There are some good samples using a WinMain and you may want to study those to see if your application can be adapted to get rid of QuickWin.