wpw_wapi_lf_95.html

VC programing

In article <[e-mail]>
           [e-mail] "D.J. VAN ECK (9512257J" writes:

>I need to do something after my window has been restored from being 
>minimised, what is the message to trap ?

When a program is being "uniconized" it first of all gets a
"WM_QUERYOPEN" message. If it response "TRUE" to indicate that it's OK
to uniconize it, it gets opened and receives the usual WM_SIZE message.

Chris
-- 
--------------------------------------------------------------------------
| Chris Marriott, Warrington, UK      | Author of SkyMap v2 shareware    |
| [e-mail]            | astronomy program for Windows.   |
|      For more info, see http://www.winternet.com/~jasc/skymap.html     |
|      Author member of Association of Shareware Professionals (ASP)     |
--------------------------------------------------------------------------
 
</PRE>

<HR><A NAME=WINAPI_LF_WIN_RESIZE_MOVE>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br> 
<H4>Subject: How to disable a window's from resizing and moving?</H4><PRE>
Check the Windows style. Those WS_XXX, you know.
-- 
Hui Huang               I ain't afraid of no ghost.
[e-mail]  http://home.cc.umanitoba.ca/~umhuang4/
</PRE>


<HR><A NAME=WINAPI_LF_WIN_MAX>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br> 
<H4>Subject: How to maximize a window?</H4><PRE>
[e-mail] (Arnaud Ventura) wrote:
>
>
>       I would like to know how to have a window full screen from the 
>       beginning. I tryed with Attr but it can not really be as when the 
>       window is maximized.
>               
>       Anyone with ideas ...
>
>       Arnaud

Try ShowWindow(hwnd,SW_MAXIMIZED) to maximize the window.  If you
don't want it "maximized" but size to the full screen, just get
the desktop window coords with GetWindowRect(NULL,&rect) and size
your window with MoveWindow or SetWindowPlacement.


-----------------------------------------------------------
Daniel G. Hyams
email:  [e-mail]
WWW:    http://www.eng.clemson.edu/~dhyams/
phone:  [phone]
-----------------------------------------------------------
<HR>
David Brabant (SNI) ([e-mail]) wrote:
: >This is Im sure a stupid question but here goes, how can I make a window
: >full screen in other words no border or anything, also is there a way to do 
: >it in OWL?
: >Thanks in advance,
: >[e-mail]

:  Use GetSystemMetrics to get the screen dimensions, then create a window
:  using the retrieved dimensions, with no border and no caption.

You don't even need to do that much.  Just create a window with no border,
no caption (which means that the style must be WS_POPUP), and show it with
an SW_SHOWMAXIMIZED parameter. 
<HR>
In article <3u1h2p$[e-mail]> [e-mail]  writes:

>This is Im sure a stupid question but here goes, how can I make a window
>full screen in other words no border or anything, also is there a way to do 
>it in OWL?

You need to create a window with the "WS_POPUP" style, rather than the
default "WS_OVERLAPPED" style. An "overlapped" window ALWAYS has a caption
bar; a "popup" window only has a caption if you give it the "WS_CAPTION"
style.

Regards,

Chris
-- 
--------------------------------------------------------------------------
| Chris Marriott, Warrington, UK      | Author of SkyMap v2 shareware    |
| [e-mail]            | astronomy program for Windows.   |
|      For more info, see http://www.winternet.com/~jasc/skymap.html     |
|      Author member of Association of Shareware Professionals (ASP)     |
--------------------------------------------------------------------------
 
</PRE>

<HR><A NAME=WINAPI_LF_Force_repaint>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: How do I force a repaint?</H4><PRE>
[e-mail] (Terence Wilson) wrote:

<snip>

>If that doesn't make any sense, consider this problem: write an app that 
>displays the screen co-ordinates of other Windows apps in real-time. i.e. when 
>an app's window is moved your app immmediately updates the screen co-ords for 
>that app in its window.

