Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I don't understand how not using the Delphi dialog components avoids shell extension DLL's causing havoc in your program if you are then calling into <em>COMDLG32.DLL</em> directly. You are still using the common dialogs, and those shell extensions are still being injected.</p> <p>More likely is that not using the components had a side effect in your code that obfuscated or masked the underlying problem, mitigating it to the point where it appeared to have been resolved.</p> <p>I suspect that is the case here too.</p> <p>I don't know what sort of hokey shell extensions you have installed on your system - perhaps you have some odd-ball extension that is causing some problems. All I can say is that in 15 odd years of Win32 programming with Delphi I have <em>never</em> known or even heard of the Delphi common file dialog components to be responsible for such behaviour.</p> <p>A simple way to test this of course would be to take the compiled EXE that exhibits the access violations on your machine, and run the same EXE on some other "clean-room" XP machine, i.e. with no 3rd party shell extensions installed what-so-ever.</p> <p>If the AV's disappear then you can be more confident that the problem is somehow related to a shell extension. Then by installing the known shell extensions onto the test machine one-by-one until the AV's re-appear, you may isolate the culprit and decide what to do about it... if it's one that your users/customers are unlikely to be using then you might choose to simply list it as a known compatibility issue and move on to other issues.</p> <p>If the AV's do not disappear however, then you can pretty much rule out the Delphi dialogs or any shell extensions as being somehow responsible at all.</p> <p>More generally, it would be most helpful to see the code in which the AV is occurring, if at all possible.</p> <p><strong>Addendum:</strong></p> <p>I did find <a href="http://www.vidisonic.com/2008/07/24/avoid-access-violation-error-from-opendialogtopendialogsavedialogtsavedialog/" rel="nofollow noreferrer">this reference to AV's occuring with the Common Dialog components themselves</a>. This though would not count as "a strange place" for an AV, being consistently reproducible - it seems - within the dialog components themselves. But I thought I would mention it anyway. Without knowing precisely where your AV's are occurring it is possible that this might be related.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload