🚀 go-pugleaf

Hi all, hope everyone's had and good (and festive :-) x-mas.

I've been debugging a DLL that I was working on before x-mas and I've come
across and strange (but in hindsight logical) anomaly which I'm hoping
someone can help me with.

I traced the bug to a section of code that reads in config information from
the registry.  As is common with all our software, the registry keys are
located under the company name with in the registry.  Within that key we
have the applications executable name, followed by a sub key which relates
to the application version number - we do this to avoid conflicts with
different versions.

To ensure that the version number is always upto date and adhered to, it is
check, at run-time, using the GetFileVersionInfo api.  This is then
concatenated together to form the registry key that we want to examine.  All
straight forward, no problems here!!!!

Now because this is standard in our company, I wrote a couple of basic
classes to deal with this.  The first one, TSystemTools has a set of methods
(ok everyone, don't rip me, I know it shouldn't be a class persay) to return
things like the version number and the path of the current ??application?? -
now this is where the problem has arisen.  The method, GetAppPath(), is
coded to retrieve the path of the current application / DLL based on the
value of ParamStr(0) i.e. AnsiString szRtnPath = ParamStr(0);  Now when I've
included this class in my DLL, it seems to be returning the value of the
calling application and NOT the DLL which is the thing that I need the path
to, so I can pass it to my VersionInfo() method and thus retrieve the
current version number of my DLL.  I never really concidered that fact that
a DLL doesn't really have any parameters passed to it, but I never thought
it would return that value of the calling application....

I hope this makes sense - so my question is, how to I fine the path to my
DLL, at run-time, when it is loaded into memory.

Many, many thanks in advance,

Mike C