Of mice and timers

Interesting question.

My first thought is, that in a single threaded client (the prowin32.exe) it won't matter in which of the only one available threads the time event is raised.

mikefe wrote:
Interesting question. 
My first thought is, that in a single threaded client (the prowin32.exe) it won't matter in which of the only one available threads the time event is raised.

Yeah .... however, remember the thread http://communities.progress.com/pcom/message/58118#58118 where it was shown that it *was* important to tie the GUI thread to the component event. If you look at the SynchronizingObject (http://msdn.microsoft.com/en-us/library/system.timers.timer.synchronizingobject.aspx) property, there is a comment

If the Timer is used inside Visual Studio in a Windows Forms designer, SynchronizingObject is automatically set to the control that contains the Timer. For example, if you place a Timer on a designer for Form1 
(which inherits from Form), theSynchronizingObject property of Timer is set to the instance of Form1.

This seems to indicate that we need to do this in the designer as well.

Anyone from PSC have an opinion on this ? I am slightly worried about using the timers with this unknown hanging around.

Julian,

The Timer control that appears in the default Toolbox is System.Windows.Forms.Timer (and not System.Timers.Timer). The Forms.Timer class doesn't have the SyncronizingObject property.

Is there any particular reason why you're using Timers.Timer as opposed to Forms.Timer?

Having said all of that, if I add System.Timers.Timer to the toolbox, and drop it on a form, the designer writes InitializeComponent as follows:

    method private void InitializeComponent(  ):
        
        /* NOTE: The following method is automatically generated.
        
        We strongly suggest that the contents of this method only be modified using the
        Visual Designer to avoid any incompatible modifications.
        
        Modifying the contents of this method using a code editor will invalidate any support for this file. */
        this-object:timer2 = new System.Timers.Timer().
        cast(this-object:timer2, System.ComponentModel.ISupportInitialize):BeginInit().
        this-object:SuspendLayout().
        /*  */
        /* timer2 */
        /*  */
        this-object:timer2:Enabled = true.
        this-object:timer2:SynchronizingObject = this-object.
        /*  */
        /*  */
        /* form1 */
        /*  */
        this-object:ClientSize = new System.Drawing.Size(292, 266).
        this-object:Name = "form1".
        this-object:Text = "form1".
        cast(this-object:timer2, System.ComponentModel.ISupportInitialize):EndInit().
        this-object:ResumeLayout(false).
        catch e as Progress.Lang.Error:
            undo, throw e.
        end catch.
    end method.    

Notice that the SyncronizingObject is set to the form.

I tested the above in 10.2B but as a rule, whatever Visual Studio generates, Visual Designer writes (the bulk of the stuff OEA does is type conversions; it otherwise takes whatever .NET gives it and writes that out).

The addition of the timer to the components collection is covered by what Matt said here: http://communities.progress.com/pcom/message/58380#58380

There's a nice explanation of the differences between the timers here http://msdn.microsoft.com/en-us/magazine/cc164015.aspx .

HTH,

-- peter

Thanks very much Peter. I had forgotten that there were different timers.

So, that was 2) and 3) answered

How about #1 ?

1) Should I use the THIS-OBJECT:components structure if I am using a timer in a non-ui class

Thanks very much Peter. I had forgotten that there were different timers.
So, that was 2) and 3) answered 
How about #1 ?
1) Should I use the THIS-OBJECT:components structure if I am using a timer in a non-ui class

I'd say yes: if the control has a requirement to have Dispose() called before destruction/deletion in the UI, I'd think that same requirement exists outside of the UI.

-- peter

You don't need a reference to components. You can call the System.Timers.Timer.Dispose whenever you are done using it. 'Components' is mostly used by the designer to keep track of design-time objects. Even UI oriented objects don't need to be added to the components if you are going to use them.