Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>We have been experiencing the same issues you described (although in C++ Builder). There seem to be three possible solutions.</p> <p>1) Remove all the VCL dependencies from your DLLs. This is where my company is ultimately going, but it probably isn't very helpful advice short-term.</p> <p>2) Use packages instead of DLLs. This is the official answer we got from Borland support (long-ago). Apparently, if you create a package (BPL) instead of a DLL, it can do a better job figuring out the VCL initialization.</p> <p>3) I don't know what hidden problems are lurking with this third solution because it's quite a hack, but here is how I am currently applying a band-aid to our system until we can get the VCL out of our DLLs (and it <em>seems</em> to work).</p> <pre><code>WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int) { delete Application; Application = new TApplication(NULL); </code></pre> <p>But I have to confess that it makes me more than a little nervous (and it makes me feel kind of dirty). </p> <p>The idea, as I'm sure you can translate it into Pascal, is to destroy the original TApplication object that was created by the DLL and that was assigned to the <code>Application</code> global variable. Then create your own <code>TApplication</code> object in the executable's <code>WinMain</code> and assign it to the global <code>Application</code> variable. As long as nothing has stored a pointer to the original TApplication object before you get the opportunity to throw it away, it seems like it should be okay.</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