I do believe I've seen various programs do this kind of thing and it's my
understanding it's all to do with the rather Deep Dark and Mysterious subject
of "Setting Hooks" (sounds kinda spooky, don't it?).  But I wouldn't know, 
not really.  Look up SetWindowsHook[Ex].

You might even find some little example apps in your "examples" directory, 
depending on what compiler you've got - look for things with names like "spy" 
or "snoop" or "inspector" or perhaps even "peeping tom".

cps

<HR>

In article [e-mail], [e-mail] (John Grant) writes:
>In article <3us76u$[e-mail]> [e-mail] (Terence Wilson) writes: 


>>I'm trying to write an app in C++ using MFC that
>>will manage desktop windows. Specifically, I need
>>my app window to be re-painted whenever the desktop
>>changes, i.e. a Window is moved, re-sized etc.
>>
>>I have tried putting lots of re-paint messages in
>>my apps queue
>
>
>	The correct answer is to simply call InvalidateRect(hwnd,NULL,TRUE);
>	when you want to have your window redrawn.  That will put a WM_PAINT
>	message into the queue

Hi John,

I have the same question as Terence; I was hacking with this last nite.

I have a menu item that causes redraws in a couple of child windows, through
the main window procedure, like this:

Menu item clicked -> main window proc -> confirmation -> update variable -> redraw child 1
                                                                         -> redraw child 2

The child windows being redrawn of course use the variable I'm updating in this
whole procedure.

The confirmation I've coded using a MessageBeep() call followed by a MessageBox()
call with flags OKCANCEL (I forget what it is exactly). Pretty standard stuff
(hey, I'm learning this all here.....).

BUT.  I was using SendMessage() and PostMessage() with the message WM_PAINT to get
the child windows to redraw.  As you know (being a seasoned veteran and all)
this did not work, and I was flabbergasted at this.  So I later tried
InvalidateRect() which you know did work, as you tell the above poster.

Before I tried the InvalidateRect() call, I hacked around by sending my child
windows user defined messages and determined that the main windows proc was
indeed working, and that the child windows procedures were also working.
This meant that Windows was for some reason hanging onto the WM_PAINT messages
for an indeterminately long amount of time, or just plain throwing them out.

Why is this ???  In Petzold's book, he says that there are 2 "special" messages
(WM_PAINT is one of them; I forget the other right now)
that Windows sends to procedures only if there is nothing else in the queue; that
is, they are low priority messages.  I knew this going in, but I thought "low" meant
"low", not "no", as in "no priority".  Can you shed some light on what is going
on ???? Are there any more messages I should know about that won't get to
their destinations ????

Oh, yes, I did think of using a user-defined message and having that drop through
to the WM_PAINT case item in the child windows procedures, but I didn't want to
do that if I could avoid it since it seems to me to be "cheating". I'd appreciate
your opinion on this also since you seem to be a knowledgeable and disciplined
programmer.


Stand on soapbox:
In the same train of thought,
I must say I agree with your view on amateur behaviour in naming functions and
variables.  Using "questionable" names can only hurt programmers and the industry
as customers and the public inevitably find out about this and are understandably
turned off by it.  It's hard to justify that one is a "professional" and should
be paid a high salary and treated with respect when one names ones functions
"MemoryDumpOhsh*tOhsh*tOhsh*t()" or similar dopey name.
Jump off soapbox:

Thanks,

W.

<HR>

In article <3v2tg9$[e-mail]> [e-mail] writes:
>In article [e-mail], [e-mail] (John Grant) writes:
>>In article <3us76u$[e-mail]> [e-mail] (Terence Wilson) writes: 
>
>
>>>I'm trying to write an app in C++ using MFC that
>>>will manage desktop windows. Specifically, I need
>>>my app window to be re-painted whenever the desktop
>>>changes, i.e. a Window is moved, re-sized etc.
>>>
>>>I have tried putting lots of re-paint messages in
>>>my apps queue
>>
>>
>>	The correct answer is to simply call InvalidateRect(hwnd,NULL,TRUE);
>>	when you want to have your window redrawn.  That will put a WM_PAINT
>>	message into the queue
>
>Hi John,
>
>I have the same question as Terence; I was hacking with this last nite.
>
	[...tried Send/Postmessage with WM_PAINT, found it didn't work,
	so tried InvalidateRect, which worked just fine...]
>
>Before I tried the InvalidateRect() call, I hacked around by sending my child
>windows user defined messages and determined that the main windows proc was
>indeed working, and that the child windows procedures were also working.
>This meant that Windows was for some reason hanging onto the WM_PAINT messages
>for an indeterminately long amount of time, or just plain throwing them out.
>
>Why is this ???  In Petzold's book, he says that there are 2 "special" messages
>(WM_PAINT is one of them; I forget the other right now)
>that Windows sends to procedures only if there is nothing else in the queue; that
>is, they are low priority messages.  I knew this going in, but I thought "low" meant
>"low", not "no", as in "no priority".  Can you shed some light on what is going
>on ???? Are there any more messages I should know about that won't get to
>their destinations ????
	WM_PAINT is a low-priority message.  It won't process it until the
	other higher-priority messages have been processed.  That's because
	most messages can be handled in the blink of an eye, but WM_PAINT
	generally takes much longer, since you have to draw the picture.
	The one thing that you *MUST* do in Windows to keep it running
	properly is to pump messages continually.  If you don't pump
	messages, your app will take over the system and shut out the others,
	so it's in the best interests of all apps for Windows to process
	the messages in the queue as fast as possible, so the queue doesn't
	fill up.  If it can handle 100 messages in 1 s before it finally
	gets to your WM_PAINT, then it will do so, otherwise there may
	be 100 messages in the queue waiting until you finish WM_PAINT.
	The other reason that WM_PAINT has a low priority is so that
	Windows can combine several WM_PAINT into a single WM_PAINT, which
	makes it more efficient.  When the queue has been emptied and only
	WM_PAINT remain, Windows looks at the invalid RECT for each one
	of them and combines them into a single WM_PAINT with an aggregate
	invalid RECT.  The fewer WM_PAINT messages you have to process,
	the faster Windows runs.

	If you want your window painted *now*, then you can bypass the queue,
	by doing InvalidateRect(), followed by UpdateWindow().  This calls
	your WndProc with a WM_PAINT message directly.  Note that you really
	should only do this if you need something drawn right away so you
	can draw another thing on top of it.  There are few situations when
	you require this.

>Oh, yes, I did think of using a user-defined message and having that drop through
>to the WM_PAINT case item in the child windows procedures, but I didn't want to
>do that if I could avoid it since it seems to me to be "cheating". I'd appreciate
>your opinion on this also since you seem to be a knowledgeable and disciplined
>programmer.
	Why would you want to do this?  The WM_PAINT handling procedure
	is well-defined and works very well, provided apps follow the
	rules.  You really must understand how the message queue works in
	Windows - read Chapter 1 in Petzold's book.  Messages should be
	processed in sequence.  UpdateWindow() provides a special mechanism
	to bypass the queue for the WM_PAINT message.

	[...other unrelated comments...]
-- 
John A. Grant						[e-mail]
Airborne Geophysics
Geological Survey of Canada, Ottawa

<HR>
In article [e-mail], [e-mail] (John Grant) writes:


>	WM_PAINT is a low-priority message.  It won't process it until the
>	other higher-priority messages have been processed.

I thought this was happening but also thought that it was possible Windows
was tossing the message out since the redraw never occurred.  I had my app
running, the shell of course, Borland 3.1 windows IDE and the resource
workshop, plus file mangler.  I waited for well over 10 seconds and the
redraw still never came.

>
>	If you want your window painted *now*, then you can bypass the queue,
>	by doing InvalidateRect(), followed by UpdateWindow().  This calls
>	your WndProc with a WM_PAINT message directly.  Note that you really
>	should only do this if you need something drawn right away so you
>	can draw another thing on top of it.  There are few situations when
>	you require this.

I'm entering information in a child window or from the menu and want the 
menu choice to be shown to the user in real time on 1, maybe 2 child
windows.  So I'm going to stick with what I've got now.  I'd hate it if
the user made a menu choice and had to resize a pair of windows to make the
action show itself - the implications of this are obvious.


>	Why would you want to do this?  The WM_PAINT handling procedure
>	is well-defined and works very well, provided apps follow the
>	rules.

I thought of doing it because it did what I wanted, though as you pointed
out there is already a procedure that is commonly used to do this.  I
remembered InvalidateRect() after thinking of the message drop-through method.

I was wondering if it would be "bad programming practice" to drop-through, and have
understood your answer, which is "yes".  So I'm going to continue to use
InvalidateRect().  Actually I'm kind of happy that I thought of doing drop-through
- to me it shows that I'm understanding how C / C++ and Windows work,
which is the largest part of this exercise.

Another thing that is kind of interesting is that the WM_PAINT messages I
was sending was the first time I had tried to send messages and it didn't
work - you can imagine how I felt after thinking that I understood how the
message system works, then the first time I try it, I happen to stumble
into one of the special cases....  So this was a good lesson.

Thanks for your reply,


</PRE> 

<HR><A NAME=WINAPI_LF_TOP_MOST>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: 'Always on Top' - How to do it??</H4><PRE>

On 28 Jul 1995 22:43:25 GMT [e-mail] (Bruce J. Veazie) wrote:

>WinHelp and Clock have 'always on top' options as does the MSOffice
>toolbar.

>How can I do that??

I do it calling the API SetWindowPos(): the first parameter has to be
the HWND of the window you'd want to put "always on top", the second
parameter has to be "HWND_TOPMOST".

Hope this helps.
Davide Marcato.

- Young C++ programmer under Windows.
* Internet: [e-mail]
* Fidonet: Davide Marcato@2:333/201.28

</PRE>

</HTML>