Access violations in strange places when using Windows file dialogs

Posted by Robert Oschler on Stack Overflow See other posts from Stack Overflow or by Robert Oschler
Published on 2010-03-17T22:07:19Z Indexed on 2010/03/17 22:11 UTC
Read the original article Hit count: 288

Filed under:
|
|
|
|

A long time ago I found out that I was getting access violations in my code due to the use of the Delphi Open File and/or Save File dialogs, which encapsulate the Windows dialogs. I asked some questions on a few forums and I was told that it may have been due to the way some programs add hooks to the shell system that result in DLLs getting injected in every process, some of which can cause havoc with a program. For the record, the programming environment I use is Delphi 6 Professional running on Windows XP 32-bit.

At the time I got around it by not using Delphi's Dialog components and instead calling straight into comdlg32.dll. This solved the problem wonderfully.

Today I was working with memory mapped files for the first time and sure enough, access violations started cropping up in weird parts of the code. I tried my comdlg32.dll direct calls and this time it didn't help. To isolate the problem as a test I created a list box with the exact same files I was using during testing. These are the exact same test files I was selecting from an Open File dialog and then launching my memory mapped file with. I set things up so that by clicking on a file in the list box, I would use that file in my memory mapped file test instead of calling into a comdlg32.dll dialog function to select a test file.

Again, the access violatons vanished. To show you how dramatic a fix it was I went from experiencing an access violation within 1 to 3 trials to none at all. Unfortunately, it's going to bite me later on of course when I do need to use file dialogs.

Has anyone else dealt with this issue too and found the real culprit? Did any of you find a solution I could use to fix this problem instead of dancing around it like I am now?

Thanks in advance.

© Stack Overflow or respective owner

Related posts about access

Related posts about violation