Problems with COM access to Common Dialogs Open and Save

[anthonyrichards]

I am practising using COM to access the Microsoft Common Dialog Controls.
I used the IVF module wizard to generate the COM interfacesof the objects defined in
C:\\WINDOWS\\system32\\COMDLG32.OCX.

I wrote some code to initialize COM and create a Common Dialog Object. Then I added code to open the various dialogs. I found that I could open the Printer dialog, the Color dialog and the About dialog using the functions supplied in the module, but I have signally failed to get the File Open and File save dialogs to display.

When I run in debug mode and step into, for example,

res=$ICommonDialog_ShowOpen(ptrComDlg)

I find that when I step over the line arrowed below,

INTEGER(4) FUNCTION $ICommonDialog_ShowOpen($OBJECT)
IMPLICIT NONE

INTEGER(INT_PTR_KIND()), INTENT(IN) :: $OBJECT ! Object Pointer
!DEC$ ATTRIBUTES VALUE :: $OBJECT
INTEGER(4) $RETURN
INTEGER(INT_PTR_KIND()) $VTBL ! Interface Function Table
POINTER($VPTR, $VTBL)
$VPTR = $OBJECT ! Interface Function Table
$VPTR = $VTBL + 268 ! Add routine table offset
ICommonDialog_ShowOpen_PTR = $VTBL
=> $RETURN = ICommonDialog_ShowOpen($OBJECT)
$ICommonDialog_ShowOpen = $RETURN
END FUNCTION $ICommonDialog_ShowOpen


the debugger jumps to a line (see below) in the SetInitDir function FUNCTION $ICommonDialog_SetInitDir

INTEGER(4) FUNCTION $ICommonDialog_SetInitDir($OBJECT, pbstrInitDir)
IMPLICIT NONE
INTEGER(INT_PTR_KIND()), INTENT(IN) :: $OBJECT ! Object Pointer
!DEC$ ATTRIBUTES VALUE :: $OBJECT
CHARACTER(LEN=*), INTENT(IN) :: pbstrInitDir ! BSTR
INTEGER(4) $RETURN
INTEGER(INT_PTR_KIND()) $VTBL ! Interface Function Table
POINTER($VPTR, $VTBL)
INTEGER(INT_PTR_KIND()) $BSTR_pbstrInitDir ! BSTR
$BSTR_pbstrInitDir = ConvertStringToBSTR(pbstrInitDir)
$VPTR = $OBJECT ! Interface Function Table
$VPTR = $VTBL + 72 ! Add routine table offset
ICommonDialog_SetInitDir_PTR = $VTBL
=> $RETURN = ICommonDialog_SetInitDir($OBJECT, $BSTR_pbstrInitDir)
CALL SysFreeString($BSTR_pbstrInitDir)
$ICommonDialog_SetInitDir = $RETURN
END FUNCTION $ICommonDialog_SetInitDir

and a message box appears saying "Windows has triggered a breakpoint in comdialog.exe.
This may be due to a corruption of the heap, and indicates a bug in comdialog.exe or any of the DLLs it has loaded.The output window may have more diagnostic information".

This also happens with the attempt to use the ShowSave function. Any ideas what is the cause of the failure?
I have added code to set filters, filename and directory before attempting to use ShowOpen and ShowSAve to no avail. Is there a way to start the dialogs using SetAction?

P.S. I use IVF composer XE 2011 and VS2005 pro and Windows XP Pro

[Paul_Curtis]

All of these common dialogs are easy and straightforward to incorporate in F90 codes using standard API calls, no need for the complexity of COM. Is there some reason to want to do it this way?

(added edit) Well, I now see you have answered this question elsewhere. So far, however, the older GetOpenFileName() etc. common dialog functions do work perfectly well with Vista and Win7; perhaps they will be eliminated from future windows editions.

[anthonyrichards]

Yes, GetOpenFileNAme + GetSaveFileName have shown problems for some users of Windows Vista and 7 and multithreading. The newest operating systems supply new preferred alternatives which will required COM interfaces to access them.
See IFileDialog, IFileOpenDialog, and IFileSaveDialog.
So I just wanted to get some practice in using COM to access the present versions and work out howto do it.

[JohnNichols]

Dear Anthony:

I use Win7 Ultimate with SP1, VS 2010 and the latest Fortran compiler.

If you include the full program directory I am happy to run it and look at it. A zip file makes it easy.

I am not perfect yet, but slowly getting better.

I agree that playing with the stuff is the best way to learn it.

John Nichols

[anthonyrichards]

I have tried using the SetAction and Set_Action functions from the module that IVF generated from COMDLG32.OCX and I find that setting the action number = 5 displays the printer dialog, action=4 displays the font dialog and action 3 displays the color dialog. Assuming the Open and Save dialogs are part of the same sequence, I tried action = 2 and 1 and action= 6 and action=7, but no dialogs were displayed.
I have used the Get versions of the interface functions to check that the Set functions are working OK, including SetAction and Set_Action etc.

It appears that something in the COMDLG32.dll or OCX is not behaving as it should, or else the generated module code is incorrect.
However, I have used the Object viewer to examine the Type library in COMDLG32.OCX and find that all the table offsets used in each function in the generated module differ by a uniform 4 bytes all the way through and follow the sequence that the methods are listed in the Object viewer.

I have tried usingan earlier version of COMDLG32.dll but still no luck with ShowOpen and ShowSave.

Can anyone at Intel help? See earlier post for some code exhibiting the problem.

[anthonyrichards]

It does not look like this problem is solvable.
I have found an error message 'Invalid address specified RtlFreeHeap(00150000, 001644c8)' which, according to my searches, means that a pointer for one heap is wrongly being given to free another heap. This is completely out of my control.

[IanH]

Forgive me if this is waaaaay off the mark (I use COM to talk to Excel and that's it), but are you sure that you are actually trying to reference the right type library? When I read the docs here all the procedure names and interface names etc are all different from what your fortran module created f90 file indicates.

I can get the COM based dialog up, but to do so I used the MIDL compiler against the ShObjIdl.idl file from the the Platform SDK to generate a type library then I applied the fortran module wizard to that. There were errors in the resulting .f90 file (type name and argument name clashes, redefinitions of GUID etc) and I retyped a few arguments to more convenient things after looking at the equivalent C interfaces.

But I've still not yet got an actual filename out. I think I have to get a shell object back using GetResults and then get the filename from that. Anyway, past my bedtime now.

OpenFileDlg.f90

ShObjIdl.f90

This is a serious amount of work just to get a filename from the user. The classic API's are just so much easier. I don't think they'll be dropping them anytime soon.

[anthonyrichards]

Thanks, but I'm using Windows XP Pro. Your reference applies to Windows Vista and Windows 7 operating systems I believe.

As far as I am aware, COMDLG32.OCX is the standard container for the interfaces and methods required to handle the common dialogs (Visual Basic also uses it as the standard reference to obtain access to CommDialog objects). I can use the module-generated code to set and get the filename, initial directory, file filters, fiter index, flags etc all OK. I can use the module code to open the Printer, Colour, font and About Box dialogs OK.
but it fails, as I say, when trying to open the GetOpen and GetSave dialogs. With allowance for the 4-byte increments in table offsets, the code is identical for showing all the dialogs, so I am at a loss as to why those two dialogs fail in exactly the same way, whereas the other four open OK. I am leaving it for now.