How to Manage Threads

Top  Previous  Next

This topic will show you how to limit an MDI Child browse procedure to a single instance using messaging.

The simplest solution is to disable the menu item when the browse procedure is active. You can't do this in the menu itself--you must send a message to the Frame procedure from the browse.

First you need to declare two new events in the Global Properties, Global Data embed point:

 

EVENT:DisableCustomerItem     EQUATE(401h)

EVENT:EnableCustomerItem      EQUATE(402h)

 

(Note that user-defined events must start after 400h.)

You also need a global variable, define this in Global Properties, Data. Call this GLO:MainThreadNo, make it a BYTE.

In the Frame procedure, WindowManager Executable Code--Init embed, type the following:

 GLO:MainThreadNo = THREAD()

(Whenever an MDI procedure is STARTed, a thread number is allocated to it. We need the thread number in order to post a message to the frame procedure.)

Now, still in the frame procedure, you need to write code in the WindowManager Executable Code--TakeWindowEvent [Priority: 2800] embed to handle the two user-defined events that the frame procedure will receive.

 OF EVENT:DisableCustomerItem

  DISABLE(?ShowCust)

 OF EVENT:EnableCustomerItem

  ENABLE(?ShowCust)

In the Browse procedure, in the WindowManager Executable Code--Init [Priority:5600] embed, type:

 POST(EVENT:DisableCustomerItem,,GLO:MainThreadNo)

In the WindowManager Executable Code--Kill [Priority:8000] embed, type:

 POST(EVENT:EnableCustomerItem,,GLO:MainThreadNo)

Now, the first time you select the Browse Procedure from your menu, ShowCust starts up, the POST() statement executes and an EVENT:DisableCustomerItem is sent to the Frame procedure.

If the user then clicks on the menu again, the message is processed and the item is disabled.

As the user exits ShowCust, the EVENT:EnableCustomerItem message is sent to the Frame. When that message is processed the menu item is enabled again.

Why store the Frame's thread number - surely it would always be number 1? Well it might NOT be the first thread in the application.

(Thanks to Rob Mousley of Chariot Software for submitting this topic.)