🚀 go-pugleaf

"Remy Lebeau \(TeamB\)" <no.spam@no.spam.com> wrote:
>
>>           ::GetClassName( FParentForm->Handle, ThisClassName, 255 );
>>           hMutex = ::CreateMutex( NULL, TRUE, ThisClassName );
>
> That will only be reliable if the TForm class name is unique
> across all applications.

Yeah. That's not too bad though. We've been living with it.

> A better approach would be to append some kind of process-
> specific data to the mutex name to ensure its uniqueness,
> such as the process ID.  Then the TForm class name becomes
> irrelevant and is not needed at all:
>
>    char MutexName[32] = {0};
>    ::wsprintf(MutexName, "TSingleInstance.%0.10u", GetCurrentProcessId());
>    hMutex = ::CreateMutex(NULL, TRUE, MutexName);

But the point is to have the same mutex name for both
processes. Won't that break it?

> [...] but a better approach would be to not track two
> variables at all.  You can check the HWND provided by the
> callback to see if it matches the TForm::Handle before
> assuming whether it is the first or second instance.

Good point.

> When did I ever tell you that the TApplication window was
> not important?

Never. My point was that no one thought to use it to get the
window state of the main form.

> If you hook the TApplication window, it could greatly
> simplify your code, since you won't have to hook into any
> particular TForm objects anymore.

I was originally hooking into that but that one line of code
from Dennis means that the component doesn't need to anymore.

~ JD