Problem Subclassing Modal Dialog Box

[dannycat]

A few dialog boxes in my application utilise the subclassing method to enable resizing and the use of tree view and list controls. All the dialogs work fine in Debug mode but when compiled for Release their behaviour becomes somewhat erratic, sometimes they work and other times they don't, (the problem is however repeatable and not random in that respect). When they don't work the dialog is displayed but none of the buttons respond to clicks even thought they seem to be active and change appearance when they are clicked. Only way out is to use Task Manager to kill the process. Another symptom of this problem is that tree or list controls are not set up properly.

After using write statements to track the process in release mode it is evident that the external callback routineis not being entered and therefore the Subclass procedure is not being activated and consequently the dialog is not being set up within the DlgModal routine. As I mentioned earlier this behaviour is not predictable and the dialog box can work fine the first time around and then not when it is called up for a second time,usually only after another dialog has been processed.

I've tried creating a release configuration with all optimisation turned off but this does not change the behaviour compared to the normal optimised Release version.


I've used the XE Inspector program (both SSA and Dynamic) but this did nothighlight any memory problems (Although this operates on a Debug configuration.

I would be very interested to from anyone who has had similar issues in the past or any advice on possible methods to track the possible cause(s) of the problem.

The last resort will be to package up the whole Project solution and submit to Premier Support and see if they can help.

Thanks

Steve

[anthonyrichards]

What might be helpful is if you could post the code for one of your problem sub--classed procedures, so that we can look at how you are handling the message processing.

• How are you passing on messages that your procedure does not directly handle for default processing? That is an area that may give you problems if it is not done correctly.
• Do you rely on any variables being 'saved' between calls within your sub-classed procedure(s)?
• Do you have duplicated resource ID's defined in youre RESOURCE.FD file? That is, do you have different resources assigned the same integer value as an ID? If the RESOURCE.H file on which it is based has been edited outside Visual Studio resource editor, or you have copied in dialog or other resources from other resource files, you can find duplicated ID's coming in, which may cause problems sometimes. you can specify your own resource ID numbers within the property dialog box for a control by adding (for example) "=1234" to the displayed identifier, for example if you see "ID_EDITBOX" (without my added quotes) in the edit box for the control ID, just edit the entry to read "ID_EDITBOX=1234" in order to change the value to one that differs from other controls (assuming 1234 is not already taken!).

[dannycat]

Thanks Anthony, you have made some interesting points. I've attached a file (too large to put in edit box) containing the problem dialog fortran code that I am focusing my attention on at present. There are several dependent modules required to be able to compile it but for now it should illustrate how I've tried to set up the subclassing.

There probably are duplicate IDs in the resource file as in the past I have copied dialogs from other sources. Is there a way of easily renumbering everything in the resource.fd/.h files to tidy everything up? I thought about doing this using Excel to reorder the control IDs and set upa sequential system for the different groups of identifiers (IDC_. IDM_, IDS_ etc) but I was a bit wary of doing this in case it caused more problems than it would solve. Having said that I did check that the ID's in the attached dialog were all unique.

Variables are generally not 'saved' between calls as the user input is put into global data structures that are managed by the module FEConstraint. The only saved variables are the T_RECT spDlgsz (size of dialog box) and the first_undo logical.

As this application was converted from CVF the /QSave switch is set.

The subclass interface should conform to the correct window definitions.

Thanks again for your time.

[anthonyrichards]

Your subclass procedure in the file you attached ontains this snippet at the end:

****************************************************

case default

end select

! pass all other messages on to the default window procedure

SpcSetDlgProc = CallWindowProc(hspcDlgProc, hDlg, message, wParam, lParam)

return

end function SpcSetDlgProc

****************************************************

This indictes to me that you are passing every message on to the default procedure.

It is normal to put the call to the default window procedure under 'case default'.

Also, under none of the 'select case (message)' cases do you set a value for the procedure.

Normally, after handling the message by doing all that is expected of the dialog, you would finish off by setting a value such as SpcSetDlgProc=1 and returning it to Windows to show that you have processed the message and that the default procedure is not required for it. You can either use an immediate 'return' statement to do this or leave the code to drop out of the 'select case' tree and execute the return at the end of the function. It might be worth trying these fewchanges to see what happens.

[dannycat]

