473,563 Members | 2,295 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Event Handling in vb.net

My unstanding of all VB up to and including vb6 is that an event could
not "interrupt" itself.

For instance if you had a timer event containing a msgbox then you would
only get one message.

However in vb.net you get continual messages (even setting the system
modal property).

Firstly, are these two assumptions right and if so what is the approved
way of stopping the event interrupting itself?

Secondly is this true of all events in VB.net and do I have to protect
myself when I am in any event?

TIA
Nov 21 '05 #1
12 4112
Jack,
My unstanding of all VB up to and including vb6 is that an event could not
"interrupt" itself. Any Windows Event can "interrupt" itself by calling DoEvents since VB1.

In both VB.NET & VB6 MsgBox & MessageBox.Show calls the equivalent of
"DoEvents", I suspect to ensure the underlying form is properly displayed
(the Paint event is handled).

When you call DoEvents or its equivalent any event can occur a second time,
except I believe Paint and one other.
Firstly, are these two assumptions right No
and if so what is the approved way of stopping the event interrupting
itself? If I call DoEvents while processing an Event, I normally set a flag in the
event that says it is already being handled.

Something like:

Private Sub Timer1_Tick(ByV al sender As System.Object, ByVal e As
System.EventArg s) Handles Timer1.Tick
Static beingHandled As Boolean
If beingHandled Then Exit Sub
beingHandled = True
' do work here
beingHandled = False
End Sub
Secondly is this true of all events in VB.net and do I have to protect
myself when I am in any event? You only have to protect yourself in any event that DoEvents is explicitly
or implicitly called.

FWIW there are events that are not Windows Events, these events are not
handled via the DoEvents keyword. Windows Forms applications have a message
pump (Application.Ru n) that causes Windows Messages in the Windows Message
Queue to be converted into Events, each event is handled inturn, unless you
call DoEvents with causes the next message in the message queue to be
converted into its respective Event. Hence if you call DoEvents explicitly
or implicitly an event can be raised a second time. This can be a source of
problems if DoEvents is called with in Timer Tick, ToolBar ButtonClick,
Button Click and MenuItem Click events.

Hope this helps
Jay
"Jack Russell" <ja***@norubbis h.tpg.com.au> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. .. My unstanding of all VB up to and including vb6 is that an event could not
"interrupt" itself.

For instance if you had a timer event containing a msgbox then you would
only get one message.

However in vb.net you get continual messages (even setting the system
modal property).

Firstly, are these two assumptions right and if so what is the approved
way of stopping the event interrupting itself?

Secondly is this true of all events in VB.net and do I have to protect
myself when I am in any event?

TIA

Nov 21 '05 #2
Doh!
Depending on the nature of the event processing a Try/Finally might be
beneficial in the Timer.Tick event
Private Sub Timer1_Tick(ByV al sender As System.Object, ByVal e As
System.EventArg s) Handles Timer1.Tick
Static beingHandled As Boolean
If beingHandled Then Exit Sub Try beingHandled = True
' do work here Finally beingHandled = False End Try End Sub
As the Finally will ensure that the beingHandled flag is turned off,
especially important if you are using a Global Exception handler.

Hope this helps
Jay

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:OM******** *****@TK2MSFTNG P10.phx.gbl... Jack,
My unstanding of all VB up to and including vb6 is that an event could
not "interrupt" itself.

Any Windows Event can "interrupt" itself by calling DoEvents since VB1.

In both VB.NET & VB6 MsgBox & MessageBox.Show calls the equivalent of
"DoEvents", I suspect to ensure the underlying form is properly displayed
(the Paint event is handled).

When you call DoEvents or its equivalent any event can occur a second
time, except I believe Paint and one other.
Firstly, are these two assumptions right

No
and if so what is the approved way of stopping the event interrupting
itself?

If I call DoEvents while processing an Event, I normally set a flag in the
event that says it is already being handled.

Something like:

Private Sub Timer1_Tick(ByV al sender As System.Object, ByVal e As
System.EventArg s) Handles Timer1.Tick
Static beingHandled As Boolean
If beingHandled Then Exit Sub
beingHandled = True
' do work here
beingHandled = False
End Sub
Secondly is this true of all events in VB.net and do I have to protect
myself when I am in any event?

