Event handling in VC++ 2005 .NET

[Ben]

Hi

I'm trying to setup a project that uses events. I'm creating a windows
forms based application.

The application interfaces to a DLL that controls a piece of external
hardware, whenever an action occurs on the hardware it needs to signal
my application.

The DLL instructions tell me to use CreateEvent to make the event, I
then pass the event handle to the DLL. This side of things seems to
work correctly and comes back with no errors.

What I'm having trouble with is how to tell the application to execute
this event. The event needs to read the hardware and then return to
the main program.

I could use a timer and continually poll the hardware but as the
hardware could signal at any time there is the danger I wouldn't be
able to pick up the messages quickly enough.

When an action is required the DLL uses SetEvent to signal the app.

My event creation code is:
(this is performed inside a button control on Form1)
HANDLE hGlobalLDVEvent;
hGlobalLDVEvent=CreateEventW(NULL,FALSE,FALSE,TEXT ("LDVEVENT"));
hGlobalLDVEvent=OpenEventW(EVENT_ALL_ACCESS,FALSE, TEXT("LDVEVENT"));

this returns with 0x268 which I believe this indicated the event is
properly
created?

What do I need to do now?

Thanks for your help

Ben

[Jeroen Mostert]

Ben wrote:

I'm trying to setup a project that uses events. I'm creating a windows
forms based application.

The application interfaces to a DLL that controls a piece of external
hardware, whenever an action occurs on the hardware it needs to signal
my application.

The DLL instructions tell me to use CreateEvent to make the event, I
then pass the event handle to the DLL. This side of things seems to
work correctly and comes back with no errors.

What I'm having trouble with is how to tell the application to execute
this event. The event needs to read the hardware and then return to
the main program.

You're confusing "event" with "event handler". An event is a Win32 object
that can be signaled to indicate something has happened or should happen. An
event handler is a higher-level concept (not present in the Win32 API
itself) for "function that executes in response to an event".

What you want to do is wait for the event to become signaled. You can use
WaitForSingleObject() or any of the related Wait...() functions for this. If
your application is a managed application, you can also use the
ManualResetEvent and AutoResetEvent classes, and
ThreadPool.RegisterWaitForSingleObject() to register a wait without tying up
a thread.

I could use a timer and continually poll the hardware but as the
hardware could signal at any time there is the danger I wouldn't be
able to pick up the messages quickly enough.

Don't use polling, it's evil. You'll peg the processor without doing
anything meaningful.

When an action is required the DLL uses SetEvent to signal the app.

This will set the event to the signaled state and release any threads
waiting on the event.

My event creation code is:
(this is performed inside a button control on Form1)
HANDLE hGlobalLDVEvent;
hGlobalLDVEvent=CreateEventW(NULL,FALSE,FALSE,TEXT ("LDVEVENT"));
hGlobalLDVEvent=OpenEventW(EVENT_ALL_ACCESS,FALSE, TEXT("LDVEVENT"));

this returns with 0x268 which I believe this indicated the event is
properly
created?

This is the value of the event handle; it it failed, it would have returned
NULL. Don't forget to check for this.

--
J.

[Ben]

On Jul 11, 12:46*pm, Jeroen Mostert <[e-mail]:

Ben wrote:

I'm trying to setup a project that uses events. I'm creating a windows
forms based application.

The application interfaces to a DLL that controls a piece of external
hardware, whenever an action occurs on the hardware it needs to signal
my application.

The DLL instructions tell me to use CreateEvent to make the event, I
then pass the event handle to the DLL. This side of things seems to
work correctly and comes back with no errors.

What I'm having trouble with is how to tell the application to execute
this event. The event needs to read the hardware and then return to
the main program.

You're confusing "event" with "event handler". An event is a Win32 object
that can be signaled to indicate something has happened or should happen.An
* event handler is a higher-level concept (not present in the Win32 API
itself) for "function that executes in response to an event".

What you want to do is wait for the event to become signaled. You can use
WaitForSingleObject() or any of the related Wait...() functions for this.If
your application is a managed application, you can also use the
ManualResetEvent and AutoResetEvent classes, and
ThreadPool.RegisterWaitForSingleObject() to register a wait without tyingup
a thread.

I could use a timer and continually poll the hardware but as the
hardware could signal at any time there is the danger I wouldn't be
able to pick up the messages quickly enough.

Don't use polling, it's evil. You'll peg the processor without doing
anything meaningful.

When an action is required the DLL uses SetEvent to signal the app.

This will set the event to the signaled state and release any threads
waiting on the event.

My event creation code is:
(this is performed inside a button control on Form1)
HANDLE hGlobalLDVEvent;
hGlobalLDVEvent=CreateEventW(NULL,FALSE,FALSE,TEXT ("LDVEVENT"));
hGlobalLDVEvent=OpenEventW(EVENT_ALL_ACCESS,FALSE, TEXT("LDVEVENT"));

this returns with 0x268 which I believe this indicated the event is
properly
created?

This is the value of the event handle; it it failed, it would have returned
NULL. Don't forget to check for this.

--
J.- Hide quoted text -

- Show quoted text -

Thanks for your reply.

I put a WaitForSingleObject() function in the routine and this worked;
it stopped the execution of the program until the hardware sent a
signal, but it tied up the rest of the application.
What I would like to know is:
Can I set up another thread that will wait for the signal(from the
hardware) read the hardware and then return to waiting for the next
signal?
Whilst it is doing that I need the main application window to still
allow me update control,etc.
What commands should I use?

