Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Boltimus

Playing "Rocky" with Windows

This topic is 5856 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Is there any way to "punch" a hole through windows? What I mean is, is there anyway (maybe with fooling around with it''s focus, etc?) for a window that is transparent to allow a user to not only see what''s beneath the window but to actually be able to click on it? While at the same time still being able to draw on the transparent window? ~Bolt

Share this post


Link to post
Share on other sites
Advertisement
Still at it?

A pass through click? Interesting thought.

My understanding is that "Focus" pertains to keyboard input.

Have you looked at "WindowFromPoint"? The docs say:
quote:

The WindowFromPoint function retrieves a handle to the window that contains the specified point.

HWND WindowFromPoint(
POINT Point // point
);

The return value is a handle to the window that contains the point. If no window exists at the given point, the return value is NULL. If the point is over a static text control, the return value is a handle to the window under the static text control.

The WindowFromPoint function does not retrieve a handle to a hidden or disabled window, even if the point is within the window. An application should use the ChildWindowFromPoint function for a nonrestrictive search.



So - if you make your primary window a Static window - maybe subclass it - you might still be able to draw on it while letting the clicks pass through. Rather - passing the clicks along to the window underneath.

Share this post


Link to post
Share on other sites
Yeah I''m still at, I''m learning alot too! Albeit at the expense of my hair which is now pretty much gone (hehe) I''ll give that a try. I ordered the SDK for XP, because I heard that there were even better API calls that support what I''m trying to do. If that''s so, I''ll sacrifice backward compatability to get what I need, but it would have been nice to make it more compatible with win 98, etc. I''ve seen programs that do this, so I know I got to be able to do it. It''s just that with windows you have to get the right combinations of function calls to get something to work. It''s like Voodoo magic or trying to make gunpowder from scratch...hehe (like being an alchemist)

~Bolt

Share this post


Link to post
Share on other sites
Just a quick question Less, what do you mean by the word "static" is it a parameter like WS_STatic or something. I tried looking it up in my compiler docs and couldn''t find anything. Or, is it just a reference to the window behavior?

Thanks,

~Bolt

Share this post


Link to post
Share on other sites
In this context "Static" refers to a type of window class. A string lable in a dialog box is usually an instance of a static class. It''s static because it doesn''t change - rather the user can''t change it. That doesn''t mean that you can''t change it though through your code.

This might actually provide a way for you to do what you want - and maybe even a way that will work on 9x too.

Using a static class, you can still draw on the client dc - and it appears that the clicks pass through automatically - and if they don''t then it''s not too much work to put a call to WindowFromPoint into the proper places in the WndProc and pass the message along.

From the docs:
quote:
STATIC Designates a simple text field, box, or rectangle used to label, box, or separate other controls. Static controls take no input and provide no output. For more information, see Static Controls.
For a table of the static control styles you can specify in the dwStyle parameter, see Static Control Styles.



A few of the types of styles are SS_SIMPLE, SS_NOTIFY, SS_ICON, SS_BITMAP

And the intro to "Static Controls" says: A static control is a control that enables an application to provide the user with informational text and graphics that typically require no response.

It goes on: Although static controls are child windows, they cannot be selected. Therefore, they cannot receive the keyboard focus and cannot have a keyboard interface. A static control that has the SS_NOTIFY style receives mouse input, notifying the parent window when the user clicks or double clicks the control. Static controls belong to the STATIC window class.

So - this might very well provide the kind of functionality that you want. If you also want to have keyboard focus at some point or another, you might want to make this static window a child window and/or use a sibling window to receive keyboard input. Toggling keyboard input on and off makes things more complicated though.

It might be that if you use a static class for the main window, then mouse clicks and the like can be passed along to the desktop where the OS will route them for you. That might make things a lot easier for you all together.

2k & XP provide some helpful transparancy api''s, but there are ways to workaround that on W9x too. There is an article at wdj magazine regarding how to do that - I''ll have to dig out the reference for that article - wdj also changed out their web site recently and it''s nearly impossible to use now.

By XP SDK do you mean the latest version of the Platform SDK? That is different than the DDK (device driver kit) which would be XP specific. The PSDK infos pertain to all versions of windows. The newer version of the PSDK would have info on newer API''s of course.




Share this post


Link to post
Share on other sites
You might also want to take a look at the SetWindowRgn() which sets the region that your window occupies. The great thing about regions is that they need not be rectangular. Using SetWindowRgn() you can make a window with a hole in it without problems, and no extra programming is needed. Windows will know that your window has a hole in it and will not send mouse clicks to your window if the user clicks inside the hole.

For a better explanation read the following article: http://www.flipcode.com/articles/article_win32skins.shtml

Drawing on the transparent area might be more difficult as your window doesn't own it (using above method). Of course you can always draw directly to the desktop, but the other windows will draw over your drawing the next time they update.

There is the possibility to use alpha blended windows but that is something I haven't looked into as it isn't supported on all versions of Windows.

www.AngelCode.com

[edited by - WitchLord on September 11, 2002 3:58:39 PM]

Share this post


Link to post
Share on other sites
The problem with using regioning in this fashion is the fact that clicking "through" will bring that window to the top.

Avoid this by using SetWindowPos with the WM_TOPMOST specified.

Otherwise, yes, this should work.

You can also use the WindowFromPoint.

If you would like some well-commented code from a lecture I gave involving using regions and interacting with other windows (from the perspective of a screenmate, in this case) you can download it at:

http://www.knightsvalorous.com/hholland/screenmate.zip

-fel

Share this post


Link to post
Share on other sites
Okay, I jst finished your article Fel, and I just have two quick questions... #1. Did you figure this out yourself or did someone kinda point you in the right sirection? #2. So basically wat I''m doing is setting the window region to be the EXACT size as the bitmap I''m using?


Thanks Fel, once again...you''ve brought 2 weeks of hell to an end...hehe..really.

~Bolt

Share this post


Link to post
Share on other sites
That''s really cool fel! I didn''t know it was that easy to write screenmates (the windowing part at least). I always thought you needed to do some careful work no to have it flicker a lot.

With this reassurance that it is so easy I just might give it a try and write myself a screenmate

Hope you don''t mind me linking your source code in my reference db.

- WitchLord

www.AngelCode.com

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!