I've tried the changes to the subclassing procedure you suggestedas well as renumbering of resource IDs to unique values but unfortunately this hasn't changed the behaviour.

I am going to try to gradually remove the functiionality from the program to see if I can identify the root cause. If this does not do the trick at least I can send a relatively concise example to premier support.

[anthonyrichards]

Make sure that any changes you make to your RESOURCE.FD directly are not negated by VS resource compiler overwriting it with a new version regenerated from an unchanged RESOURCE.H when you rebuild.

[dannycat]

I've managed to produce a smallish example to illustrate the problem (Solution attached). Resource.fd has been regenerated from the resource.h.

The program runs fine in Debug mode but crashes in release mode (on Windows 7) in both 32 & 64 bit configurations.

The test routine calls a dialog box, click the Add button followed by OK. A second dialog box will be displayed where you can simply click Done. The first dialog should reappear but in release mode the program crashes at this point.

Note that on Windows 64-bit XP the dialog gets displayed but the callback does not seem to get called causing the program to get stuck in the dialog.

[anthonyrichards]

I extracted the zipped archive into a new folder.
I have IVF XE Composer 2011.10.325 with VS2005 and Windows XP Pro.
I could not load the solution as it was constructed using a newer version of VS, so I loaded the project file into my VS2005.
The resource.H and resource.FD files were omitted from the project for some reason and were not visible in the solution explorer pane.
I added those two files to the project.

I selected Win32 debug configuration
I built the solution.
I Started it without debugging.

Here is what I saw:

A blank console appeared (There are "WRITE(6,..) statements called throughout the code using "Call grp_message(string)").
Dialog "Constraint Set" appeared with no entries.
I pressed the "Add" button".
Dialog "Constraint set" remained, this time with an entry added to "SPC sets" list box. The text " SPC Constraint Set 1 added" appeared in the console window.
I pressed "Close" in dialog "Constraint Set". The dialog closed.
Dialog "Constraint Combinations" appeared top left, covering the console output. No text was added to the console window.
I pressed the "Done" button in the "Constraint Combination" dialog. The dialog closed.
Dialog "Constraint Set" appeared. It looked unchanged from its last appearance with just the one line added to "SPC Sets".
I pressed the "Close" button in the "Constraint Set" dialog. The dialog closed and "Press any key to continue2 appeared in the console window.
I did as I was told and the console closed and the program ended there.
No problems there!

I selected and built the WIn32 Release configuration.
I did exactly the same operations and observed exactly the same responses.
No problems there!

I reran both using "OK" buttons instead of "Close". Again, no problems.

I guess you need someone else to test it using your Windows/VS /IVF composer versions. What are they?

(BTW, look for spelling mistake "Constaints" in the "Constraint Set" dialog, top right edit box).

[dannycat]

Hi Anthony,

Thanks for looking at this again. You have followed the same run procedure that I did iwhen I got thecausing the crash with Access Violation error in both 32 and 64 bit versions.


I'm using the latest version of the compiler Intel Visual Fortran Compiler XE 12.1.4.325 [Intel 64] on Window 7 SP1. It appears that something has been introduced in the compiler or OSwhich is causing this problem. Hopefully someone at Intel could try both to see if they can get to the bottom of this.

If you run the release versions from within VS you get a prompt reminding you that no debugger information is available and do you want to continue. If you say yes and follow the program procedure as from the command window no crash occurs.

PS Thanks for spotting the spelling mistake.

[anthonyrichards]

I do not get that message from VS2005 when I start the /release/ version.

What version of Visual Studio are you using?

[dannycat]

I'm using VS2010. Iam getting the crash when I run outside of visual studio from a command window or double clicking the exe file.

[Jugoslav_Dujic · Accepted solution]

Hi everyone :)

I stumbled upon this thread, and had some spare time, so I took a brief look using the debugger.

The crash occurs when IFLOGM tries to process the controls on close (IFLOGM:DATA2DIALOG, line 1417). It tries to access the 17-th control of IDD_SPCSET, which is the SysListView32. However, it thinks it's a CTRL_PUSHBUTTON (=3):

[bash]select case (dlg % list(index) % control)
...
case (ctrl_pushbutton) logvalue = dlg % list(index) % logvalue(1) [/bash]In the Debug config, dlg%list(17)%control has garbage value (-31442161243), so it does not enter here, but in Release, it magically gets value 3 (pushbutton), and kaboom.