Thanks your help, this is my first attempt at multithreaded apps. I'm
more used to embedded systems and using interrupts to jump to specific
routines.

Ben

[SvenC]

Hi Ben,

I put a WaitForSingleObject() function in the routine and this worked;
it stopped the execution of the program until the hardware sent a
signal, but it tied up the rest of the application.
What I would like to know is:
Can I set up another thread that will wait for the signal(from the
hardware) read the hardware and then return to waiting for the next
signal?

Yes, that is the correct approach.

Whilst it is doing that I need the main application window to still
allow me update control,etc.
What commands should I use?

Use PostMessage to post update information to your main window.
Do not use HWNDs of your main thread directly in your background
thread. HWNDs can only be accessed by the thread which created it.

How these message look like depends on your app design.
They might be as simple as invalidating your main window to force
redraws which takes new data updated by your background thread.
Or you might post control specific messages to update some control
state or you might invent your own messages to send some custom
data structure to your main window which has to be processed in the
window proc of the receiving window.

--
SvenC

[Ben]

On Jul 11, 1:39*pm, "SvenC" <[e-mail]:

Hi Ben,

I put a WaitForSingleObject() function in the routine and this worked;
it stopped the execution of the program until the hardware sent a
signal, but it tied up the rest of the application.
What I would like to know is:
Can I set up another thread that will wait for the signal(from the
hardware) read the hardware and then return to waiting for the next
signal?

Yes, that is the correct approach.

Whilst it is doing that I need the main application window to still
allow me update control,etc.
What commands should I use?

Use PostMessage to post update information to your main window.
Do not use HWNDs of your main thread directly in your background
thread. HWNDs can only be accessed by the thread which created it.

How these message look like depends on your app design.
They might be as simple as invalidating your main window to force
redraws which takes new data updated by your background thread.
Or you might post control specific messages to update some control
state or you might invent your own messages to send some custom
data structure to your main window which has to be processed in the
window proc of the receiving window.

--
SvenC

Ok,

I tried to use the CreateThread Function
hThread = CreateThread(NULL, 0,
(LPTHREAD_START_ROUTINE)TFunction(),NULL,CREATE_SU SPENDED ,
&IDThread);

In my form_load routine, but don't seem to have it right. It
immediatly executes TFunction but the program doesn't continue to
execute the rest of my code. Am I correct in thinking that each thread
should run concurrently? or am I missing something?

I was hoping to have something along the lines of
DWORD TFunction()
{
unsigned int x;
while (TRUE)
{
x=WaitForSingleObject(hGlobalLDVEvent,INFINITE) ;
ldv_return=NiRead(buff);
resetstate(hGlobaleLDVEvent);

}
return 0;
}

Ben

[SvenC]

Hi Ben,

I tried to use the CreateThread Function
hThread = CreateThread(NULL, 0,
(LPTHREAD_START_ROUTINE)TFunction(),NULL,CREATE_SU SPENDED ,
&IDThread);

Only specify TFunction without parenthesis. That hands in the address of
that function
and does not execute it.

In my form_load routine, but don't seem to have it right. It
immediatly executes TFunction but the program doesn't continue to
execute the rest of my code. Am I correct in thinking that each thread
should run concurrently? or am I missing something?

I was hoping to have something along the lines of
DWORD TFunction()

Use DWORD WINAPI TFunction(LPVOID p)

p will contain what you gave a 4th param to CreateThread.

When you use the CRT you might need to use _beginthreadex to initialize per
thread CRT state correctly.

--
SvenC

[Ben Voigt [C++ MVP]]

SvenC wrote:

Hi Ben,

>I tried to use the CreateThread Function
hThread = CreateThread(NULL, 0,
(LPTHREAD_START_ROUTINE)TFunction(),NULL,CREATE_S USPENDED ,
&IDThread);

Only specify TFunction without parenthesis. That hands in the address
of that function
and does not execute it.

And remove the (LPTHREAD_START_ROUTINE) cast. If you defined the function
right, no cast is needed. The address-of (&) operator is optional but
recommended. Only specify CREATE_SUSPENDED if you intend to change thread
properties, like priority, before it starts to run. i.e.:

hThread = CreateThread(NULL, 0, &ThreadProc, NULL, 0, &IDThread);

>

>In my form_load routine, but don't seem to have it right. It
immediatly executes TFunction but the program doesn't continue to
execute the rest of my code. Am I correct in thinking that each
thread should run concurrently? or am I missing something?

I was hoping to have something along the lines of
DWORD TFunction()

Use DWORD WINAPI TFunction(LPVOID p)

p will contain what you gave a 4th param to CreateThread.

When you use the CRT you might need to use _beginthreadex to
initialize per thread CRT state correctly.

[Ben Voigt [C++ MVP]]

My event creation code is:
(this is performed inside a button control on Form1)
HANDLE hGlobalLDVEvent;
hGlobalLDVEvent=CreateEventW(NULL,FALSE,FALSE,TEXT ("LDVEVENT"));
hGlobalLDVEvent=OpenEventW(EVENT_ALL_ACCESS,FALSE, TEXT("LDVEVENT"));

After CreateEvent, you do not also need to do OpenEvent. OpenEvent is
designed for using an event created by name in a different program. You
also don't need to name your event, because you and the DLL are sharing it
using the handle, not the name.