You only have to protect yourself in any event that DoEvents is explicitly
or implicitly called.

FWIW there are events that are not Windows Events, these events are not
handled via the DoEvents keyword. Windows Forms applications have a
message pump (Application.Ru n) that causes Windows Messages in the Windows
Message Queue to be converted into Events, each event is handled inturn,
unless you call DoEvents with causes the next message in the message queue
to be converted into its respective Event. Hence if you call DoEvents
explicitly or implicitly an event can be raised a second time. This can be
a source of problems if DoEvents is called with in Timer Tick, ToolBar
ButtonClick, Button Click and MenuItem Click events.

Hope this helps
Jay
"Jack Russell" <ja***@norubbis h.tpg.com.au> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
My unstanding of all VB up to and including vb6 is that an event could
not "interrupt" itself.

For instance if you had a timer event containing a msgbox then you would
only get one message.

However in vb.net you get continual messages (even setting the system
modal property).

Firstly, are these two assumptions right and if so what is the approved
way of stopping the event interrupting itself?

Secondly is this true of all events in VB.net and do I have to protect
myself when I am in any event?

TIA


Nov 21 '05 #3
Jay,

I read your response with great interest because I am working on an app
which will need a timer. What you are talking about, i.e. the re-entry of
the timer handler, requires two threads, right? I don't mean that the
programmer has asked for more than one thread, but that, somehow, under the
covers, Windows is using more than one thread. And if that's the case don't
you have to do something to make the setting of your beingHandled flag
atomic? Otherwise both threads could fetch and examine the beingHandled
flag before either thread sets it. How do you do the equivalent of a
critical section in .Net?

Thanks, Bob
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:OM******** *****@TK2MSFTNG P10.phx.gbl...
Jack,
My unstanding of all VB up to and including vb6 is that an event could not "interrupt" itself. Any Windows Event can "interrupt" itself by calling DoEvents since VB1.

In both VB.NET & VB6 MsgBox & MessageBox.Show calls the equivalent of
"DoEvents", I suspect to ensure the underlying form is properly displayed
(the Paint event is handled).

When you call DoEvents or its equivalent any event can occur a second

time, except I believe Paint and one other.
Firstly, are these two assumptions right No
and if so what is the approved way of stopping the event interrupting
itself?

If I call DoEvents while processing an Event, I normally set a flag in the
event that says it is already being handled.

Something like:

Private Sub Timer1_Tick(ByV al sender As System.Object, ByVal e As
System.EventArg s) Handles Timer1.Tick
Static beingHandled As Boolean
If beingHandled Then Exit Sub
beingHandled = True
' do work here
beingHandled = False
End Sub
Secondly is this true of all events in VB.net and do I have to protect
myself when I am in any event?

You only have to protect yourself in any event that DoEvents is explicitly
or implicitly called.

FWIW there are events that are not Windows Events, these events are not
handled via the DoEvents keyword. Windows Forms applications have a

message pump (Application.Ru n) that causes Windows Messages in the Windows Message
Queue to be converted into Events, each event is handled inturn, unless you call DoEvents with causes the next message in the message queue to be
converted into its respective Event. Hence if you call DoEvents explicitly
or implicitly an event can be raised a second time. This can be a source of problems if DoEvents is called with in Timer Tick, ToolBar ButtonClick,
Button Click and MenuItem Click events.

Hope this helps
Jay
"Jack Russell" <ja***@norubbis h.tpg.com.au> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
My unstanding of all VB up to and including vb6 is that an event could not "interrupt" itself.

For instance if you had a timer event containing a msgbox then you would
only get one message.

However in vb.net you get continual messages (even setting the system
modal property).

Firstly, are these two assumptions right and if so what is the approved
way of stopping the event interrupting itself?

Secondly is this true of all events in VB.net and do I have to protect
myself when I am in any event?

TIA


