Runtime Error 204 :(

[bbonik]

Dear all,

I am new in using Borland C++ and I face a difficult problem to solve. I would be most grateful if you gave me some advice on it. (I use Borland builder 6, with winXP+SP3)

I have created a dll (mydll.dll) which opens a binary file, makes some processing and then saves the file in another location. The compilation of the dll was successful and has given no warnings or any problems at all.

I have also created a very simple application just to test the calling of the dll (just one button + one open dialog to give the location of the binary file). The code of this simple application is the following:

#include <vcl.h>
#include <string.h>
#include <windows.h>
#include "Unit1.h"
#pragma hdrstop
#pragma package(smart_init)
#pragma resource "*.dfm"

extern "C" __declspec(dllimport) void mydll(int P1, int P2, AnsiString P3, double P4, double P5, double P6, double P7, double P8);

TForm1 *Form1;
//---------------------------------------------------------------------------
__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)
{
}
//---------------------------------------------------------------------------

void __fastcall TForm1::Button1Click(TObject *Sender)
{
int P1,P2;
AnsiString P3;
double P4, P5, P6, P7, P8;

//getting the input values
P1 = 2816;
P2 = 3584;
P4 = 50;
P5 = 0;
P6 = 1;
P7 = 70;
P8 = 100;

if( OpenDialog1->Execute() == True )
{
P3=OpenDialog1->FileName;
}

mydll(P1, P2, P3, P4, P5, P6, P7, P8);
}


If I press the button, the open dialog box opens and after I give the filename, the dll is called, the processing is successfully done and the new file is saved also successfully. HOWEVER, if I close the application (press the X button) I get the following error:

“Runtime Error 204 at 40002FFC”

I tried everything I currently know and I couldn’t correct the problem.

Some extra information:
1. If I omit the calling of the dll in the simple application (line: mydll(P1, P2, P3, P4, P5, P6, P7, P8) there is no problem: I press the X button of the application and the window closes without a problem.
2. I also embedded the source code of the dll inside the code of the simple application (instead of calling the dll, I performed all the processing of the dll in the application) and there was also no problem at all.

Do you have any ideas of what might be wrong?

Thank you in advance,

bbonik

 

[luckieluc]

It seems to me there is a release problem of memory for instance an object that doesn't exist any more is called to release his memory.. which of course isn't possible. But I don't can find any reason in the code you were giving.

I should try to use try... catch commands to get some more information about the catched errors

 

[smays]

Uh,...help me out you guys with more experience creating DLL's: I don't think passing AnsiStrings (or pointers to AnsiStrings) to DLLs is kosher.

extern "C" __declspec(dllimport) void mydll(int P1, int P2, AnsiString P3, double P4, double P5, double P6, double P7, double P8);

And in fact, I believe the major issue with passing AnsiStrings is memory management. I have learned to rely on AnsiString almost exclusively, but I realize there are times when you absolutely have to use char * when passing string information, and I think this is one of those times. That said, if you want/need to use the AnsiString members (which I wouldn't blame you one bit), you could probably pass a pointer to a null-terminated character array and allow an AnsiString resident IN your DLL work it's magic.

extern "C" __declspec(dllimport) void mydll(int P1, int P2, char *P3, double P4, double P5, double P6, double P7, double P8);

...in your DLL (mydll.cpp)

void mydll(int P1, int P2, char *P3, double P4, double P5, double P6, double P7, double P8)
{
  AnsiString asYourAnsiString = P3;

/* Some ingenious processing */
}

I hope this helps!

Steve.

 

[bbonik]

Dear smays,

Thank you for your reply.

I tried your suggestion, but unfortunately the problem persists.

"Runtime Error 204 at 40002FFC"

 

[bbonik]

Problem solved.... but whyy?????
Sometimes programming can be SO illogical....
After extensive trial and error i solved the problem.

The last thing that mydll was doing was to open a new binary file

1. br = fopen(charpath, "wb");

2. write the processed data

3. close the file: fclose(br);

Omitting the line that closes the file just solves the probelm!!!!

The simple application can be closed now without raising the Runtime error....

But why?????

Is that logical?

Regards to all,

bbonik

 

[luckieluc]

This was the kind of error I expected.

Why? I think can not predict with the information you give it will be guessing why

 

[smays]

I'm stepping out on a limb here. From my experience it seems like file handles (and the associated file) are automatically closed when processes are ended. In my defense, I am always careful to close a file handle before moving on. I realize this may sound crazy based on the actual code, but, gee, I wonder if somehow the file handle was closed by some other means *before* your fclose(br) statement occurs. Gee, I wonder what would happen if you were to write some code to attempt to close a file handle twice:

FILE br = fopen(cFilename, "wb");

fclose(br);
fclose(br);

Forgive me if I am way off...

Steve.