idIRC, Hanging problems, code is fine, but not when called in idIRC events?

[Commodianus]

Hello everyone.

I'm working on an IRC client, and I've got one major snag. My code for
creating
MDI Child windows is good, and works, for example if I stick it on a
button's
click event. However, if I for example, catch a PrivateMessage, I
check if
there's a window made for that, and if not, create one. This is the
problem.
When I put the code in my PrivateMessage event handler, the
application hangs.
No exceptions or anything, but it's locking and becoming unresponsive.

Does this perhaps have something to do with being a "blocking mode"
client? and
if so what is the workaround?

There's actually a couple instances where the same thing happens, for
example
the onjoin event, naturally I want to check if I'm the one joining a
channel,
create the channel window etc.

Advice?

Kind Regards,
Paul S.

[Jamie]

You did not specify if you're multi-threading?

Also, windows has issues and the effects change on different OS versions
where if you do some GUI creation of objects while in a WM_KEY..UP/DOWN
event, things goes wrong. Normally what I do is, pump a custom message
in the system to handle that after this even is over, which is one
reason why you see the VCL use a lot of CM_XXXXXXX messages..

So, try to inject a custom message that will be handled in your code
and arrives after you have handled to current problem area to create
your window. etc..

Things to think about.

[Rob Kennedy]

Commodianus wrote:
> I'm working on an IRC client, and I've got one major snag. My code for
> creating
> MDI Child windows is good, and works, for example if I stick it on a
> button's
> click event. However, if I for example, catch a PrivateMessage, I
> check if
> there's a window made for that, and if not, create one. This is the
> problem.
> When I put the code in my PrivateMessage event handler, the
> application hangs.
> No exceptions or anything, but it's locking and becoming unresponsive.
>
> Does this perhaps have something to do with being a "blocking mode"
> client? and
> if so what is the workaround?

Probably, yes. Indy executes its event handlers in threads other than
the GUI thread (because it's also using blocking sockets to *listen*
with threads other than the GUI thread). If you need to do GUI work in
response to an Indy event, you'll need to synchronize that work with the
main thread. You could post a message notification to whatever form is
interested in the event, for example.

--
Rob