Nov 21 '05 #4
Bob,
What you are talking about, i.e. the re-entry of
the timer handler, requires two threads, right? No, there is only a single thread. The DoEvents itself (the one inside of
MsgBox in Jack's case) is causing a recursive call. Only one thread is
allowed to read the windows message queue, the thread that created the
window, so two threads do not come into play in this context.

Seeing as DoEvents & MsgBox are under full control of the developer, there
is no need to make beingHandled atomic.

In fact only the thread that creates windows controls are allowed to modify
those controls, so if you are creating multiple threads in your app, you
need to be certain to use Control.Invoke or Control.BeginIn voke &
Control.IsInvok eRequired as needed so as only the thread that created the
controls call methods on the control. (Of course other threads need to call
& are allowed to call Control.Invoke, Control.BeginIn voke, Control.EndInvo ke
& Control.IsInvok eRequired :-))

That aside.
How do you do the equivalent of a
critical section in .Net? I normally use SyncLock, which is implemented in terms of
System.Threadin g.Monitor. SyncLock is easier, while Monitor provides more
control. I normally create a new Object (literally New Object) that is the
padlock used with SyncLock, something like:

Private m_padlock New Object

Public Sub ThreadedRoutine ()
SyncLock m_padlock

' do work here

End SyncLock
End Sub

Alternatively I would consider making m_padlock static to ThreadedRoutine ,
normally however I need/want padlock to be class scope (not procedure
scope).

Hope this helps
Jay

"eBob.com" <eB******@total lybogus.com> wrote in message
news:%2******** *******@TK2MSFT NGP11.phx.gbl.. . Jay,

I read your response with great interest because I am working on an app
which will need a timer. What you are talking about, i.e. the re-entry of
the timer handler, requires two threads, right? I don't mean that the
programmer has asked for more than one thread, but that, somehow, under
the
covers, Windows is using more than one thread. And if that's the case
don't
you have to do something to make the setting of your beingHandled flag
atomic? Otherwise both threads could fetch and examine the beingHandled
flag before either thread sets it. How do you do the equivalent of a
critical section in .Net?

Thanks, Bob
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:OM******** *****@TK2MSFTNG P10.phx.gbl...
Jack,
> My unstanding of all VB up to and including vb6 is that an event could not > "interrupt" itself.

Any Windows Event can "interrupt" itself by calling DoEvents since VB1.

In both VB.NET & VB6 MsgBox & MessageBox.Show calls the equivalent of
"DoEvents", I suspect to ensure the underlying form is properly displayed
(the Paint event is handled).

When you call DoEvents or its equivalent any event can occur a second

time,
except I believe Paint and one other.
> Firstly, are these two assumptions right

No
> and if so what is the approved way of stopping the event interrupting
> itself?

If I call DoEvents while processing an Event, I normally set a flag in
the
event that says it is already being handled.

Something like:

Private Sub Timer1_Tick(ByV al sender As System.Object, ByVal e As
System.EventArg s) Handles Timer1.Tick
Static beingHandled As Boolean
If beingHandled Then Exit Sub
beingHandled = True
' do work here
beingHandled = False
End Sub
> Secondly is this true of all events in VB.net and do I have to protect
> myself when I am in any event?

You only have to protect yourself in any event that DoEvents is
explicitly
or implicitly called.

FWIW there are events that are not Windows Events, these events are not
handled via the DoEvents keyword. Windows Forms applications have a

message
pump (Application.Ru n) that causes Windows Messages in the Windows
Message
Queue to be converted into Events, each event is handled inturn, unless

you
call DoEvents with causes the next message in the message queue to be
converted into its respective Event. Hence if you call DoEvents
explicitly
or implicitly an event can be raised a second time. This can be a source

of
problems if DoEvents is called with in Timer Tick, ToolBar ButtonClick,
Button Click and MenuItem Click events.

Hope this helps
Jay
"Jack Russell" <ja***@norubbis h.tpg.com.au> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
> My unstanding of all VB up to and including vb6 is that an event could not > "interrupt" itself.
>
> For instance if you had a timer event containing a msgbox then you
> would
> only get one message.
>
> However in vb.net you get continual messages (even setting the system
> modal property).
>
> Firstly, are these two assumptions right and if so what is the approved
> way of stopping the event interrupting itself?
>
> Secondly is this true of all events in VB.net and do I have to protect
> myself when I am in any event?
>
> TIA



