Archived

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

Playing "Rocky" with Windows

This topic is 5545 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
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
Thanks again Fel!!! I''b probably going to have to try Less''s idea though and I''ll tell you why... When making screenmates, the screenmate is active and moving. What I''m doing is trying to create an animated desktop. Basically is a static image (by static I mean that the object is not moving) but the pixels change. So my problem was trying to figure out how a user could still move icons over the image so at least it would appear like a desktop, but alas if I can''t get Less''s idea to work then at least I''ll use regions so that only the portion of the animated desktop will be "uncoverable". This way only desktop icons will be affected and not windows that the user pops up.


~Bolt

Share this post


Link to post
Share on other sites
I figured it out myself, mostly because I was curious after a friend asked me how you make one, and I realized I didn''t know, hehe. I did get the region-blitting information off of Codeguru, which is a great MFC site.

Basically what you''re doing with the bitmap is using it as a sort of template to blit out the regions of a window... just like you would do transparent blitting.

Less''s suggestion is better if you have no intention of allowing the user to interact in any way with your overlays.

-fel

Share this post


Link to post
Share on other sites
fel, I noticed two "scrunched" bitmaps in the package - is the ball supposed to compress when it "hits" the bottom of the screen? Or are those leftovers or expansion possibilities?

bolt - here''s another thought off the top of my head - if your goal is to animate the desktop perhaps generating a bitmap in memory and then setting it as the wallpaper might be the way to go. I don''t know if that''s possible - I''ve never programmatically set the desktop wallpaper - but I imagine that it''s possible - it''s probably a matter of tweeking a registry setting.

Here''s the C source for a prog that "clears" the desktop that I found in a newsgroup. Basically it gets a handle to the desktop window and hides it. You''ll have to tweek it to suit your needs, but perhaps you can build on this to blit to the desktop dc

  
// cleartop.c

#include <windows.h>

#include <windowsx.h>

#include <commctrl.h>

#include <string.h>

#include "cleartopres.h"

/* prototype for the dialog box function. */
static BOOL CALLBACK DialogFunc(HWND hwndDlg, UINT msg, WPARAM wParam, LPARAM lParam);

int APIENTRY WinMain(HINSTANCE hinst, HINSTANCE hinstPrev, LPSTR lpCmdLine, int nCmdShow)
{
WNDCLASS wc;

memset(&wc,0,sizeof(wc));
wc.lpfnWndProc = DefDlgProc;
wc.cbWndExtra = DLGWINDOWEXTRA;
wc.hInstance = hinst;
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = (HBRUSH) (COLOR_WINDOW + 1);
wc.lpszClassName = "cleartop";
RegisterClass(&wc);

return DialogBox(hinst, MAKEINTRESOURCE(IDD_MAINDIALOG), NULL, (DLGPROC) DialogFunc);

}


static BOOL CALLBACK DialogFunc(HWND hwndDlg, UINT msg, WPARAM wParam, LPARAM lParam)
{

static HWND hWndLV = NULL;

switch (msg) {

case WM_INITDIALOG:
{
HWND hwndProgMan = FindWindow("ProgMan", NULL);
HWND hwndShellDef = FindWindowEx(hwndProgMan, NULL, "SHELLDLL_DefView", NULL);
hWndLV = FindWindowEx(hwndShellDef, NULL, "SysListView32", NULL);
}

return TRUE;

case WM_COMMAND:
switch (LOWORD(wParam)) {

case ID_CLEAR :

ShowWindow(hWndLV, SW_HIDE);

break;

case ID_RESTORE :

ShowWindow(hWndLV, SW_SHOW);

break;

case IDOK:
EndDialog(hwndDlg,1);
return 1;
case IDCANCEL:
EndDialog(hwndDlg,0);
return 1;
}
break;

case WM_CLOSE:
EndDialog(hwndDlg,0);
return TRUE;

}
return FALSE;
}

// cleartop.rc

#include "cleartopres.h"


100 DIALOG 7, 20, 195, 86
STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
CAPTION "cleartop"
FONT 8, "Helv"
BEGIN
DEFPUSHBUTTON "OK", IDOK, 149, 6, 40, 14
PUSHBUTTON "Cancel", IDCANCEL, 149, 23, 40, 14
PUSHBUTTON "Clear", ID_CLEAR, 13, 15, 40, 14
PUSHBUTTON "Restore", ID_RESTORE, 63, 15, 40, 14
END

// cleartopres.h

#define IDD_MAINDIALOG 100

#define ID_CLEAR 200

#define ID_RESTORE 300


Share this post


Link to post
Share on other sites
The ball animates to flatten when it hits the top of a window or the bottom of the screen.

Keep in mind this was a lecture demo, so it''s super, super simplistic while trying to demonstrate everything possible you might need, including rudimentary animation and window interaction.

That''s why I didn''t just use an elliptical CRgn and call it done rather than go through all the blitting stuff. hehe.

-fel

Share this post


Link to post
Share on other sites
Ok - well the reason I asked is because it doesn''t scrunch when it hits the bottom - at least not every time. It just falls and hits the bottom and stays there. It doesn''t bounce. Is it supposed to?

Share this post


Link to post
Share on other sites
Didn''t see the term used anywhere here (although I guess most of the discussion was about it), but you should look up layered windows in MSDN, which I believe is only supported by NT 5+.

