📄 wpw_wapi_message_95.html
字号:
<HTML>
<HR><A NAME=WINAPI_OWNMESSAGE>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Creating my own messages.</H4><PRE>
In article <DA8p14.AAv@emr1.emr.ca>, John Grant <jagrant@emr1.emr.ca> wrote:
> Use WM_USER+n n=0,1,2,3,...
Are any problems caused by the fact that WM_USER through WM_USER+~30 are
used by Windows in various control classes? I can't think of any offhand,
since it looks like all the WM_USER+n messages used by Windows are ones that
are sent by the application to the controls, rather than the other way
around, but just to be safe, I start my messages at WM_USER+100. Am I being
overly paranoid?
--Tim Smith
> I need to how I go about creating my own messages so that in an
> application I can have two windows communicate via these new messages.
I use "virtual" control buttons to do this.
When you click (e.g.) a button in a dialog, it posts a message to its
parent. The parent gets a WM_COMMAND message with the control's
indentifier in the Word Parameter and the notification code & control
handle in the Long Parameter.
One of my current applications needs to send inter-window messages
such as you describe.
I do this in window #1:
PostMessage(hw2,WM_COMMAND,ID_MYCOMMAND1,0UL);
The ID_MYCOMMAND1 is a number not used by any of your resource IDs
(typically over 2000 for me). The last paramter seems to work
well as 0UL but you might like to put a dummy notification code and/or
the source window in there if you like.
Do you have the window handle hw2 ? Is it the parent of window #1 ?
Can you find it with FindWindow() ?
In the receiving window, my WM_COMMAND response has:
void WMCommand(RTMessage Msg)
{
switch(Msg.WParam)
{
case ID_MYCOMMAND1:
....
.........
break;
}
}
You could use define your own WM_yyy constants of course but the above
method works more neatly for me.
Richard [in HR8]
<HR>
In article <DA8p14.AAv@emr1.emr.ca>, jagrant@emr1.emr.ca (John Grant) wrote:
>In article <3rq0op$6iu@ocean.CAM.ORG> s_weisz@CAM.ORG (Steven Weisz) writes:
>>I need to how I go about creating my own messages so that in an
>>application I can have two windows communicate via these new messages.
>>That is to say as an example I want window number one to send window
>>number 2 a message telling it to start doing something. Now I knwo I can
>>use the SendMessage function (I`m using the OWL libraries for Borland3.1)
>>but I`m not sure about one thing and that is the second parameter of the
>>function.
>>
>>SendMessage(HWindow, WM_MYMESSAGE, wParam, lParam)
>>
>>can I define WM_MYMESSAGE to be any UINT or do I have a specific range I
>>can use....
>>
>>thanks in advance...
>>
>>Steve
>
> Use WM_USER+n n=0,1,2,3,...
Also see RegisterWindowMessage.
Dave
--------------------
Is my project done? Define done...
dcon@iwwpd.att.com
David.Connet@att.com
<HR>
In article <3rq0op$6iu@ocean.CAM.ORG> s_weisz@CAM.ORG "Steven Weisz" writes:
> I need to how I go about creating my own messages so that in an
> application I can have two windows communicate via these new messages.
> That is to say as an example I want window number one to send window
> number 2 a message telling it to start doing something. Now I knwo I can
> use the SendMessage function (I`m using the OWL libraries for Borland3.1)
> but I`m not sure about one thing and that is the second parameter of the
> function.
>
> SendMessage(HWindow, WM_MYMESSAGE, wParam, lParam)
>
> can I define WM_MYMESSAGE to be any UINT or do I have a specific range I
> can use....
It must be WM_USER+n with n>=0 and less than some documented value.
(OWL may place extra constraints, which I would know nothing about,
but that is tha API constraint).
Dave
--
+---------------------------+-----------------------------------+
| Dave Webber dave@musical.demon.co.uk |
| Author of MOZART, the Windows 3.1 shareware Music Processor |
| and member of the Association of Shareware Professionals |
+---------------------------+-----------------------------------+
<HR>
In article <3rrk1v$mdh@nntp5.u.washington.edu> tzs@u.washington.edu (Tim Smith) writes:
>In article <DA8p14.AAv@emr1.emr.ca>, John Grant <jagrant@emr1.emr.ca> wrote:
>> Use WM_USER+n n=0,1,2,3,...
>
>Are any problems caused by the fact that WM_USER through WM_USER+~30 are
>used by Windows in various control classes? I can't think of any offhand,
>since it looks like all the WM_USER+n messages used by Windows are ones that
>are sent by the application to the controls, rather than the other way
>around, but just to be safe, I start my messages at WM_USER+100. Am I being
>overly paranoid?
>
>--Tim Smith
You don't need to be that careful. As you say, the WM_USER+n
messages that you see in <windows.h> are sent to controls directly.
You won't receive any of them (i.e. LB_ADDSTRING) in your WndProc.
In your WndProc, you can use WM_USER+n (n=0,1,2,3...)
--
John A. Grant jagrant@emr1.emr.ca
Airborne Geophysics
Geological Survey of Canada, Ottawa
</PRE>
<HR><A NAME=WINAPI_SUBCLASS_MDI>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Subclass MDI Client</H4><PRE>
In article <3rvau6$qvi@ionews.io.org> grnlion@io.org writes:
>
> Hey there,
> I'm seeking some help in subclassing the MDI Client window.
> What I want to do is process some of the regular window messages that are sent
> to the Client window, such as WM_RBUTTONUP. I know it's possible to create my
> own WndProc for the Client window, and process all the MDI messages, but it's
> too much work. If you know of a easier way, please let me know.
>
> Thanks,
>
> Dave.
>
You don't have to process all the MDI messages as far as I know! I have never
used MDI Client windows as yet, but I'm sure they are much the same as main
windows, in which case all you do is process the messages you want and pass
any others to the default window message handler!
Regards:
Jonnathon :)
--
</PRE>
<HR><A NAME=WINAPI_MSG_WMPAINT>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: WM_PAINT Message</H4><PRE>
Ignoring what the manual says, what is the practical use of WM_PAINT?
It seems to be sent too often to be useful. What should I do with it?
Any suggestions welcome.
Thanks in anticipation,
(Andrew, Melbourne)
<HR>
In article <3s2ui6$123@harbinger.cc.monash.edu.au> <andrew@cobra.path.monash.edu.au> writes:
>Ignoring what the manual says, what is the practical use of WM_PAINT?
>It seems to be sent too often to be useful. What should I do with it?
>
>Any suggestions welcome.
>
>Thanks in anticipation,
>
>(Andrew, Melbourne)
It is very important. The bottom line is that you don't draw anything
until you are told to do so by Windows. Windows does that by sending
you a WM_PAINT message. You are expected to just sit there and twiddle
your thumbs until WM_PAINT arrives. At that point you [re-]draw
the indicated portion of your picture. If *you* want to initiate
a redraw, you use InvalidateRect() to trigger the WM_PAINT event.
If you can't wait for it (WM_PAINT has a low priority) and need to
update the window immediately, use UpdateWindow().
As I said, WM_PAINT is a low priority message. Windows processes
other messages from the queue first. When it gets around to looking
at WM_PAINT, it collects all of the WM_PAINT messages in the queue
and combines them into one WM_PAINT message with a single damaged
rectangle that needs to be re-painted.
Initially, you create your window with CreateWindow and then
do ShowWindow & UpdateWindow(). That triggers the first WM_PAINT
message for your window and forces it to paint itself the first time.
Subsequently, you will get a WM_PAINT message:
- when you resize your window
- when you close a dialog box (or move it around)
- when you uncover a portion of your window previously
covered by another application
- etc
You won't get a WM_PAINT when you close a drop-down menu, because
Windows implements a backing store for the menu items and re-paints
the area itself.
You must be prepared to paint *any* portion of your picture at *any*
time, because you can *never* predict when you will get a WM_PAINT
message.
This is a big difference from the traditional way of writing programs.
You must learn how to work in a message-based event-driven system
in order to write Windows programs.
If you don't understand this, I strongly recommend that you buy a
proper book on Windows programming. You can NOT learn Windows
programming by reading the manuals provided with your compiler.
I can highly recommend "Programming Windows 3.1" by Charles Petzold
(Microsoft Press). Most programmers consider this the classic book
on the subject and is essential reading.
--
John A. Grant jagrant@emr1.emr.ca
Airborne Geophysics
Geological Survey of Canada, Ottawa
<HR>
In article <3s2ui6$123@harbinger.cc.monash.edu.au>
andrew@cobra.path.monash.edu.au
"<andrew@cobra.path.monash.edu.au>
" writes:
>Ignoring what the manual says, what is the practical use of WM_PAINT?
>It seems to be sent too often to be useful. What should I do with it?
No disrespect, but you REALLY need to read an introductory Windows
programming book! Petzold's "Programming Windows 3.1" is the classic.
The fundamental difference between a Windows program and a DOS program is
the concept of a "message driven" architecture. In a DOS program, YOU decide
when to display your output. In a Windows program, you display your output
when Windows asks you to, and you have to be able to reproduce your output
window at any time. Windows sends your program a "WM_PAINT" message when
it wants you to redisplay all or part of your window display.
Chris
--
--------------------------------------------------------------------------
| Chris Marriott, Warrington, UK | Author of SkyMap v2 shareware |
| chris@chrism.demon.co.uk | astronomy program for Windows. |
| For more info, see http://www.winternet.com/~jasc/skymap.html |
| Author member of Association of Shareware Professionals (ASP) |
--------------------------------------------------------------------------
<HR>
In article <3s2ui6$123@harbinger.cc.monash.edu.au> <andrew@cobra.path.monash.edu.au> writes:
>Ignoring what the manual says, what is the practical use of WM_PAINT?
>It seems to be sent too often to be useful. What should I do with it?
John Grant gave you some of his usual excellent advice. Let me just add this:
Always respond to WM_PAINT.
Do all your drawing under WM_PAINT.
Draw your window completely under WM_PAINT (unless you wish to check the
PAINTSTRUCT.rcPaint field and draw only that rectangle).
Don't do any drawing at any other time.
If you want all or part of your window drawn at some other time, don't just go
drawing into it. Instead, use InvalidateRect() or InvalidateRgn() to specify
what should be redrawn. There is nothing more you need to do, because your
WM_PAINT code will do the drawing. If you want the drawing to happen
immediately, call UpdateWindow().
There are other techniques you can use, but they fall into the category of
advanced Windows programming. If you are at the point of asking "what is
WM_PAINT for?" (and there is nothing wrong with being at that place), it means
you're not yet ready for the advanced techniques--you should stick with doing
all your drawing under WM_PAINT.
WM_PAINT is your friend. <g>
-Mike
<HR>
Ignore it if the specified area is not critical, however the paint is sent
whenever the system deems it to be neccessary.
Richard Gagnon
Consulting/Contract Windows 3.1/NT Programmer
VC++, VB3.0, and now Delphi (whoopi Pascal again)
</PRE>
<HR><A NAME=WINAPI_MSG_CAPTURE_APP>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: How to capture other application's message?</H4><PRE>
In article <3ts4iv$nmm@aegis.altabates.com>,
Drew Perttula <drew_perttula@altabates.com> wrote:
>How can I catch messages from other applications in OWL or plain Win API.
>I've seen Winsight do it, but I can't figure out how it works.
>
>Anyone know?
You set a system hook. See the SetWindowsHookEx function. Jeffrey Richter
has a good discussion of using hooks in "Windows 3.1: A Developer's Guide."
Dave
--------------------
Is my project done? Define done...
dcon@iwwpd.att.com
David.Connet@att.com
</PRE>
</HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -