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

[Lorri_M_Intel]

I have an unofficial, "official" build log available to me, and the interesting switches set to build iflogm.mod, on Windows, in the debug mode is:

ifort /Zi -Od -Ob0 -fpp -Qsafeseh -D_X86_=1 -D_M_IX86=1 -libdir:none -free

Now, the astute reader will note that several of these are redundant, because /Zi sets /Od and /Ob0

And, -free is also redundant because the file is named ".f90", but when you have a makefile with macros, sometimes there are redundancies.

However, I don't know if the /Qsafeseh flag might have an interesting build effect or not. I'm not sure where that is set in the Visual Studio property pages, but you can manually add it in the "Command Line" field.

Also, if you can get thedialog boxto work in either debug or release, you can try transferring command line switches from one configuration to the other, until it starts to work in the other configuration.

I hope this gets you further --

--Lorri

[dannycat]

I have been away for a week and have just got back to trying to solve this problem. Unfortunately I'm still struggling to get this to work. I have only added the two lines suggested by Jugoslav, added the module to the project and rebuilt it. I've tried the various compiler settings but something still seems to be wrong.

I will wait for an "unofficial" or "official" version to be built by Intel as I can't afford to spend any more time on this.

Hopefully Steve can resolve this when he returns from his vacation.

[Steven_L_Intel1]

I'm back, but don't see any new information that would help. Does the original example you posted in reply 6 still fail?

[dannycat]

Hi Steve,

I hope you had a good holiday.

The exampleI originally sent does still fail in 64 bit mode using the modified iflogm.f90. 32-bit version 'seems' to work OK. I've attached an updated solution with the 64 bit configuration added.

All I changed in iflogm was to add the two lines to set controld and iditems to zero.

else

! Not a recognized control, zero out the sizes so that we don't

! try to deallocate them in DlgUninit.

dlg % list(dlg%NumControls) % id = 0 ! Added by SS to correct bug when using non-supported controls

dlg % list(dlg%NumControls) % control = 0 ! Added by SS to correct bug when using non-supported controls

dlg % list(dlg%NumControls) % intsize = 0

dlg % list(dlg%NumControls) % logsize = 0

dlg % list(dlg%NumControls) % charsize = 0

dlg % list(dlg%NumControls) % callbacksize = 0

dlg % list(dlg%NumControls) % vartextptr = 0

end if

Have I understood this correctly?

Thanks again for looking into this.

[Steven_L_Intel1]

I can't get this program to fail with the changes on x64. What do I do in the program to trigger the error?

[dannycat]

Hi Steve,

I just run it from within Visual Studio (on XP 64-bit) in debug configuration andbefore any dialog boxes appear Iget this message:

Debug Assertion Failed!
Program C:\Win\Test1\Test1\x64\Debug\Test1.exe
File: f:\dd\vctools\crt_bld\self_64_amd64\crt\src\winsig.c
Line: 417

