Dialog Box

Dialog Box

Dear Steve:

I hae been slowly working backward through the sample WIN32 programs to create a simple windows program that gives me an input dialog window with a few simple controls on it, but it comes from the main window not by itself. I need to main window clear for future results as this program once running will run for months at a time.

It is based onyour latest templates, butI had a good look at the backcolour program using the EXAMDIFF Pro program.This has been invaluable tolearn Windows Forms programming.

But Ican not get return data from the Radio button, obvioulsy because I am completely lost as to the code. I keep getting an error

Error1 error #6284: There is no matching specific function for this generic function reference. [DLGGET]C:\\Users\\John\\Documents\\Visual Studio 2010\\Projects\\CX1Reader4\\CX1Reader4\\CX1Reader4.f90588

retlog = DLGGET(hDlg, IDC_RADIO1, pushed_state)

which is on line 588 of the main program file.

I would really appreciate your help in seeing what I am doing wrong, I just cannot see an error, but I do not know enough to know what I am doing wrong.

I am also writing a simple file of the steps I used so that I can put it in a post for future learners. mainly me I think when I want to do this again.

Thanks

John

AttachmentSize
Download cx1reader4.zip1.09 MB
15 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

The DlgGet generic interface is out of the IFLOGM module, which is a collection of types and procedures that sit (barely) above the "raw" Win32 api and make it easier for a programmer to use dialog boxes in a program. The compiler's documentation describes these routines under Building applications > Using Windows OS features > Using Dialog Boxes for application control.