Nov 21 '05 #5
Hi,

.In addition to Jay's comments. You can use Synclock to prevent
multiple procedure from changing a variable at one time.

http://msdn.microsoft.com/library/de...tmSyncLock.asp

Ken
-----------------------
"Jack Russell" <ja***@norubbis h.tpg.com.au> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
My unstanding of all VB up to and including vb6 is that an event could
not "interrupt" itself.

For instance if you had a timer event containing a msgbox then you would
only get one message.

However in vb.net you get continual messages (even setting the system
modal property).

Firstly, are these two assumptions right and if so what is the approved
way of stopping the event interrupting itself?

Secondly is this true of all events in VB.net and do I have to protect
myself when I am in any event?

TIA
Nov 21 '05 #6
Wow! What an eye opener this thread has been, at least for this
novice VB.NETer. Thanks you Jay. The moral seems to be that you had
better know whether anything you call might call DoEvents. In fact
you had better know if anything you call might call anything which
might call DoEvents. ... etc. etc. etc. MessageBox.Show
documentation does not mention this "interestin g" aspect of its use.
Are there other calls I should beware of?

I am still having trouble grasping this. If I use MB in a timer tick
event handler I sure see the effect of the DoEvents call - MBs
overlaying MBs. BUT ... when I throw up a MB all of the controls on
my form are disabled until I click the OK. I.E. clicks on a Button
or a NumericUp/Down are ignored. Ignored - not just saved up and
processed after I click on the OK button. So if the timer tick events
are getting processed why are the Button events and NumericUp/Down
events not getting processed? (Or is this what you were addressing in
your original reply to Jack Russel when you pointed out that "there
are events that are not Windows Events ...". I didn't follow all of
that.)

And another thing which is confusing me (if I can explain it) ...
In my little experiment I used MB in a timer tick handler. The
interval was set to 1 second and I got the MBs faster than I could get
rid of them. But surely the first MB was displayed before the second
timer tick ticked. So if the MB code called DoEvents before it
displayed the MB, then the second tick hadn't tocked yet and DoEvents
would not have found an event to Do. If MB is calling DoEvents while
it is waiting for me click on OK ... well ... I don't understand how
it would do anything while it is waiting? Is MB polling to see if I
have clicked the OK button instead of waiting for me to click it?

I hope that these are not dumb questions but this strikes me as a very
important topic (not to mention really interesting).

Thanks, Bob

On Fri, 1 Oct 2004 07:46:09 -0500, "Jay B. Harlow [MVP - Outlook]"
<Ja************ @msn.com> wrote:
Bob,
What you are talking about, i.e. the re-entry of
the timer handler, requires two threads, right?

No, there is only a single thread. The DoEvents itself (the one inside of
MsgBox in Jack's case) is causing a recursive call. Only one thread is
allowed to read the windows message queue, the thread that created the
window, so two threads do not come into play in this context.

Seeing as DoEvents & MsgBox are under full control of the developer, there
is no need to make beingHandled atomic.

In fact only the thread that creates windows controls are allowed to modify
those controls, so if you are creating multiple threads in your app, you
need to be certain to use Control.Invoke or Control.BeginIn voke &
Control.IsInvo keRequired as needed so as only the thread that created the
controls call methods on the control. (Of course other threads need to call
& are allowed to call Control.Invoke, Control.BeginIn voke, Control.EndInvo ke
& Control.IsInvok eRequired :-))

That aside.
How do you do the equivalent of a
critical section in .Net?

I normally use SyncLock, which is implemented in terms of
System.Threadi ng.Monitor. SyncLock is easier, while Monitor provides more
control. I normally create a new Object (literally New Object) that is the
padlock used with SyncLock, something like:

Private m_padlock New Object

Public Sub ThreadedRoutine ()
SyncLock m_padlock

' do work here

End SyncLock
End Sub

Alternativel y I would consider making m_padlock static to ThreadedRoutine ,
normally however I need/want padlock to be class scope (not procedure
scope).

