"Jamie Dale" <j.dale@turboz.net> wrote in message
news:448022a2@newsgroups.borland.com...
> Drop one of those onto the form (and any others you have in the
> app for best results)
TIdAntiFreeze is a singleton component. It can only be instantiated once
for the entire project. Place it on the MainForm only.
> it will force the forms to be redrawn/refreshed while the indy
> component is still working/freezing.
Which is exactly its pitfall. It not only allows repainting/refreshing, but
ALL pending messages are processed. That means that all message-based event
handlers can still be triggered, etc. Which can be a problem if you don't
want your event handler code to account for re-entrant issues, etc.
TIdAntiFreeze is sort of like the bastard child of Indy. Even the Indy
developers avoid it when possible. It is a necessary component when doing
work in the context of the main thread and you don't want to block the UI.
But that is the kind of thing that threads were invented for in the first
place. TIdAntiFreeze really should be avoided whenever possible.
> Assuming your version of Indy still has the Antifreeze component
All versions of Indy have it.
> you really should use it on every form whenever you use an Indy component.
You can't use it on multiple forms simultaneously.
> Indy uses blocking sockets (I think - might be non-blocking I can't
> remember now but they're apparently evil these sockets)
Indy uses blocking sockets. Blocking sockets are not evil. That is a
misconception. In fact, almost every socket stack implementation on every
OS is blocking by default. If blocking sockets are evil, then every OS
implementation of sockets is evil by default. Asynchronous sockets are a
Microsoft invention from the Windows 3.1 days when true preemptive threading
didn't exist yet. Microsoft needed a way to implement event-driven sockets
so that Windows would not be blocked. So WinSock v1 was invented to
bastardize the socket standards to include support for asynchronous socket
operations using window messages. Later on, WinSock v2 expanded on that by
introducing other asynchronous socket models, such as native support for
Overlapped I/O and Event objects.
> whenever you use an Indy component, it will freeze while it's doing stuff.
As it should be. That is by design.
> Antifreeze is their solution to this and works very effectively.
Not as effectively as you think. Threading is a better solution, and one
that Indy embraces much more than it does for TIdAntiFreeze.
Gambit
