🚀 go-pugleaf

> Ah. So you are writing a plug-in of some form - in other words, a
> pre-existing application will call your DLL though a predefined
> interface?

Precisely, so it would be good to know the identity of the host. Currently I
am using FindWindow which works OK but assumes you know the name of the
calling app etc. A much more transparent way of doing this would be
beneficial.

It's funny because TApplication gives the ExeName of the host app but not
the Handle ??

Regards
David


"Alan Bellingham" <alanb@episys.com> wrote in message
news:04g9e1ds95n92cgrj36tdvi80ng3mtmmtd@4ax.com...
> [I'm moving this over to .nativeapi, since it's got nothing to do with
> language, BTW. Followup therefore set]
>
> "David" <davids@unite.com.au> wrote:
>
> >> But since you're writing the DLL, and the only
> >> way into your DLL is by a function call, why don't you just make the
> >> caller supply the handle you need to that function call?...
> >
> >The only problem is I don't have access to the exe source code to add
this
> >call. It's a standalone app and I have no control over it.
>
> Ah. So you are writing a plug-in of some form - in other words, a
> pre-existing application will call your DLL though a predefined
> interface?
>
> OK, so that's more of a problem, but not insuperable.
>
> I'd probably use EnumThreadWindows(). This requires a thread ID, which I
> suspect I could get using GetCurrentThreadId()
>
> Alan Bellingham
> --
> ACCU Conference 2006 - 19-22 April, Randolph Hotel, Oxford, UK