Hope this helps
Jay

"eBob.com" <eB******@total lybogus.com> wrote in message
news:%2******* ********@TK2MSF TNGP11.phx.gbl. ..
Jay,

I read your response with great interest because I am working on an app
which will need a timer. What you are talking about, i.e. the re-entry of
the timer handler, requires two threads, right? I don't mean that the
programmer has asked for more than one thread, but that, somehow, under
the
covers, Windows is using more than one thread. And if that's the case
don't
you have to do something to make the setting of your beingHandled flag
atomic? Otherwise both threads could fetch and examine the beingHandled
flag before either thread sets it. How do you do the equivalent of a
critical section in .Net?

Thanks, Bob
"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:OM******** *****@TK2MSFTNG P10.phx.gbl...
Jack,
> My unstanding of all VB up to and including vb6 is that an event could

not
> "interrupt" itself.
Any Windows Event can "interrupt" itself by calling DoEvents since VB1.

In both VB.NET & VB6 MsgBox & MessageBox.Show calls the equivalent of
"DoEvents", I suspect to ensure the underlying form is properly displayed
(the Paint event is handled).

When you call DoEvents or its equivalent any event can occur a second

time,
except I believe Paint and one other.

> Firstly, are these two assumptions right
No

> and if so what is the approved way of stopping the event interrupting
> itself?
If I call DoEvents while processing an Event, I normally set a flag in
the
event that says it is already being handled.

Something like:

Private Sub Timer1_Tick(ByV al sender As System.Object, ByVal e As
System.EventArg s) Handles Timer1.Tick
Static beingHandled As Boolean
If beingHandled Then Exit Sub
beingHandled = True
' do work here
beingHandled = False
End Sub

> Secondly is this true of all events in VB.net and do I have to protect
> myself when I am in any event?
You only have to protect yourself in any event that DoEvents is
explicitly
or implicitly called.

FWIW there are events that are not Windows Events, these events are not
handled via the DoEvents keyword. Windows Forms applications have a

message
pump (Application.Ru n) that causes Windows Messages in the Windows
Message
Queue to be converted into Events, each event is handled inturn, unless

you
call DoEvents with causes the next message in the message queue to be
converted into its respective Event. Hence if you call DoEvents
explicitly
or implicitly an event can be raised a second time. This can be a source

of
problems if DoEvents is called with in Timer Tick, ToolBar ButtonClick,
Button Click and MenuItem Click events.

Hope this helps
Jay
"Jack Russell" <ja***@norubbis h.tpg.com.au> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
> My unstanding of all VB up to and including vb6 is that an event could

not
> "interrupt" itself.
>
> For instance if you had a timer event containing a msgbox then you
> would
> only get one message.
>
> However in vb.net you get continual messages (even setting the system
> modal property).
>
> Firstly, are these two assumptions right and if so what is the approved
> way of stopping the event interrupting itself?
>
> Secondly is this true of all events in VB.net and do I have to protect
> myself when I am in any event?
>
> TIA



Nov 21 '05 #7
Jay B. Harlow [MVP - Outlook] wrote:
Jack,
My unstanding of all VB up to and including vb6 is that an event could not
"interrupt" itself.


Any Windows Event can "interrupt" itself by calling DoEvents since VB1.

In both VB.NET & VB6 MsgBox & MessageBox.Show calls the equivalent of
"DoEvents", I suspect to ensure the underlying form is properly displayed
(the Paint event is handled).

When you call DoEvents or its equivalent any event can occur a second time,
except I believe Paint and one other.

Firstly, are these two assumptions right


No

and if so what is the approved way of stopping the event interrupting
itself?


If I call DoEvents while processing an Event, I normally set a flag in the
event that says it is already being handled.

Something like:

Private Sub Timer1_Tick(ByV al sender As System.Object, ByVal e As
System.EventArg s) Handles Timer1.Tick
Static beingHandled As Boolean
If beingHandled Then Exit Sub
beingHandled = True
' do work here
beingHandled = False
End Sub

Secondly is this true of all events in VB.net and do I have to protect
myself when I am in any event?


