Posting an event

[Jeff Casbeer]

New to VB..

What is the VB syntax for posting a Windows event? For example, to have an event fire AFTER a form loads, I'd add a posted call to a "post_load" event, from "load". What is the VB syntax for that deferred call? Raiseevent seems to be synchronous, as does just calling the handler subroutine. Also, how do I defer processing to allow windows to process incomplete events, eg., painting

Thanks - Jeff

[Trev Hunter]

Jeff,

If you want to do asynchronous processing, look up the following topics in
the help files and in MSDN

Threading
Thread Pool
Asynchronous delegates

The following links may also be of use:

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

http://msdn.microsoft.com/msdnmag/is...t/default.aspx

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

Be careful with threads and windows forms - always remember the golden
rule - you shouldn't call a method on a form from a different thread - use
Form.Invoke to call it instead.

If you want your application to process windows messages before executing a
piece of code, call System.Windows.Forms.Application.DoEvents(). DoEvents
processes waiting messages before continuing. InVB6 it was used to allow
your window to stay responsive while preforming background processing. In
VB.net, the addition of threading has become the preferred method for
background processing, but DoEvents is still available.
Below is a quick example of how to call a method asynchronously:

-------------------------

' Delegate to call async
Private Delegate Sub DoStuffDelegate(Byval MyParam as String)
' Main Entry point
Private Sub Main()

' Local Variables
Dim DoStuffAsync as new DoStuffDelegate(AddressOf Me.DoStuff)
Dim objResult as IAsyncResult

' Start the async processing
objResult = DoStuffAsync.BeginInvoke("test", nothing, nothing)

' Do some stuff in this thread
Threading.Thread.Sleep(5000)

' Pause until the processing has finished
DoStuffAsync.EndInvoke(objResult)

End Sub
' Method that runs on a different thread
Private Sub DoStuff(Byval Param as String)

' Do stuff on a different thread
Threading.Thread.Sleep(10000)

End Sub

-------------------------
Hope this helps,

Trev.
"Jeff Casbeer" <je*********@hsi.com> wrote in message
news:5B**********************************@microsof t.com...

New to VB...

What is the VB syntax for posting a Windows event? For example, to have an event fire AFTER a form loads, I'd add a posted call to a "post_load"
event, from "load". What is the VB syntax for that deferred call?
Raiseevent seems to be synchronous, as does just calling the handler
subroutine. Also, how do I defer processing to allow windows to process
incomplete events, eg., painting?
Thanks - Jeff

[Jeff Casbeer]

Thanks Trev for your quick reply!

I'm just trying to make a distinction between the Windows API options to POST vs. SEND a Windows event. I'd really rather avoid trying to start a new thread. I want the work to occur on this thread, just AFTER the application returns to the Windows message handler and after Windows processes anything else that entered the message queue before my POST. So, for example, if I put a "MsgBox" in my form's load event, the message box displays, then when I press OK the form displays. But what if I want the message box to display immediately after my form displays

Is this not a valid technique with VB

Thanks - Jeff

[Trev Hunter]

> But what if I want the message box to display immediately after my form
displays?

You could use the Activate event instead of the load event although you
would have to distinguish between the first time it is shown and times when
it is simply activated.

A better method would be to do the processing after you call Form.Show
(maybe with a call to DoEvents). E.g.

-------------------

Dim obJForm as new MyForm

objForm.Show
Application.DoEvents()
Messagebox.Show(........)

-------------------
If you could provide an explanation of what you're trying to accomplish, I
may be of more help. Also, try posting in the
microsoft.dotnet.framework.windowsforms group as this may be more
appropiate.

HTH,

Trev.
"Jeff Casbeer" <je*********@hsi.com> wrote in message
news:00**********************************@microsof t.com...

Thanks Trev for your quick reply!

I'm just trying to make a distinction between the Windows API options to POST vs. SEND a Windows event. I'd really rather avoid trying to start a
new thread. I want the work to occur on this thread, just AFTER the
application returns to the Windows message handler and after Windows
processes anything else that entered the message queue before my POST. So,
for example, if I put a "MsgBox" in my form's load event, the message box
displays, then when I press OK the form displays. But what if I want the
message box to display immediately after my form displays?
Is this not a valid technique with VB?

