I think this question is primary for Jcl, but maybe somebofy else would be able to help.

Situation:
First part:

1) I have sources of Joint.dll library, written in VS, using C++
2) In VS project's "General" menu, "Output directory" is directory with Lite-c project
3) In VS project's "Debugging" menu, Command is "D:\GS\acknex.exe" and "Command arguments" is "D:\GSwork\NewtonWrapper\WrapperLitec\main.c"

So, if i run project in Studio: DLL compiles, Lite-c lanuches, and if i have breakpoints in DLL's code, project stops as it reaches breakpoint.

Second part:

4) Lite-c calls function from DLL:

5) In VS this function lookings like


Launching:

If i would comment CreateCustomPlayerController() call in Lice-c, everything would work fine (well, Player Controller wouldnt work, but there would be no crashes).

FIRST QUESTION
How can i know in Lite-c that DLL is loaded?
If i place breakpoints in DLL's source, complier stops there only when i launch project ONLY FIRST time. Looking like that 2nd and 3rd times, Lite-c uses another DLL as it ignores breakpoints while compiling.

How i sovled this problem: i added
wait(-1);
in Lite-c before first function calling. This gives time to load DLL (well, i think so) and now VS stops every time when compiler reaches breakpoint.

This works for now, but i would be glad to have in Lite-c some function like
bool DllIsLoaded(name_of_dll);
so i would be able to know, if DLL is loaded for current user (i'm afraid, for some users time of loading DLL could be very differ, so this would make my project unstable)

Continue launching:

Now, i uncommented function CreateCustomPlayerController() in Lite-c... and got engine crash error. So, i place first breakpoint on the string number /* 1 */ and second breakpoint on the string /* 2 */ in C++ code.

Well, looking like everything allright: engine stops at the /* 1 */ and i started to learn code. At the line /* 2 */ i noted that &matrix[0][0] holds wrong meanings of cells. Ah, i had used wrong pointers in Lite-c.

Now read carefully, please

I change Lite-c code from

to

, then launch project(still with breakpoints in VS), go through breakpoints and EVERYTHING WORKS FINE(!!!).
I feel myself very happy, i remove breakpoints, launch project again and GOT A CRASH. What a ... Now i add breakpoints again, launch project and GOT A CRAHS again WITHOUT stopping at the breakpoints.

If i would change back from

to

, then run, got a crash, then change again, then run again, this would work for one time.

I'm totally lost.

SECOND QUESTION, very simple
WHAT'S GOING ON???

I want to say sorry for a large number of letters, but i tried to describe problem in a clear way. Also, i'm sorry for BIG LETTERS in some cases, but they are imporatnt, as i think.
I think, i could make a video of this, if i'm not clear.

Looking like i solved this with adding



Well, so now the question is more simple: how can i know that DLL is loaded, without wait(-1); and wait(5); ?

ermm, maybe the WINAPI function GetModuleHandle could help? It retrieves a handle to the loaded module so check if GetModuleHandle("my.dll") returns a handle, if it does > it's loaded. If it returns NULL then its not loaded.

At least that is my understanding of the function, i've never had to use it.

You could check in a while loop...


Is lite-c loading the DLL automatically? Otherwise you could use the LoadLibrary function and that returns a valid handle if the DLL is successfully loaded.

Thanks for good idea.

But this dont work... i added

and removed all wait(); function calls, but engine crashes as if there is no waiting for loading DLL at all

you dont' need a wait, just let it keep looping, break; out of the loop when GetModuleHandle returns true.

Em... i dont see the difference between

and


Anyway, both methods dont work.

havn't read the first post, but what enduriel wanted to express is:

while(1)
{
if(GetModuleHandle("Newton.dll")) { break; }
}

or:

while(!GetModuleHandle("Newton.dll"))
;

greetings

Hi, TechMuc
I mean that neither

nor

dont work as it expected


If i change

with

i get a crash...