🚀 go-pugleaf

"Stefano Bonifazi" <stefboombastic@email.it> wrote in message
news:45a8c3c4@newsgroups.borland.com...

> I even thought of that at first, but I am used to Exception message
> to pop up when some Exception is thrown

Only if you are running inside the IDE's debugger at the time.
Otherwise no.  There will be no popup at all.

> instead I only got the Windows XP window message of request
> to send debug data to Microsof :(

Then you likely have a third-party debugger running that is
intercepting the exception before the application is.  Under normal
circumstances, that will NOT happen.  TIdTCPServer handles uncaught
exceptions internaly.

> __fastcall TNodzServerMainForm::TNodzServerMainForm(TComponent*
Owner)
>          : TForm(Owner)
> {
>   NodzIdTCPServer->ThreadClass=__classid(TNodzClientThread);
> }

Make sure that you set the ThreadClass property BEFORE the server is
activated.  Do not set the server to Active=true at design-time.

>    TNodzClientThread *pNodzThread =
> reinterpret_cast<TNodzClientThread*>(AThread);

Use static_cast instead of reinterpret_cast.

> TUpdateData(AThread,command,Data).Synchronize();

TUpdateData is a TIdSync-derived class.  You cannot construct it on
the stack like that.  VCL-based objects must be constructed on the
heap only.  That is a requirement of the VCL runtime.  In fact, the
C++ compiler can produce invalid code if you try to use VCL objects on
the stack.

>          void __fastcall DoSynchronize()
>          {
>           TNodzClientThread*
> pNodzThread=reinterpret_cast<TNodzClientThread *>(this);

Why are you doing that?  TUpdateData has no relation to
TNodzClientThread at all.  You can't cast one to the other like that.
I suspect you meant to cast the Thread property instead, correct?

    TNodzClientThread* pNodzThread = static_cast<TNodzClientThread
*>(this->Thread);

> Well at first I did not use TUpdateData, but I have been getting
> Access violation Exceptions

Then you are likely still using the code wrong to begin with.

> so I moved the switch block inside the Synchronized class

Which you should not have done.  There is nothing in that code that
needs to be Synchronize()'d in the first place.  Keep in side of the
OnExecute event handler where it belongs.

> before, without deriving from TIdPeerThread all worked well (before
> I used to allocate my class data in a thread safe class, inside the
> OnConnect event handler and assigning it to the data member of
> TIdPeerThread)!!

You have not shown that code yet.  But the fact that that code was
working but the TIdPeerThread derived class is not working tells me
that you did not set up the new code properly in the first place.


Gambit