Application.DoE vents in a module?

[Amjad]

Hi,

Is there an equivalent to the "Application.Do events" 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.Do events" 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.doe vents or not. Windows application can pass it in
as true, and it will get called, all other applications will pass in false.

"Amjad" <Am***@discussi ons.microsoft.c om> wrote in message
news:61******** *************** ***********@mic rosoft.com...

Hi,

Is there an equivalent to the "Application.Do events" 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.Do events" and I
can't
use this because the DLL module is not an application.

Is there a workaround?

[Amjad]

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.Doe vents 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.Doe vents), but I don't know how to do it in a module form.

"Marina" wrote:

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.doe vents or not. Windows application can pass it in
as true, and it will get called, all other applications will pass in false.

"Amjad" <Am***@discussi ons.microsoft.c om> wrote in message
news:61******** *************** ***********@mic rosoft.com...

Hi,

Is there an equivalent to the "Application.Do events" 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.Do events" and I
can't
use this because the DLL module is not an application.

Is there a workaround?

[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.Doe vents.

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.

"Amjad" <Am***@discussi ons.microsoft.c om> wrote in message
news:FD******** *************** ***********@mic rosoft.com...

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.Doe vents 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.Doe vents), but I don't know how to do it in a module form.

"Marina" wrote:

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.doe vents or not. Windows application can pass it
in
as true, and it will get called, all other applications will pass in
false.

"Amjad" <Am***@discussi ons.microsoft.c om> wrote in message
news:61******** *************** ***********@mic rosoft.com...

> Hi,
>
> Is there an equivalent to the "Application.Do events" 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.Do events" and I
> can't
> use this because the DLL module is not an application.
>
> Is there a workaround?

[Cor Ligthert [MVP]]

Amjad,

In addition to the others.

On what event it will than have to react?

Cor

[Amjad]

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.Do events" 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]" wrote:

Amjad,

In addition to the others.

On what event it will than have to react?

Cor

[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]

"Amjad" <Am***@discussi ons.microsoft.c om> schrieb

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.Do events" 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.ru n(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 (WindowsApplica tion!)
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_DeviceAttache d As Boolean = False

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

Public Function IsDeviceAttache d() As Boolean

Dim TimeOut As Integer = 300 ' timeout of 3 seconds

m_Port.Send(... )

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

TimeOut -= 1
Loop

Return m_DeviceAttache d

End Function

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

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

m_DeviceAttache d = 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
"Amjad" <Am***@discussi ons.microsoft.c om> wrote in message
news:6C******** *************** ***********@mic rosoft.com...

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.Do events" 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]" wrote:

Amjad,

In addition to the others.

On what event it will than have to react?

Cor

[Armin Zingler]

"Charles Law" <bl***@nowhere. com> schrieb

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