You only have to protect yourself in any event that DoEvents is explicitly
or implicitly called.

FWIW there are events that are not Windows Events, these events are not
handled via the DoEvents keyword. Windows Forms applications have a message
pump (Application.Ru n) that causes Windows Messages in the Windows Message
Queue to be converted into Events, each event is handled inturn, unless you
call DoEvents with causes the next message in the message queue to be
converted into its respective Event. Hence if you call DoEvents explicitly
or implicitly an event can be raised a second time. This can be a source of
problems if DoEvents is called with in Timer Tick, ToolBar ButtonClick,
Button Click and MenuItem Click events.

Hope this helps
Jay
"Jack Russell" <ja***@norubbis h.tpg.com.au> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
My unstanding of all VB up to and including vb6 is that an event could not
"interrupt" itself.

For instance if you had a timer event containing a msgbox then you would
only get one message.

However in vb.net you get continual messages (even setting the system
modal property).

Firstly, are these two assumptions right and if so what is the approved
way of stopping the event interrupting itself?

Secondly is this true of all events in VB.net and do I have to protect
myself when I am in any event?

TIA


Thanks for the replies. You say VB6 is the same but I just tried it and
there is no second occurance, so either msgbox is different or the timer
event is different.

That piece of academia apart, how do I kow what other things contain a
hidden "do events"? Or do I protect all events. I was consdering with
the timer just disabling it at the start and re-enabling at the end.
As an old asembler programmer I can see dangers in the busy flag or
disabling as neither of these are accomplished in a single machine
instruction but I guess they will work assuming that an event cannot
interrupt itself except in the case of a "do events".
I will investigate synclock.

Nov 21 '05 #8
Jack,
Thanks for the replies. You say VB6 is the same but I just tried it and
there is no second occurance, so either msgbox is different or the timer
event is different. You are correct, VB6 appears to only allow the Paint event to continue to be
handled, it appears to block the Timer event. Without the Paint event being
handled your form will not redraw itself properly...
That piece of academia apart, Again, you are correct, VB6 behavior is largely academia...
how do I kow what other things contain a hidden "do events"? Or do I
protect all events. How paranoid are you? seriously?

If you are super paranoid about it, I would suggest you protect all events.

Me I only protect those routines that I know I am calling DoEvents
(explicitly) in, I rarely call DoEvents, ergo its not an issue. I do not
explicitly call MessageBox.Show from a Timer, so the fact that
MessageBox.Show allows a timer event to fire a second time is largely moot
for me. I may explicitly call MessageBox.Show within a "command" click event
(ToolBarButton Click, Button Click or MenuItem Click), seeing as
MessageBox.Show is modal, the user will not be able to click the same
ToolBar ButtonClick, Button Click or MenuItem Click event a second time, so
protecting any "command" click is moot also. Other events I would handle on
a case by case basis.

I have yet to actually come across a Windows Forms event that I
inadvertently entered a second time, hence I rarely need to protect the
event.

Note, using Synclock to protect an event wont work, as the current Thread
owns the Synclock, so when you attempt to lock the same object, you will
simply gain access to it.

Try the following, without clicking OK on the message box, you should see
multiple Timer1_Tick message boxes show up...

Private WithEvents Timer1 As System.Windows. Forms.Timer
'
'Timer1
'
Me.Timer1.Enabl ed = True
Me.Timer1.Inter val = 4000

Private ReadOnly m_padlock As New Object

Private Sub Timer1_Tick(ByV al sender As System.Object, ByVal e As
System.EventArg s) Handles Timer1.Tick
SyncLock m_padlock
MessageBox.Show ("Timer1_Tic k")
End SyncLock
End Sub

Note: I stated "I do not explicitly call MessageBox.Show from a Timer"
above, I may implicitly call MessageBox.Show , as my Global Exception
Handlers may call MessageBox.Show to display exceptions to the user, if the
Timer event happens to have an unhandled exception, then in this case I
could implicitly call MessageBox.Show . Seeing as this is an Exceptional case
(no pun intended) I'm not sure how concerned I would be with "protecting "
the Timer event from reentrancy.

