SUGGESTION: Enhanced event support

Postby guy on Wed Jun 27, 2001 9:44 am

This looks complicated, but is actually very simple (implementation may not be...).


1. PocketC now has the facility to callback from the shell into user functions (see atexit())

2. The basic windows controls are subclassed by the shell.

3. Most real windows event handling has to be performed from within the window procedure before it returns to windows, not at a later point.

I suggest:

1. A new function is added to the runtime:

pfOldEventFunction = setevent(iGuiId, iWindowsMessage, pfEventFunction) ;

iGuiId is a PocketC control or timer ID
iWindowsMessage is a real Windows message number
pfEventFunction is a pointer to a PocketC function, or NULL (0).

The return, pfOldFunction is either a pointer to a previous event function, or is NULL (0) if none.

The shell function adds a handler for a particular windows message for a particular control onto a list of handlers, returning the address of the previous handler if there was one. If the handler is already there then it replaces the handler. If the function pointer is null it removes the handler. The return of the previous handler function allows the user to build a chain of message functions (atexit should really do this as well).

2. In the window proc for the subclassed controls, BEFORE processing the message, call a function to check for a handler for that message on the control (need to translate window handle first), if there is a handler, call it through the same mechanism as the atexit function. Use the return value in the same way that windows does, to control whether PocketC carries on processing (and if PocketC doesn't handle the message pass it to the def win proc).

3. Provide a generalised window proc for the common controls, and subclass them as well. The generalised proc just needs to call the check for a handler code, then pass message to def win proc if appropriate based on return value.

If practical, the user callback function should be called as follows:

int MyEvent(int iGuiId, pointer pwMsg) ;

Where pwMsg is in the same format as in the eventmsg() function (this contains the real windows message number and the real window handle. Returns TRUE or FALSE.

The result of all this would be that user code could process windows messages in the correct context. The mechanism seems to be very simple given the code that exists in the shell already.


Does the PocketC threading model make this more difficult than it seems?

PocketC CE API interface:
PCForm and CE API forum:
Posts: 879
Joined: Thu Dec 07, 2000 8:58 am
Location: United Kingdom

Return to PocketC for CE Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest