Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <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>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. COI worried about that for a long time (still do) but a few more details. I recently moved my entire setup to a new computer system with a fresh Windows XP install. In addition, the project I made for testing the memory mapped file code is a bare bones project with only a few of my "common routine" files included. All the components on the plain vanilla main form are stock Delphi VCL (listbox, button, etc.). Admittedly my component palette is jam packed with third party items, including the JCL and JVCL, but I don't think code from unused components gets compiled into the project.
      singulars
    2. COThat depends... if those 3rd party units are in your uses list and contain initialization sections then you may find you are dragging things in that you perhaps aren't expecting. But still, seeing exactly where/when these AV's occuring (i.e the source code) would be most helpful. Otherwise any assistance can only come from "psychic debugging" (read: guesswork/speculation).
      singulars
    3. COThe errors in my current project are happening during a Move() call when I attempt to copy data from the memory mapped file data buffer to a variable. It happens during the "repeat move bytes" loop where bytes are being copied by the Move instruction (with the execution pointer in the CPU window since it's assembler code). When I don't make any file dialog calls the errors vanish. I'll check the initialization sections for the 3rd party components and the DLL list in the Event viewer.
      singulars
 

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