Re: Can't use TComponent in thread object?



On 23 Nov 2006 18:14:35 -0800, "brett" <account@xxxxxxxxx> wrote:

Only the main thread can work with the GUI. To work around this, check
out the "Synchronize" procedure in your help. I don't see why you need a
separate TProgressThread (But it may depend on which socket library you
are using).

Thanks Nicholas. How can Synchronize help? I still run into a circular
reference problems. My form needs a reference to the thread class to
start the thread. The thread will need a reference to the form so it
can update a label. The update label method will be called using
Synchronize in the thread's execute method.

Personally I would use SendMessage back to the main thread
.



Relevant Pages

  • Re: Cant use TComponent in thread object?
    ... My form needs a reference to the thread class to ... The update label method will be called using ... Synchronize in the thread's execute method. ...
    (alt.comp.lang.borland-delphi)
  • Re: Cant use TComponent in thread object?
    ... out the "Synchronize" procedure in your help. ... My form needs a reference to the thread class to ... The update label method will be called using ...
    (alt.comp.lang.borland-delphi)
  • Re: Cant use TComponent in thread object?
    ... My form needs a reference to the thread class to ... The update label method will be called using ...
    (alt.comp.lang.borland-delphi)
  • Re: REQ: High Performance Access to a Static Objects List
    ... one reason to copy to a local variable would be so that the static object's reference could be updated by one thread without affecting the instance being used by another. ... Easier would be to synchronize all access to the list, but then even readers of the list would wind up serialized, which could hinder performance. ... If each element of the list requires extensive time to process during the iteration then it's possible copying the list could speed things up. ... However, you may still have synchronization issues between individual list elements if you do a shallow copy, or you may not find there's any significant performance benefit if you do a deep copy. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Thread safety and atomic assignment (again)
    ... If I understand this correctly, then synchronizing set and get would guarantee the correct counter behavior by making set and get *mutually* exclusive, which is not guaranteed by volatile. ... What you need to do to ensure your counter works as expected is to synchronize the "increment" operation. ... It is an excellent reference on what, why, and how in handle multi-threaded programming. ...
    (comp.lang.java.programmer)