Timer/debugger interface problem

[Tom Edelbrok]

I have narrowed down a previous problem to the following more specific
items:

1) I have my startup object in VB.NET (VS 2003) set to Sub Main().

2) Inside of Sub Main() I do a "Application.Run(MyMainForm)"

3) Inside of MyMainForm_Load I create an object, ie: "poMyObj=new clsMyObj"

4) Within poMyObj I create a new System.Threading.Timer instance. I use a
delegate with AddressOf to fire a certain function whenever the timer fires
(the function
is called MyFunction(), and works fine).

5) Everything works like a charm!

6) HOWEVER: Inside the timer callback function (ie: the MyFunction()
function) I place a
breakpoint. When the debugger stops I try to display any labels from
MyMainForm and
just referencing them cause VB.NET to hang. This problem only occurs when
the debugger
trys to reference controls on the form. If I don't use the debugger the
controls can be
referenced by the object's VB code just fine - updating and refreshing data.


Why can't the debugger access the form's controls but everything else can?
Note: when
the problem is occurring I can display any local program variable values,
but I can't
display anything from the form unless I do it without stopping via a
breakpoint.

Any ideas?

Tom

 

[Chris Dunaway]

What is the interval of the timer? Is it possible the timer is firing
before the form's constructor is finished? Can you delay starting the
timer in your custom object until the last thing in the form;'s
constructor?

Just a thought.

 

[Tom Edelbrok]

An additional helpful note: If I do nothing but change the startup object to
MyMainForm then everything works perfectly, including debugger references to
the form's controls. If I then change back to Sub Main() as a startup
object, the problem comes back.

Tom

 

[Tom Edelbrok]

Very good idea but no luck ... I set the timer to make its first firing of
the callback after 5 relative seconds (ie: the "due" time). The timer fires
in exactly 5 seconds (ie: this will be 5 seconds after the constructor
completes, because the state timer is created in the constructor). But the
same problem happens.

Thanks for the idea.

Tom

 

[Tom Edelbrok]

One more piece of information:

When I set the form as the startup object, and the form_load creates my
application object, I display application.messageloop and find it to be TRUE
(ie: when my form timer fires).

But whenever I try the other situations described (ie: I create a state
timer within my application object, and set Sub Main() as the startup
object) I find that application.messageloop is always FALSE. This coincides
with the debugger not being able to access controls on the form.

Tom

 

[Tom Edelbrok]

I think I have it figured out:

Because I've been using a System.Threading.Timer it goes out and grabs a
free thread (I think), and the free thread grabbed has no message pump
running against it, therefore when in the debugger I can't access the
controls on the form.

But if I create a System.Windows.Forms.Timer instead, it all seems to work
fine - I can access my form controls from the debugger, and the timer
performs its tick functions perfectly. I'm guessing that because the
Systems.Windows.Forms.Timer is required to have a message pump and is
optimized for use with forms that it binds itself to the message pump of
your default application form's thread, and therefore has a message pump to
use.

Works great regardless of what's happening under the hood!

Tom