The culprit is in IFLOGM itself, line 1261, when the dialog is initialized:

[fortran]else ! Not a recognized control, zero out the sizes so that we don't ! try to deallocate them in DlgUninit. dlg % list(dlg%NumControls) % intsize = 0 dlg % list(dlg%NumControls) % logsize = 0 ...[/fortran] However, they never initialize the Control and Id structure members, and if you have an "unrecognized" control, you're at mercy of random (un)luck.

So, the bug is Intel's. You can get IFLOGM.f90 into your code, fix it and recompile it, wait for Intel to fix it, or use Xeffort :D. Though, admittedly, it is not maintained anymore.

[Steven_L_Intel1]

So if I understand you correctly, Jugoslav, the fix is to add these lines to the code you show for line 1261:

[plain]dlg % list(dlg%NumControls) % id = 0 dlg % list(dlg%NumControls) % control = 0 [/plain] Or should the id be set to ctrlheader % id ?

[dannycat]

Thanks Jugoslav. This has been driving me mad for months as it is quite random and depends upon the order of calls etc. I can't use the release versions so we have had to resort to debug executables which are much larger and probably slower in execution.

Steve, is it possible to fix andmake availablethe iflogm module in advance of the next official update so that I don't have to meddle with it myself? The directories are protected so I can't easily substitute files.

Would do you suggest as the best course of action?

Thanks,


Steve (dannycat)

[Steven_L_Intel1]

First, I want to be sure I understand the fix Jugoslav is suggesting. I have looked at IFLOGM and think I understand the issue, but Jugoslav probably knows that code better than I do.

If you want me to attach a fixed IFLOGM to a post here, or something like that, sure, I can do that. It will be not until the week of June 4 at the earliest, though, as I'll be away until then. But all you have to do is add the "fixed" source to your project. It will then compile locally and override the one in the product folder. Nothing special needed.

[dannycat]

When I try to compile a local version of iflogm I get several Bad Preprocessor Warnings referring to the following lines

! Temporary code until updated 64-bit headers are used

#IFDEF _X86_

#define GetWindowLongPtr GetWindowLong

#define SetWindowLongPtr SetWindowLong

#define DWLP_USER DWL_USER

#ENDIF

What should be done about these?

[Steven_L_Intel1]

Enable Fortran > Preprocessor > Preprocessing. You can do it for just that file.

[dannycat]

Thanks Steve,

The good news is that Jugoslav's fix has worked.

Will this fix be included in the next update?

[dannycat]

Steve,
My euphoria was short lived. While the problem seemed to be fixed in the Release configuration, all sorts of strange things are happening in the debug versions. The 32-bit won't run at all and the 64-bit misbehaves when dialog boxes are called up causing a crash.

Are there special compiler settings I need to apply overand above the one you mentioned in the earlier post for debug configurations?

I've fully rebuilt all configuartions after adding the revised iflogm module to the project.

[Jugoslav_Dujic]

Seems to work OK for me, in all configurations. I don't know the business logic, and not all buttons seem to produce visible output, but it didn't crash or exhibited any sort of weird behavior. (64-bit Win7)

[dannycat]

Unfortunately my main application (from which the small example was taken) is no longer working wrt normal dialog boxes. There seems to be some sort of misalignment of data because the text inlist-box controls is chopped up into strange segments. It suggests to me that there are some compiler switches that I have not set properly in order to recreate the iflogm module in the same way as the offical Intel version. Steve is away for two weeks so I'm a bit stuck until he returns.

One thing I've noticed is that the following code may violate array bounds (I currently havebounds checkingswitched on).

recursive subroutine PadStrFor( str )

!DEC$ ATTRIBUTES DEFAULT :: PadStrFor

character*(*), intent(inout) :: str

integer i

! scan up to the terminating null

i = 1

do while( i .le. len(str) .and. str(i:i) .ne. char(0) )

i = i + 1

end do

! pad the rest with blanks

do while( i .le. len(str) )

str(i:i) = ' '

i = i + 1

end do

end subroutine PadStrFor

the first do while is checking i and str(i:i) in the same statement. If the char(0) is missing this will cause the index to be higher than array size which willterminate the debug versions. The problem points towards the string termination character not being correctly appended to fortran strings in list-boxes.