Bob,

A couple o' answers,

>In order to receive messages from a 3rd party .DLL I was trying to wedge
>a non-system message number into the default Swiftforth window message
>loop, and tried the method proferred on page 161 of the manual to add to
>the message handler as follows:
>
>[+SWITCH SFMESSAGES ... etc

Typo? Try SF-MESSAGES in the CONSOLE-WINDOW wordlist.

CONSOLE-WINDOW +ORDER
[+SWITCH SF-MESSAGES
   ...
SWITCH]

>And this leads me to my next question... Those WM_CREATE and other
>constants in the switch structures are values that can not be computed
>at run time right? That is to say, those values that are tested in the
>switch have to be put in the structure at compile time, it looks like.
>So, just what is the best way to reserve a message number for use in my
>apps without any danger of conflict. I thought maybe that the Windows
>RegisterWindowMessage function would offer hope, but the message number
>is captured at run time, and so it can't go into the switch, which is
>created at load time. Uh, does this make any sense? The question is, how
>can I really be sure I am using a unique message number if I make one up
>within the range of values above WM_USER?

The normal practice, if you are writing self-contained code, is to
simply use the messages above WM_USER as you like. Some external
windows classes like RICHEDIT (I think, not sure) do use some of the
messages in the range of WM_USER thru WM_USER + 100 so if you want to
be certain, start with WM_USER + 1000 .

As to the use of RegisterWindowMessage, its use is a bit difficult
given the run-time binding of the SF-MESSAGES switch. If you really
want to use it, you would have to replace either the default message
handler DEFWINPROC or the code in the callback SF-CALLBACK to examine
the actual message for your custom messages at runtime befire passing
it into the switch. Neither is trivial, but if you really need to
do it, I will try to help.

Rick
Received on Wed Jun 28 2000 - 05:59:18 PDT