Hope this helps
Jay
"Jack Russell" <ja***@norubbis h.tpg.com.au> wrote in message
news:%2******** *******@TK2MSFT NGP15.phx.gbl.. . Jay B. Harlow [MVP - Outlook] wrote:
Jack,
My unstanding of all VB up to and including vb6 is that an event could
not "interrupt" itself.


Any Windows Event can "interrupt" itself by calling DoEvents since VB1.

In both VB.NET & VB6 MsgBox & MessageBox.Show calls the equivalent of
"DoEvents", I suspect to ensure the underlying form is properly displayed
(the Paint event is handled).

When you call DoEvents or its equivalent any event can occur a second
time, except I believe Paint and one other.

Firstly, are these two assumptions right


No

and if so what is the approved way of stopping the event interrupting
itself?


If I call DoEvents while processing an Event, I normally set a flag in
the event that says it is already being handled.

Something like:

Private Sub Timer1_Tick(ByV al sender As System.Object, ByVal e As
System.EventArg s) Handles Timer1.Tick
Static beingHandled As Boolean
If beingHandled Then Exit Sub
beingHandled = True
' do work here
beingHandled = False
End Sub

Secondly is this true of all events in VB.net and do I have to protect
myself when I am in any event?


You only have to protect yourself in any event that DoEvents is
explicitly or implicitly called.

FWIW there are events that are not Windows Events, these events are not
handled via the DoEvents keyword. Windows Forms applications have a
message pump (Application.Ru n) that causes Windows Messages in the
Windows Message Queue to be converted into Events, each event is handled
inturn, unless you call DoEvents with causes the next message in the
message queue to be converted into its respective Event. Hence if you
call DoEvents explicitly or implicitly an event can be raised a second
time. This can be a source of problems if DoEvents is called with in
Timer Tick, ToolBar ButtonClick, Button Click and MenuItem Click events.

Hope this helps
Jay
"Jack Russell" <ja***@norubbis h.tpg.com.au> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
My unstanding of all VB up to and including vb6 is that an event could
not "interrupt" itself.

For instance if you had a timer event containing a msgbox then you would
only get one message.

However in vb.net you get continual messages (even setting the system
modal property).

Firstly, are these two assumptions right and if so what is the approved
way of stopping the event interrupting itself?

Secondly is this true of all events in VB.net and do I have to protect
myself when I am in any event?

TIA


Thanks for the replies. You say VB6 is the same but I just tried it and
there is no second occurance, so either msgbox is different or the timer
event is different.

That piece of academia apart, how do I kow what other things contain a
hidden "do events"? Or do I protect all events. I was consdering with the
timer just disabling it at the start and re-enabling at the end.
As an old asembler programmer I can see dangers in the busy flag or
disabling as neither of these are accomplished in a single machine
instruction but I guess they will work assuming that an event cannot
interrupt itself except in the case of a "do events".
I will investigate synclock.

Nov 21 '05 #9
Bob,
See my response to Jack.

Message boxes are Modal, which means that your form is "disabled" (won't
accept keyboard or mouse input) until the message box is closed. (actually
its closer to your form losses focus and the message box captures it until
closed). Ergo you Button, NumericUpDown will not receive any keyboard or
mouse input (the message box is receiving all this input & ignores it).
I really have to ask: Are developers seriously writing applications where
you are calling MessageBox.Show in the Timer.Click event? Is that a real
requirement in your apps? Why?
I can see having a Timer that fires once a second to check a database or web
resource, if the resource is not available and I needed to display a message
box, I would disable the Timer, then let the user know the problem, asking
the user if they wanted me to keep trying or not. More then likely I would
change something in the system tray or status bar of my app, which the user
could then click to see what the problem was.

Hope this helps
Jay
"eBob.com" <eB******@total lyfakeisp.com> wrote in message
news:pm******** *************** *********@4ax.c om...
Wow! What an eye opener this thread has been, at least for this
novice VB.NETer. Thanks you Jay. The moral seems to be that you had
better know whether anything you call might call DoEvents. In fact
you had better know if anything you call might call anything which
might call DoEvents. ... etc. etc. etc. MessageBox.Show
documentation does not mention this "interestin g" aspect of its use.
Are there other calls I should beware of?

