Enter Key in Edit Control

[msmith]

The customer has to do an "INTERCEPTON" for each edit control and then write an event handler for each one.

[zooba]

So presumably there's some code that the customer doesn't write which calls their interception code. Can't you have another window procedure for the edit control which passes Enter key presses to the customer's code?

[msmith]

zooba

The procedure the customer does right now is:

1) create control
     This does a CreateWindowEx and fills in the descriptor with key things like Handle, control type, ID, status, etc. and nulls all of the event dispatch addresses. It also saves   the default WindowProc.

2) Does an INTERCEPTON for that control (if it desired to intercept events intended for the control). This overwrites the Proc in the Handle using a SetWindowLong

3) Writes an intercept event of the form:
     ControlName.INTERCEPT
     UserCode (In this case checks wmsg to see if is a WM_CHAR and if it is, checks wparam for a ENTER code. If it is, the proper button event is called))
     PASSEVENT (if the user wants to allow normal processing of the event, otherwise this is omitted causing a 0 to be returned)
     END EVENT

For the normal case of doing an event:

1) Create control (ExitButton for example)

2) Write event
     ExitButton.COMMAND
     END
     END EVENT

The compiler automatically stores the ExitButton.COMMAND dispatch address in the descriptor and the event handler automatically checks the entry in the descriptor for a 0, in which case not event is called. Otherwise it calls the address stored in the descriptor in the Command Dispatch entry.

I hope this answers your question, and thanks again for all the help.

[zooba]

Yes, it does answer my question.  :wink

I've been so interested because it appears very similar to my current project, a runtime library for MASM to hide a lot of the API details in macros and procedures  :bg