Application.DoEvents in a module?

[Guest]

Hi,

Is there an equivalent to the "Application.Doevents" method in modules or
Windows services?

I want to make a Windows service that calls a DLL. The DLL would have all my
functions and it would be doing all the job, but some of the functions that
I'm using require calling something like "Application.Doevents" and I can't
use this because the DLL module is not an application.

Is there a workaround?

 

[Marina]

A windows service doesn't have user events like a windows form would - so
what could it process?

Perhaps you can pass a flag into your function to let it know whether it
should call application.doevents or not. Windows application can pass it in
as true, and it will get called, all other applications will pass in false.

 

[Guest]

Marina,

I didn't mention "user events". My DLL module raises other events. All my
functions are in the DLL module, so I cannot run Application.Doevents in any
of my functions.

I want to process all Windows messages currently in the message queue from
within my DLL module. I know how to do it in a WindowsForm (using
Application.Doevents), but I don't know how to do it in a module form.

 

[Stephany Young]

The point is that you are calling the methods in the dll from a windows
service therfore there is no window and, ergo, there is no window message
queue, so there is no pint in calling Application.Doevents.

If you are looking to relinquish the remainder of the time slice for the
current thread so that other threads can 'get a look in' then you need to
have a look at Thread.Sleep.

 

[Cor Ligthert [MVP]]

Amjad,

In addition to the others.

On what event it will than have to react?

Cor

 

[Guest]

I want to communicate with an RS232 COM port, so I transmit a command to the
port and listen for replies in a threaded infinite loop. In my WindowsForm
application I used the "Application.Doevents" after sending the command in
the loop. I also used it in another function after calling a Dial-up
"Connect" method.

It seemed to me that the "Doevents" method was important to force Microsoft
Windows (and not necessarily the WindowsForm) to process any messages
generated by my application now.

I'm concluding from your replies that a DLL module cannot generate Windows
Messages.

 

[Cor Ligthert [MVP]]

Amjad,

Not my part of sport however have a look at Dick Griers his pages.

http://www.hardandsoftware.net/

I hope this helps,

Cor

 

[Armin Zingler]

I want to communicate with an RS232 COM port, so I transmit a
command to the port and listen for replies in a threaded infinite
loop. In my WindowsForm application I used the
"Application.Doevents" after sending the command in the loop. I also
used it in another function after calling a Dial-up "Connect"
method.

It seemed to me that the "Doevents" method was important to force
Microsoft Windows (and not necessarily the WindowsForm) to process
any messages generated by my application now.

I'm concluding from your replies that a DLL module cannot generate
Windows Messages.

It doesn't matter if the code is an a module or in a (not-module) class.
Whether you can use DoEvents or not - like the others have already said -
depends on the fact whether the code is running in a UI (user interface)
thread. A UI thread is a thread that has a message queue. A thread gets a
message queue if you create a window (AKA Control, Form) in the thread. The
message loop is there to process all the messages and it runs all the time
to wait for the messages. In .Net, the message loop is contained in
Application.Run. If you write your own sub main, you have to call
Application.Run to keep the thread/app alife. If you specify a Form as the
startup object, VB.Net internally creates a sub main that only contains
"application.run(new Startupform)".

'DoEvents' is a kind of 'workaround' if you are running in a loop where the
thread's main task is doing a job while still being able to process the
messges in the message queue. DoEvents also processes theses messages.
Usually, the job that I mentioned should then be pushed to a different
thread so that the main thread, which is the UI thread, can keep on
processing messages while the other thread is doing it's job without the
need for DoEvents.

In a service, there is no UI. Thus, you don't have a message loop. Long
story short: The question is whether you would need a message loop to get
the events from your COM port. If possible, do the following:

1. make a test application (WindowsApplication!)
2. Write an event handler for the event that you need to handle
3. set a breakpoint in the event handler
4. run
5. Post the full callstack here

Depending on the component you are using, it might be possible that it does
*not* depend on windows messages because some components offer a callback
mechanism instead. If this is there, use it. Otherwise, and if a message
loop is not allowed in a service (I am not a service expert), you can not
use the component in the service.


Armin

 

[Charles Law]

Hi Amjad

What method/component are you using to communicate with the coms port? Have
you written it yourself or is a third-party (or MS in VS2005) component?

If it is a third-party component then I would imagine there would be an
event raised when data is received. If you have written it yourself then you
probably want to emulate this behaviour.

My guess is that you send data on the DLL's main thread, and data is
received on a worker thread. Therefore, having sent the data, you want to
sit and wait for a response, like this

<snip>
Public Class MyDLL
Private WithEvents m_Port as RS232
Private m_DeviceAttached As Boolean = False

Public Sub New(ByVal portNumber as Integer)
m_Port = New RS232(portNumber)
End Sub

Public Function IsDeviceAttached() As Boolean

Dim TimeOut As Integer = 300 ' timeout of 3 seconds

m_Port.Send(...)

Do While Not m_DeviceAttached And TimeOut > 0
' DoEvents not available here
Thread.Sleep(10)

TimeOut -= 1
Loop

Return m_DeviceAttached

End Function

Private Sub DataReceived(ByVal sender As Object, ByVal e As
ComEventArgs) _
Handles m_Port.DataReceived

' Look at data to decide whether device is attached and return
result
' ...

m_DeviceAttached = True

End Sub

End Class
</snip>

Of course, DoEvents is not available to you, as you have discovered, so use
Sleep() instead.

This is a quick-and-dirty way of doing it. Personally, I use a Monitor and
block the main thread until data is received or a timeout occurs, but the
logic is basically the same.

HTH

Charles

 

[Armin Zingler]

Of course, DoEvents is not available to you, as you have discovered,
so use Sleep() instead.