Expression ("Invalid signal or error!,0)

For information etc etc.

When I click Ignore and output window shows:

First-chance exception at 0x00000001401cf759 in Test1.exe: 0xC0000005: Access violation writing location 0x0000000001e2e000.

First-chance exception at 0x77edc034 in Test1.exe: 0xC0000005: Access violation reading location 0xffffffffffffffff.

The program is failing when the strings are being added to the first combo-box:

recursive subroutine ControlAddString( control, newstr )

!DEC$ ATTRIBUTES DEFAULT :: ControlAddString

type (ControlType), intent(inout) :: control

character*(*), intent(in) :: newstr

character*(STRSZ), pointer, dimension(:) :: charvalue

integer i, newsize

! assert that control is of type listbox, combobox or droplist

!DEC$ IF defined(DEBUG)

if (control%control .ne. ctrl_listbox .and. &

control%control .ne. ctrl_combobox .and. &

control%control .ne. ctrl_droplist) then

stop "assert in module dialogm"

end if

!DEC$ ENDIF

newsize = control%charsize+1

allocate( charvalue(newsize) )

! copy the current values

do i = 1, control%charsize

charvalue(i) = control % charvalue(i)

end do

charvalue(newsize) = newstr (FAILS at this Line !!!!!)

deallocate( control%charvalue )

control % charsize = newsize

allocate( control%charvalue(newsize) )

do i = 1, control % charsize

control % charvalue(i) = charvalue(i)

end do

deallocate( charvalue )

! update the dlg_numItems count

control % intvalue(1) = newsize - 1

end subroutine ControlAddString

The 'control%charvalue' is allocated and is blank but the program seems to crash at the"charvalue(newsize) = newstr" line resulting in the access violation error.

This suggests that the population of list/combo boxes is not working after the iflogm module has been modified. This behavior is also evidentin the main program, although symptoms varyon different computers.

AAAARGH! I've just tried it on my laptop (Windows 7 x64) and,as youexperienced,there is no apparent problem in the Test1 although when I try it on my main application the dialog boxes with list/combos no longer work properly and just hang i.e. no response to any button clicks.

The error messages seem to indicate that there is a memory alignment problem somewhere because the crashes are being reported to be caused by trying to read from an invalid memory location, although the location of the exceptionvaries.

During compilation of iflogm the compiler gives some warnings relating to misaligned fields for CONTROLTYPE, DIALOGEXTRABYTES & DIALOG structures.

Have you any suggestions?

Is it possible for Intel to repair, compile and make available the iflogm.mod and iflogmt.mod files using the exact same settings as those used for the standard issue?

Thanks.

[Steven_L_Intel1]

I don't think any special settings are needed for iflogm. None of the ones Lorri showed will have any real effect on behavior.

Try this. In w32ListCombo.f90, change:

integer,intent(in) :: nv
logical,intent(out) :: flgList(nv)

to:

integer(fWPARAM),intent(in) :: nv
logical(fLPARAM),intent(out) :: flgList(nv)

and see what happens.

[dannycat]

I tried what you suggested but it made no difference.

The w32ListCombo module is only used in my dialog boxes that are created using CreateDialog or those where SubClassing is required as in the two within the test example. 99% of my dialog boxes just use the standard IFLOGM functionality.

I also tried just copying the original iflogm.f90 from the Intel/compilers directory and rebuilding my projects with that included and with no changes whatsoever to the iflogm.f90 file. The same type of behaviour is observed to that I see when using my modified copy.

When I try to use a local iflogm all dialogs exhibit stange behaviour. As soon as I revert back to the original all work fine expect the ones containing the non supported controls.

I've also simply copied the two .mod files into my local directory and rebuilt and again everything works fine apart from those where the listview controls are utilised.

This indicates to me that the compiler I am using is producing different .mod files to those provided by Intel.

The attachment has four versions of the iflogm & iflogmt module files.

Intel - Copied from C:\Program Files (x86)\Intel\Composer XE\compiler\include\intel64
SS - Debug Version Using original Intel iflogm.f90 file compiled locally using Intel Visual Fortran Compiler XE 12.1.4.325
SSrel - Release Version Using original Intel iflogm.f90 file compiled locally using Intel Visual Fortran Compiler XE 12.1.4.325 (Should be identical to Intel but isn't)
SSmod - Release Version using modified iflogm.f90 incorporating Jugoslav's correction suggestion.

Is there a way of comparing .mod files?

[Steven_L_Intel1]

The .mod files are not relevant. What I see is that a Debug x64 build works fine. A Releae x64 build, however, brings up the dialog boxes but attempts to exit the application do nothing. I'll see if I can figure this out, but it may take me some time.

[dannycat]

Thanks Steve,

I looked into this a bit more over the weekend and although I didn't manage to fix it I did notice that the behaviour I observed was different to what Jugosav described.
I addedwrite statements to display the contents of the dlg data structure during initialisation and just prior to closure. For the listview controls my debug version produced garbage values (uninitialised)for the %id and %control terms while the release version did initialise these to zero (both using standard unchanged iflogm). This suggestes that the fix suggested will do nothing as it is the release version that falls over and values are already initialised to zero.

When I include the iflogm.f90 (with no changes)into my mainproject I still get strange behaviour in both versions.

I hope you get chance to look into this further as it is becoming ver frustrating.