Thanks - Jeff

[Jeff Casbeer]

Thanks again for responding Trev. My background is with Powerbuilder, but I've done this in other languages as well. We load the window before beginning the slower process of retrieving data, or the non-visual processes of creating business objects, etc. In other words, anything that isn't related to the user interface directly gets deferred until the form has completed drawing. We do this with a custom windows event. We set up a custom event on the form and then "post" the event. Posting the event tells Windows to stick the event at the bottom of the message queue rather than the top. (Raiseevent seems to use window's "send" functionality, which runs the event *right now*.) The effect is that the form displays first, faster, before all other processing occurs, resulting in better perceived performance

VB coders don't use this sort of technique

Thanks - Jeff

[Dominique Vandensteen]

is a more common way to do that not

1. show splash screen
2. do "business" stuff
3. load "real" form
?
....

but for your idea you can maybe create a thread in formLoad event?
Dominique
"Jeff Casbeer" <je*********@hsi.com> wrote in message
news:68**********************************@microsof t.com...

Thanks again for responding Trev. My background is with Powerbuilder, but I've done this in other languages as well. We load the window before
beginning the slower process of retrieving data, or the non-visual processes
of creating business objects, etc. In other words, anything that isn't
related to the user interface directly gets deferred until the form has
completed drawing. We do this with a custom windows event. We set up a
custom event on the form and then "post" the event. Posting the event tells
Windows to stick the event at the bottom of the message queue rather than
the top. (Raiseevent seems to use window's "send" functionality, which runs
the event *right now*.) The effect is that the form displays first, faster,
before all other processing occurs, resulting in better perceived
performance.
VB coders don't use this sort of technique?

Thanks - Jeff

[Trev Hunter]

Jeff,

There are many ways to accomplish this with a form in VB including
threading, asynchronous delegates and DoEvents() (note that these techniques
should apply to all dotnet languages, not just VB). The difference is that
windows forms in dotnet add a layer to insulate the developer from having to
deal with the low-down windows events (although you can still get at them
with the WndProc method or API calls).

Events in .NET have nothing to do with the windows message queue events,
instead their implementation is based on multicast delegates (synchronous
ones) and are a managed part of the dotnet framework. Because these
delegates are synchronous, there is no messsage queue for them and you can't
post a message to the bottom of the queue.

If you want your form to be shown fully before populating the loading of the
data, then try the following:

-------------------------------

Protected Overrides Sub OnLoad(ByVal e As System.EventArgs)
' Call the Base Method
MyBase.OnLoad(e)

' Allow the window to process all its waiting windows messages
Application.DoEvents()

' Do stuff to load the data

End Sub

--------------------------------

Note that with the above example, your form should paint OK with the call to
DoEvents, but it will still not respond to user messages while loading the
data (unless you call doevents while loading the data, or use a thread to
load the data).

If you are loading a lot of data, then I would suggest using a thread.
They're not that hard to do in .net as long as you are careful when calling
a method on the form or one of its controls.
Hope this helps,

Trev.

"Jeff Casbeer" <je*********@hsi.com> wrote in message
news:68**********************************@microsof t.com...

Thanks again for responding Trev. My background is with Powerbuilder, but I've done this in other languages as well. We load the window before
beginning the slower process of retrieving data, or the non-visual processes
of creating business objects, etc. In other words, anything that isn't
related to the user interface directly gets deferred until the form has
completed drawing. We do this with a custom windows event. We set up a
custom event on the form and then "post" the event. Posting the event tells
Windows to stick the event at the bottom of the message queue rather than
the top. (Raiseevent seems to use window's "send" functionality, which runs
the event *right now*.) The effect is that the form displays first, faster,
before all other processing occurs, resulting in better perceived
performance.
VB coders don't use this sort of technique?

Thanks - Jeff

[Jeff Casbeer]

Thanks to Dominique and Trev for the response. From what I can see from reading about calling the API and Control.WndProc and the related stuff, fooling with the Windows API isn't invited by .NET. *UNMANAGED* is a word that kept showing up, and the help information doesn't make it sound pretty

I'm going to work on using a new thread next, and see if that takes me where I want to go... (oh no, cover your eyes...) today

Thanks again guys - Jeff