I am still having trouble grasping this. If I use MB in a timer tick
event handler I sure see the effect of the DoEvents call - MBs
overlaying MBs. BUT ... when I throw up a MB all of the controls on
my form are disabled until I click the OK. I.E. clicks on a Button
or a NumericUp/Down are ignored. Ignored - not just saved up and
processed after I click on the OK button. So if the timer tick events
are getting processed why are the Button events and NumericUp/Down
events not getting processed? (Or is this what you were addressing in
your original reply to Jack Russel when you pointed out that "there
are events that are not Windows Events ...". I didn't follow all of
that.)

And another thing which is confusing me (if I can explain it) ...
In my little experiment I used MB in a timer tick handler. The
interval was set to 1 second and I got the MBs faster than I could get
rid of them. But surely the first MB was displayed before the second
timer tick ticked. So if the MB code called DoEvents before it
displayed the MB, then the second tick hadn't tocked yet and DoEvents
would not have found an event to Do. If MB is calling DoEvents while
it is waiting for me click on OK ... well ... I don't understand how
it would do anything while it is waiting? Is MB polling to see if I
have clicked the OK button instead of waiting for me to click it?

I hope that these are not dumb questions but this strikes me as a very
important topic (not to mention really interesting).

Thanks, Bob

<<snip>>
Nov 21 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

7
49562
by: Pavils Jurjans | last post by:
Hallo, I have been programming for restricted environments where Internet Explorer is a standard, so I haven't stumbled upon this problem until now, when I need to write a DOM-compatible code. The question is about best practices for passing parameters to an event function. I have, say, the following HTML:
1
20685
by: Covad | last post by:
Hi all, For some reason my change() function is only called when the page loads. I'd much rather it gets called when the select changes. Here's the code: window.onload = init; function init() {
4
12552
by: Eric | last post by:
How can I dynamically assign an event to an element? I have tried : (myelement is a text input) document.getElementById('myelement').onKeyUp = "myfnc(param1,param2,param3)"; document.getElementById('myelement') = new Function("myfnc(param1,param2,param3)");
18
2865
by: Christopher W. Douglas | last post by:
I am writing a VB.NET application in Visual Studio 2003. I have written a method that handles several events, such as closing a form and changing the visible status of a form. I have some code that applies to all these events, but I need to have specific code execute when the form closes. The properties for this method are sender (the...
8
6079
by: Mark | last post by:
Hi, I'm looking for some ideas on how to build a very simple Event processing framework in my C++ app. Here is a quick background ... I'm building a multithreaded app in C++ (on Linux) that uses message queues to pass pointers to Events between threads. In my app there are simple events that can be defined using an enum (for example an...
4
1737
by: hillcountry74 | last post by:
Hi, I'm a newbie and trying to understand event handling in c#. I have understood handling events using delelgate objects. But not this method- "Event handling by overriding the virtual protected method of the base class". Can someone please explain this with a sample code? Thanks a lot.
3
2066
by: Ashok Kumar K | last post by:
Hi all, Where can I get some insight on using the __hook, __unhook, event_source and event_receiver for specifically COM events. The documentation given in MSDN is very minimal. I have the following scenario Server (COM event source) is written in VC++ 6.0 using ATL (event interfaces can be either dispinterface / IDispatch based) Client...
2
2123
by: Paul E. Orman | last post by:
I have a piece of VB code (.NET 1.1 - VB 2003) that loads data from a database through a timer. So the timer is setup and from it I call the procedure that loads the latest records from the database. This works fine. However, I attempt to notify the user when data accesses occur. The way I attempt to accomplish this is by changing the...
4
9672
by: mflll | last post by:
I am looking into the different techniques of handling arrays of edit boxes in Java Script. The first program below works fine. However, are there better ways of doing this, where the person writing the JavaScript doesn't have to pass the index in the "onChange" event name. I thought that one might be able to use "this.value" or...
0
7658
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
0
7876
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
0
8101
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
1
7630
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
7941
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
0
5201
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3612
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
1194
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
0
909
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.