> TIdAntiFreeze is a singleton component. It can only be instantiated once
> for the entire project. Place it on the MainForm only.
>
I beg to differ however I got an instance on every form in my project.
Though I must confess, it is the same program that is not working properly
on my 2nd machine (Though like I said it works perfectly on this one).
>> 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.
Thats fair comment! - I just learnt to work with it to be honest and it's
never been a problem yet.
>> Assuming your version of Indy still has the Antifreeze component
>
> All versions of Indy have it.
Good, good
>
>> you really should use it on every form whenever you use an Indy
>> component.
>
> You can't use it on multiple forms simultaneously.
I have - made quite a big difference too.
>
>> 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.
Yes but you are taking me out of context. I was having a laugh at what is
quoted on the Indy website GGrrrr
>> whenever you use an Indy component, it will freeze while it's doing
>> stuff.
>
> As it should be. That is by design.
I never said differently.
>> 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.
Ok but whatever floats your boat..