These routines (including DlgGet) often take an argument of derived type "dialog" that wraps the native windows handle to the dialog box (the variable called hDlg in your program's code) plus other information that's internal to this collection of routines. Your code isn't providing an argument of type(dialog) as the first argument - hence the error.

The underlying problem is that you have this one call to this higher level dialog library while everything else in your program, apart from that one attempted procedure call, is using the raw Windows' API (comment out the USE IFLOGM statements and the DlgGet call - your program still compiles and links!). If you are going to use this higher level library then you should be using that library's routines for creation and manipulation of the dialog box. I can't comment much further because I don't use the IFLOGM stuff.

To retrieve the value of a dialog control as a logical using only the raw windows API I'd be using the IsDlgButtonChecked API (msdn link). Intel provides the Fortran interface for this API in the USER32 module. Note that it's first argument is of type HWND (C language) or INTEGER(HANDLE) (fortran equivalent), which matches your hDlg variable. Be mindful that the return type of this API is not of type logical - it is an integer - the Window's API doesn't know about Intel Fortran's logical type (plus some check boxes can represent more than just true/false or on/off). Your call to this api therefore needs to compare the returned value with an appropriate integer constant in order to decide whether the equiavlent fortran logical value should be .TRUE. or .FALSE..

You could always revert to the methods described in the IVF examples that uses DLGINIT to initialize and DLGMODAL or DLGMODELESS to display a dialog and DLGSET to set call-back routines for each control in the dialog.

However, since you have gone to all the trouble to learn the full windows way to set up a window menu for your dialogs, I have had a play with your posted code and modified the DIALOG1 function (started with the Open.. menu item) to show how basic button and edit control messages might be handled (I only send text to the edit box, but retrieving it is just the case of sending the correct message and declaring a buffer ready to store the returned string). My edits to the code are marked between lines of asterisks in the attached modified version of your CX1READER4.F90 file.

I note that the check box flips automatically between states after each click on it, whereas the unitialised radio button remains selected after each click on it. So if you want to flip the radio button state (assuming it is not one of a linked group, which will automatically be cycled through), you need to record its state and, when required, flip it yourself by sending a message to it using SendMessage or SendDlgItemMessage.

e.g. iret=SendMessage(GetDlgItem(hDlg,IDC_RADIO1),BM_SETCHECK,BST_UNCHECKED,0)
or iret=SendDlgItemMessage(hDlg,IDC_RADIO1 ,BM_SETCHECK,BST_UNCHECKED,0)

Attachments: 

AttachmentSize
Download CX1Reader4_mod.f9023.15 KB

Thanks heaps guys. I want to use the full Windows API, it just takes a while to learn the commands.

A lot like LISP, just there are more people who speak Fortran:

You should try to get a CADDR working in Autocad when you are just new to LISP.

JMN

Dear Anthony and Steve:

I just spent two weeks in Australia, playing with the code Anthony had given me to use for Dialog boxes. It was a lot of fun and I managed to get the program running using the Dialog box to control the analysis type for the straightforward analysis.

However, I would like to print out messages from the program to a window as it runs so I can follow along in real time. I could set up an edit box in a dialog window, but I think that is not elegant, more brutish.

The main window and the dialog box is opened in CX1reader4_mod and works just fine. I had to modify your code so that it deleted the edit box data, before sending out a new comment, which took me a while, but learning this was highly instructive. I have added some controls and worked out how to group them so they work as required.

I call a subroutine Thor passing it the handle for the main window - thor is located in this same file at the bottom, and it calls CX1Reader again passing the handle to the main window. This CX1Reader subroutine is in Analysis.f90. This group of routines performs the FFT analysis.

I am usinga message box [see below:] at the moment to pass back messages, but I would prefer to write them to the "main window area" as a set of text strings so that I am not hitting return and soI can track the analysis and the position in the analysis as I add complications to the code.

I have been through Penzold and the CVF book,I can get their textout and drawtext to work in the sample programs, but as soon as I try something in this program I never get anything out. Obviously I am missing something simple, but Ican not see how to do this simple task. I stripped out all my attempts as they appeared futile.

Your assistance would be appreciated.Sorry for being a pain, but this is driving me nuts.

JMN

PS: I used a note by Petzold on static variables to save the analysis and wavelet types to be used in the FFT subroutines from the dialog box.That proved to be nifty.

mret = MessageBox(hDlg,

'Analysis Method Entered '//clf &

//

' (c) John Nichols, 2011. '//clf &

//

' Version 1.2.110709'//clf &

//

' Analysis Type is '//chwID//clf &

//

' Wavelet Select Type is '//chAnType//clf &

//

' Debug Select Type is '//chDeType//clf &

//

' '//char(0), &

' CX1 Data Analysis Program 'c, MB_OK)

Attachments: 

AttachmentSize
Download CX1Reader4.zip77.95 MB

By 'write to the main window' I presume you mean the non-client area below the menu bar.
You could draw text on its device context using DrawText, as shown in the attachemtn, but you would have to save all the text and redraw it as soon as the window receives a command to repaint it if part of it is uncovered after being obscured, or if the window is resized, as this erases everything in the window. You also have to keep track of the window size in order to specify a rectangle for the text to be output, plus it doesn't automatically scroll when you reach the bottom.

If you do not want to append progress text to a large edit or list box in the dialog (or in a secondary dialog containing just one large edit box), which would otherwise suit, I would suggest you examine the creation of a console using AllocConsole and writing to it using WriteConsole.

Attachments: 

AttachmentSize
Download Image1.jpg48.23 KB

CX1Reader4.zip

Dear All:

I thought I could use the status bar to print out some simple messages.

Lawrence provides a good example, which works in IVF, I got it running,

Adding the necessary code to my program results in

call

initcommoncontrolsex(iccex)

returning a compile error as it is listed as a function in the headers.

Yet it works in Lawrences program.

I used EXAMdiff pro to compare the two file sets and I am tolerably sure I got all the code I needed, but obviously I am missing something.

I enclose the code, but the main code is all contained in the cx1reader4_mod.f90 file.

I would really appreciate someone explaining what I am doing wrong.

I havetried changing the call to a function, but it crashes the program.

Thanks heaps

JMN

Dear Steve:

Is there anywhere besides lawrence and petzold that provides a simple blow by blow description of how to get a tolerably simple interface windows API working in IV Fortran?

In regards to the status bar problem, the second approach is to use the Lawrence Status bar program as a base and copy my other stuff into it.

Thanks

JMN

Dear All:

So I looked up the interface and tried this again. Put in some breakpoints and it was clearly the correct call now.

jret = InitCommonControlsEx(iccex)

But why does the subroutine work as the call in the lawrence program when it is converted to IVF? I changed all the use statements and it still works?

iParts was set by Lawrence to three in the WM_CREATE and then in the next go around when the

case (WM_SIZE)

is hit, the ipartshad lost its value, so clearly I need to set this as a static variable, no problem:

So then I copied the (WM_Size) Code creating the three parts of the status bar into the WM_Create and low and behold there it was.

So why are the WM_Size and WM_MOUSEMOVE case statements not being seen the way Lawrence wrote it, but they are whenI runhis program in IVF?

Is it my addition of code for my program in

case (WM_COMMAND)
select case ( IAND(wParam, 16#ffff ) )

case (ID_FILE_OPENFILES)
! Save the analysis types to default types of nothing and nothing
call SaveDialog1_AW (1,0)
call SaveDialog1_AW (2,0)
lpszName = "Dialog1"C
ret = DialogBoxParam(ghInstance,LOC(lpszName),hWnd,&
LOC(Dialog1), 0)

here that is stopping access to the WM_Size and Wm_Mouse move?

Very frustrating at times, but once I stopped and start to use the debugger it was easier.

I will need to put in some dialog boxes as Anthony showed me to figure it out finally, but I am still a bit lost.

JMN

John,

I am not sure this will work for you but it works for me. I too have experience with running simulations that take weeks and months to complete. While it is running I want feedback as to progress and if the simulation has gone amuck (no sense completing weeks worth of run if the simulation buggered-up at hour 12). What I did, and which is probably more than you want is:

Original app had console window for progressmessages:

I added side dialog box for buttons and radio selectors and other control items. Note, this dialog is added in the main application via CreateThread. This permits the dialog loop to run seperate from the simulation code. As you (I) click controls on the dialog box the dialog code marks these changes in a common data (module shared by main app and dialog). The dialog is passive to the main application other than for tweaking this shared data. My application is similar to a finite element analysis and has a main loop which iterates at the simulation integration step size. In the this "main" loop I add code to test a "dialog tweaked the common data" flag, and if set call an appropriate function/subroutine such as a "tell me where you are", and in which case the info is displayed to the main app console window. Alternately, the main app can write to the dialog shared data area and which then the dialog loop picks up this data and displayes usually as text box or progress bar.

For my purposes this was not sufficient enough. To this (back in ~2005) I added the Intel Array Visualizer (it _was_ a terrific but under-apreciated product). This too ran (runs) as a seperate control thread .AND. seperate process from the simulation app. With this addition, I could then see 3D charts (image) of the simulation as it runs as well as observe tables of data all in real time (to the simulation). The other neet thing you could do is open multiple instances of the Array Visualizer each showing different views.
Beloware two screenshots:

One displaying a table

And one showing

Two 3D charts, Dialog Box (control box), plus status log in console window

The Dialog box has has controls for modifying the display data as well as modifying the simulation (and some text display)

The simulator code is virutally untouched. While the simulation is running I can

Open as many AV windows as I want. Each has a browse tree where I can select what to display, 3D chart, 2D chart, table.... and I can add a new chart on the fly as the simultion is running.

Quite powerful stuff.

Sad to say, AV is no longer a (supported) product.

I've added an OpenGL display option... but it sorely lacking in features that were available in AV
(iow I must add these in myself)

Jim Dempsey

www.quickthreadprogramming.com

We provide several samples that use the Windows API and dialogs. You may find them helpful. In general, I look for C (not C++) sample code and translate it to Fortran - that usually works. There are lots of books that look at the API from a C perspective. One I have, which is rather old right now, is the Win32 API Superbible.

Steve - Intel Developer Support

Dear Steve:

I can get the Windows API thru the Uni library. Thanks.

When I started to play with only using IFWIN I found that the standard comctl32 module is not included in IFWIN. It is needed for the Status Bar to work.
You know sometimes when you are trying to understand other people's code decisions it pays to sometimes just acceptit as it is.

JMN

	use comctl32
    !   Call for the InitCommonControlsEx - changed from the call statement in Lawrence.
    jret = InitCommonControlsEx(iccex)

Fascinating. You are right - COMCTL32 is not referenced by IFWIN. I think that's a bug and will suggest that it is changed. It was that way in CVF too.

Steve - Intel Developer Support

The current situation with module nesting mirrors to some extent the Platform SDK, where commctrl.h (the header file for comctl32.dll) is not included by windows.h.

We added in some missing modules, but went a bit far adding WS2 which causes problems with WSOCK32 also in the mix, so we took it back out.

Steve - Intel Developer Support

Leave a Comment

Please sign in to add a comment. Not a member? Join today