Share this post


Link to post
Share on other sites
No, no bouncing.

It has some random problems scrunching sometimes due to desktop settings (it''s a look-ahead calculation on passing over windows, etc, sometimes it doesn''t look ahead enough). I didn''t want to put a bunch of complex cross-checks in there because I wanted to keep it simple.

-fel

Share this post


Link to post
Share on other sites
I just had another thought along those same lines Less, Fel... What if I could somehow get the MemDC where the bitmap for the desktop is loaded? Is the bitmap considered a child window of the desktop? If so would EnumChildwindow() be the way? I am assuming that since the desktop is a window that it has to load the bitmap into some MemDC (I can''t believe it wold constantly load from the hard drive) so now the question Fel, and Less is how can I get access to that MemDC. Once I get it...the rest would be as simple as bltting to and from the surface!!! that would make life so wonderful (hehe)

~Bolt

Share this post


Link to post
Share on other sites
fel - Ok. I see.

Bolt - It's not the MemDC that you want but the HDC. Once you have that, you could blit your MemDC to that HDC. Your MemDC would be the backbuffer - that is what you would write on and when finished you would then blit that to the HDC. I think that code to clear the desktop lays down the path to the HDC that you want. Here's the parental chain:

HWND hwndProgMan = FindWindow("ProgMan", NULL);
HWND hwndShellDef = FindWindowEx(hwndProgMan, NULL, "SHELLDLL_DefView", NULL);
HWND hWndLV = FindWindowEx(hwndShellDef, NULL, "SysListView32", NULL);

The icons are part of the SysListView32 window - that code above merely toggles the visibility of that window. When that window is invisible - the icons are too - but the wallpaper still shows through. That tells me that the wallpaper is likely displayed as part of one of the two parent windows. Looking at the SHELLDLL_DefView window using that WinSpy program that I mentioned in the other thread, it turns out that the SHELLDLL_DefView window class uses the CS_PARENTDC style. According to the docs, that style sets the clipping rectangle of the child to that of the parent so that the child can draw on the parent. This doesn't mean that the child gets the parents dc or dc settings. The child gets it's own dc as it ordinarily would - the style is supposed to enhance performance - because the child window is clipped differently - the docs are kind of vague on this -

At any rate - that window is likely the one that holds the wallpaper - and since you now know how to get the HWND to it, you can get the HDC to it from that and from there blit your MemDC to that. Give it a shot, see what happens. If it's not the SHELLDLL window then it's the ProgMan window - looking at the classinfo for those windows - the ProgMan window class uses COLOR_BACKGROUND as the background brush and the SHELLDLL window uses COLOR_WINDOW as the background brush - the docs don't say much about those brushes specifically. If it's not either of those windows, then it might be the sibling window to to the listview - whose class is "Internet Explorer_Server"

Time for some experimentation. Let me know what comes of it.

//edit: let _us_ know

[edited by - lessbread on September 12, 2002 10:45:24 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
About a month ago on Slashdot, there was a guy that posted a link to someone who had this.

It was actually to demonstate a security flaw in Windows.

It basically was a window that got the HDC of the window underneath it(I think it was transparent), and then allowd you to send messages to the other program message queue.

It was some sort of research paper, but if I remember correctly, he also posted the source code for it.

Go to slashdot and search.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Ahaha I found it 2 seconds after I posted this.

Here''s the link to the guys paper and file.
I was wrong, no source code, but he tells you exactly what he''s doing.

Here''s the link:

http://security.tombom.co.uk/shatter.html

Share this post


Link to post
Share on other sites
Yes, I read that - the "Shatter Attack" is quite powerful. Foon's approach seems somewhat roundabout though. The source code is available. It's in a zip file. If you thought that was cool - you might also find the Debloit at Elicz's site interesting too. It's similar and simpler. However, I don't think that's what Boltimus is aiming for. I don't think needs "privilege elevation" to achieve his goal.

[edited by - lessbread on September 12, 2002 11:49:50 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
You don''t have to use it for privelege escalation. There are things you could use the general idea for though.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
About a month ago on Slashdot, there was a guy that posted a link to someone who had this.

It was actually to demonstate a security flaw in Windows.

It basically was a window that got the HDC of the window underneath it(I think it was transparent), and then allowd you to send messages to the other program message queue.


It''s not that big of a secret that you can iterate all top-level windows - and get thier HWND, and thus thier HDC.

I have to agree that the more I read about this, the more it sounded like an attempt to acquire passwords...

Man, you could just make an always-on-top window, make it transparent and capture&forward all user input.

Share this post


Link to post
Share on other sites
quote:
Original post by Magmai Kai Holmlor
I have to agree that the more I read about this, the more it sounded like an attempt to acquire passwords...


I can see that too, but this is about the third thread that Boltimus has started in relation to his project. The first two pertained to using EnumWindows and TextOut to display information on the DC - Oluseyi helped out some in one of the other threads too. I don''t think that Bolt is attempting to write a "key logger" of sorts. Taking him at his word - he also wants to draw on the transparent window - not exactly the mark of a "stealth" program, imo. Unless it''s to say "hah! gotcha!" or somesuch

Share this post


Link to post
Share on other sites