tags:

views:

40

answers:

2

Hi all!!

We are developing C++ application for Windows, using Borland Code Gear 2007.

The main app has only one thread (this is a strong restriction). From this thread:

1) A Form is created (VCL from Borland).

2) Messages are received from both:

a. Messages from the window: messages including Windows mouse events, etc.  (Form).

b. Our own pre-defined messages

3) The form is used in a Real Time application (including a camera), so this thread receives both users defined and window messages.

4) The thread must process ALL messages, so we cannot discard (filter) any of them.

The problem is:

Right now, when user clicks the mouse (on the FORM) and keep it pressed, the Application locks. Events from the mouse have a high priority than our own messages, so the thread keeps processing mouse events (until the user releases the mouse). In the meanwhile, the other type of Messages are not processed because of the flooding of messages from the mouse, so the camera locks.

Any idea on how to resolve this problem?

Our main restriction is dealing with message priorities in one single thread: it seems that Windows messages always arrive with the higher priority.

Below you can find some code illustrating our approach:

================================================================ 

FThread(LPVOID owner) {

  ...
  ...

  form->CreateViewController(  );

  if( form)   
 form->Show();

  while( 
  (new_event = MsgWaitForMultipleObjects( size, events, false,  INFINITE, QS_ALLINPUT )) 
         != (WAIT_OBJECT_0 + 1 )) {

 new_event = new_event - WAIT_OBJECT_0;

 if(new_event >= 2 && new_event!= size)

    ResetEvent( events[new_event]);

    if ( new_event < size) {

    try{
     form->processMyMessages(new_event);
     }
     catch ( Exception &ex) { }

    }

    if (new_event == size ) {

    MSG msg;

    while( PeekMessage( &msg, 0, 0, 0, true)) {

    TranslateMessage( &msg);
    DispatchMessage ( &msg);

   }

    }

 }

    ...
    ...

 return 0;
}
+1  A: 

I don't think there's any scheduling done on messages, it's probably just that while the mouse doing something, it'll be causnig your code to handle it's actions. Since you've only got a single thread, it'll lock up your camera as you've suggested.

You might be able to do something to yield control temporarily to allow other messages to process.

Relying on the windows message pump as a way of updating the display is probably not the best solution in this case. Personally I'd suggest running the camera code in a background thread so that your GUI remains responsive without tying up your data-capture process.

[Edit] It looks to me (from your indenting) that there ought to be a '{' between the following lines:

if(new_event >= 2 && new_event!= size)
    ResetEvent( events[new_event]);
Jon Cage
A: 

The code you've posted appears to be correct. I don't spot any problem in this code. Furthermore, I've got no idea which mouse message you're getting.

Also, you have a fundamental design problem. Your so-called "Real-Time Application" MUST use multiple threads. There's no realistic alternative: Windows priority is a thread property, not a message property.

MSalters