I posted this problem to the Ultramon forum and suggested that
Ultramon use a more unique message number and this is the response I
received from the Ultramon creator:
Might be an option, but I would only want to do this if this is a
common compatibility issue.
Most apps should have no problem with this because the message
loop simply forwards messages
to the appropriate window procedure, which does the processing. If
gvim would do this, it would never
see the WM_APP messages from UltraMon.
Does he mean that one should always call TranslateMessage/
DispatchMessage? And that, in this case, gvim should free the memory
in the procedure that handles the string message?
I am going to do a little more digging to see if I can figure out what
this means in regards to code but thought that I would post the
response for feedback.
Ray
>
> The patch looks good, though Ray's suggestion of RegisterWindowMessage
> might be safer.
>
> I'd argue, however, that the fault really lies with Ultramon. It's
> supposed to unobtrusively hook into other processes. The WM_APP range
> of messages has been documented as safe for applications to use for
> their own private needs since the early 90s.
> --
> /George V. Reilly
> [email protected]http://www.georgevreilly.com/blog http://blogs.cozi.com/tech-
> Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