If the event of the component he is using is solely based on windows
messages - wrapped in an event - Sleep is no replacment and does not help
here.


Armin

 

[Charles Law]

I suppose I am second-guessing how the comms component works, but I agree.

Better to use the Monitor technique then, for a more general solution.

Charles

 

[Guest]

Thanks for the replies.

Let's look at this 3rd-party activeX component that dials a phone number
using the computer's modem (AxRasDialerCtrl) in a WindowsForm.

I captured two call stacks below. The first one is just after I called the
"Connect" method and before calling the "Application.DoEvenets" and the
second Call Stack is captured when the "Connect" event is raised (after
"Application.DoEvents" was called).

Do you think I can use this component in a Windows service?

'First Call Stack:

projectDialer.exe!projectDialer.formMain.cmdAction_Click(Object eventSender = {System.Windows.Forms.Button}, System.EventArgs eventArgs = {System.EventArgs}) Line 396 Basic

system.windows.forms.dll!System.Windows.Forms.Control.OnClick + 0x5e bytes
system.windows.forms.dll!System.Windows.Forms.Button.OnClick + 0x53 bytes
system.windows.forms.dll!System.Windows.Forms.Button.OnMouseUp + 0x133
bytes
system.windows.forms.dll!System.Windows.Forms.Control.WmMouseUp + 0x261
bytes
system.windows.forms.dll!System.Windows.Forms.Control.WndProc + 0x49b bytes
system.windows.forms.dll!System.Windows.Forms.ButtonBase.WndProc + 0x121
bytes
system.windows.forms.dll!System.Windows.Forms.Button.WndProc + 0x85 bytes

system.windows.forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage + 0x13 bytes

system.windows.forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc + 0xda bytes

system.windows.forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback + 0x3d bytes

system.windows.forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods+IMsoComponentManager.FPushMessageLoop
+ 0x349 bytes

system.windows.forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner + 0x1f3 bytes

system.windows.forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop + 0x50 bytes
system.windows.forms.dll!System.Windows.Forms.Application.Run + 0x34 bytes
projectDialer.exe!projectDialer.formMain.Main() Line 3 + 0x1d bytes Basic


'Second Call Stack:

projectDialer.exe!projectDialer.formMain.rasDialer_ConnectEvent(Object eventSender = {AxRasDialerCtrl.AxDialer}, System.EventArgs eventArgs = {System.EventArgs}) Line 510 Basic

axinterop.rasdialerctrl.dll!AxRasDialerCtrl.AxDialer.RaiseOnConnectEvent +
0x2a bytes

axinterop.rasdialerctrl.dll!AxRasDialerCtrl.AxDialerEventMulticaster.Connect
+ 0x3d bytes

system.windows.forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods+IMsoComponentManager.FPushMessageLoop
+ 0x1c0 bytes

system.windows.forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner + 0x1f3 bytes

system.windows.forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop + 0x50 bytes
system.windows.forms.dll!System.Windows.Forms.Application.Run + 0x34 bytes
projectDialer.exe!projectDialer.formMain.Main() Line 3 + 0x1d bytes Basic

 

[Armin Zingler]

Thanks for the replies.

Let's look at this 3rd-party activeX component that dials a phone
number using the computer's modem (AxRasDialerCtrl) in a
WindowsForm.

I captured two call stacks below. The first one is just after I
called the "Connect" method and before calling the
"Application.DoEvenets" and the second Call Stack is captured when
the "Connect" event is raised (afer "Application.DoEvents" was
called).

Do you think I can use this component in a Windows service?

I don't think so.

'Second Call Stack:

projectDialer.exe!projectDialer.formMain.rasDialer_ConnectEvent(Object
eventSender = {AxRasDialerCtrl.AxDialer}, System.EventArgs
eventArgs = {System.EventArgs}) Line 510 Basic

[...]

system.windows.forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop
+ 0x50 bytes
system.windows.forms.dll!System.Windows.Forms.Application.Run +
0x34 bytes
projectDialer.exe!projectDialer.formMain.Main() Line 3 + 0x1d bytes
Basic

The event is captured during the message loop, thus you'll have to look at
the documentation of the control to see if it supports a different callback
mechanism as I mentioned in the previous post.


Armin

 

[Jay B. Harlow [MVP - Outlook]]

Amjad
In addition to the other comments.

It sounds like you have a DLL that is calling Application.DoEvents (which is
rarely a good idea, as Armin suggests) and you don't want to call it
sometimes because your DLL is being called from a Windows Service which
doesn't allow Application.DoEvents. Correct?

Irregardless of whether you should or should not be calling
Application.DoEvents in a Windows app. I would consider using the
app.config/web.config file to control whether "Application.DoEvents" is
called or not. I would consider defining an Interface with a method. In the
Windows Forms application the Windows Forms friendly class that implemented
the interface would call Application.DoEvents, in the Windows Service
application the Windows Service friendly class that implemented the
interface would do Windows Service appropriate things. In a ASP.NET app, the
ASP.NET friendly class that implemented the interface would do ASP.NET
appropriate things... In a Console application...

The four specific classes (Windows Forms, ASP.NET, Windows Service, Console)
along with the interface could be your class library, while the
app.config/web.config would indicate the correct class to use for the type
of application. Alternatively the interface could be in your class library,
while the implementation classes would be in the respective application.

Using an Interface allows you to isolate other behavior that changes based
on the type of app you are creating.

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| Hi,
|
| Is there an equivalent to the "Application.Doevents" method in modules or
| Windows services?
|
| I want to make a Windows service that calls a DLL. The DLL would have all
my
| functions and it would be doing all the job, but some of the functions
that
| I'm using require calling something like "Application.Doevents" and I
can't
| use this because the DLL module is not an application.
|
| Is there a workaround?