Path of current DLL (ISAPI)

I have a function that will return current path for application OR dll.  Back soon...

Here's some functions that I use.  The basic one is GetModuleFileSpec, and the others derive from that.

{ Get Application or DLL Module name / path }
{ These functions work for both executables AND dll's }

function GetModuleFileSpec: String;
var
  cret: integer;
  ModName: array[0..MAX_PATH - 1] of Char;
begin
  Windows.GetModuleFileName(HInstance, ModName, SizeOf(ModName));
  cret := GetLongPathName(ModName, ModName, SizeOf(ModName));
  SetString(Result, ModName, cret);
end;

function GetModuleName: String;
begin
  Result := ExtractFileName(GetModuleFileSpec);
end;

function GetModulePath: String;
begin
  Result := ExtractFilePath(GetModuleFileSpec);
end;

function AppChangedExt(const NewExt: String): String;
begin
  Result := ChangeFileExt(GetModuleFileSpec, NewExt);
end;

function AppIni: String;
begin
  Result := AppChangedExt('.ini');
end;

function AppLog: String;
begin
  Result := AppChangedExt('.log');
end;

beaten  :)

ugh .. nobody checked what ParamStr(0) does ?
stuff you wrote guys :)
it's a call to GetModuleFileName

That's pretty funny.  

I assumed that this was something that had been fixed recently in Delphi, but I checked back to an old copy of Delphi 3 and it looks like it used GetModuleFileName even then.

BUT in ParamStr it passes 0 for the Module handle and I suspect that this does not work for DLL's which is why I wrote these other functions.

from the help:


hModule

Identifies the module whose executable filename is being requested. If this parameter is NULL, GetModuleFileName returns the path for the file used to create the calling process.

and yes it works in ISAPI dlls as well

I use :
GetModuleFileName(hInstance, PChar(LogFile), MAX_PATH);

in my pas2html.dll isapi :
http://lee.nover.has.his.evilside.org/isapi/pas2html.dll/pas2html?File=/delphi/MiscFiles/pas2html_isapi_dll.pas

I'm confused, Lee.  Are you saying that ParamStr(0) does or does not work in DLL's.

Firstly you seem to indicate it does, but then you go on to say that you use GetModuleFileName() in your dll?

ah sorry ... if you use 0 then it will return the name of calling process .. that is the .exe that called your dll
so you need to use hInstance to get the dlls name
:)

Thanks it works
Inthe, you assumed that function parameters are called from right to left, isn't it?

Motaz

motaz,
i dont know what your meaning ?
what/whose function parameters

the calling conventions specify the order of paramater passing .

What the f#$%?

Why do I bother answering these questions if someone who gives fundamentally the same answer AFTER me is given the points?

That's the second one today.

To Hamlet:
I already gave you 200 points : https://www.experts-exchange.com/jsp/qManageQuestion.jsp?ta=delphi&qid=20321569

I accept Inthe answer because it is very concise solution.

To Inthe:
I mean in your function calling:

SetString(dllpath,fullPath,GetModuleFileName(HInstance,fullPath,SizeOf(fullPath)));


GetModuleFileName is called first, then the result will be returned in FullPath variable, then when SetString call FullPath, it will be already set to a value,
If the function was like this then the situation will be diferent I think:

SetString(dllpath,GetModuleFileName(HInstance,fullPath,SizeOf(fullPath)), FullPath);

Suppose in this case this was the order of parameters.

Another example:

CallSomthing(First, CallAnother(Second), Second);

Is this is a right call? or I should use:

Size:= CallAnother(Second);
CallSomthing(First, Size, Second);

I know that Delphi call the parameters from right to left, does it affect the previous examples:

Example3:

CallSomthing(First, CallAnother(Second), CallThird(Second));

I think it is different than:

CallSomthing(First, CallThird(Second), CallAnother(Second));

Sorry for becoming off-topic.

Motaz

Hi Motaz...

The order of the parameters doesn't matter in this case. Instead the decisive thing is that 2 calls are done. And in x86 assembler each call is executed after the other, not at the same time. Now (according to your example) Delphi can't CallSomething before it has CalledAnother. This just wouldn't work. So Delphi has to CallAnother first. You see? It has nothing to do with the order of the parameters, but with the order of the calls.

Regards, Madshi.

Sorry  (insert embarrassed emoticon here).

I had just finished checking another question, where the person accepted a poor solution where I had given them the correct answer, and was also in a foul mood for other reasons.

the compiler will know ,and it would most likely complain if you had something that wouldnt work.

personally in your scenario above i would use this
CallSomthing(First, CallAnother(Second), Second);
if the compiler will let me for that particular function rather than
Size:= CallAnother(Second);
CallSomthing(First, Size, Second);

literally to save on the amount of lines used ,makes it easier for me 2 find problems if a unit is say 400 lines rather then 1500 ..

To Hamlet, inthe code is working properly without problem, moreover he points me to a new type of calling fucntions that I wasn't use befor.

To Madshi, what about (Second) Parameter in this type of calling:

CallSomthing(First, CallThird(Second), CallAnother(Second));

Suppose that Second contain 1, CallAnother adds 1 to Second, and CallThird multiply Second by 5. What is the last result of Second?

Motaz

:-)   In this specific case the order of the parameters DO have a meaning. So I would split the calls into seperate lines/instructions.

That's what I ment.

Yeah, but with Barry's code it's different.

Yes, that's what I get.
The issue is only applicable on the last example.