-1

I know that a window handle "HWND" can be hidden by the function ShowWindow(hwnd,SW_HIDE), this function deactivates and hides the window.

What I want to do is to hide and activate the window at the same time, I want to get data from the window but hide it at the same time. How can this be achieved?

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
ahmed
  • 37
  • 3
  • 7
  • What kind of data are you trying to get? – chris May 25 '13 at 21:06
  • What do you mean by activate? – shf301 May 25 '13 at 21:13
  • This is my code HWND hwnd = CreateWindowEx(WS_EX_TOOLWINDOW, "LISTBOX", "Facial Features", 0, 0, 0, 0, 0, 0, 0, 0, 0); HDC dc = GetDC(hwnd); ShowWindow(hwnd,SW_SHOW); SetWindowPos(hwnd, 0, 600, 888, 646, 518, SWP_NOZORDER|SWP_NOMOVE); ShowWindow(hwnd, SW_SHOW); RECT ClientRect; GetClientRect(hwnd, &ClientRect); HPEN FaceRectanglePen = CreatePen(PS_SOLID, 1, RGB(0, 255, 0)); //green HBRUSH FaceRectangleBrush = (HBRUSH)GetStockObject(NULL_BRUSH); – ahmed May 25 '13 at 21:14
  • @shf301, Presumably make it the active window. – chris May 25 '13 at 21:14
  • @ahmed, Please add it to your *question* and explain the actual problem you have. I doubt having an active window that's hidden is even possible, but there's probably some other way of doing what you want. – chris May 25 '13 at 21:17
  • ok , I will do this and give a better explanation – ahmed May 25 '13 at 21:19
  • Please use the [edit] link to add code and additional explanation to your question. Comments don't support code formatting, so they're not a good place for this. Also, people who want to answer your question shouldn't have to hunt for this information and read all of the comments. – Cody Gray - on strike May 26 '13 at 08:01

1 Answers1

1

It is not possible to have a hidden window (SW_HIDE) that is active (also known as focused). That's a good thing, though, because if you could it would be a huge security risk. The user could be entering their password and inadvertently providing it to a hidden window that had stolen the focus. Not to mention it would be incredibly confusing to have an invisible window stealing all of the input events.

Now, you can simulate a hidden window by either minimizing your window (SW_SHOWMINIMIZED) or reducing its size to where it is very small. Minimized windows can still be the active/focused window; their taskbar icons will change accordingly to illustrate this. Likewise, Windows doesn't care how small your window is on the screen, it can still be active/focused.

Some older applications would try and simulate a hidden window by moving it to extremely large positive (or small negative) coordinates, where it was assumed that the window would always be off-screen. Of course, the problem with this approach became immediately obvious as soon as Windows started supporting multiple monitors (around the time of Windows 98)—those "invisible" windows started showing up on the additional monitors users positioned to the left and the right of their primary screen. Oops.

However, I don't think any of those approaches are very good design. This is the point where I usually ask people to explain why they think they need to do this. Questions like this one are often manifestations of the XY Problem, where you ask about your imagined solution to a problem rather than asking about how to solve the problem itself. You say that

I want to get data from the window but hide it at the same time

but I'm not sure what that means. What does it mean to "get data from the window"? You can "get data" from a window regardless of whether or not it is active. If you told us what kind of data you want to get, I could suggest a better approach for retrieving the data. But for example, if you want to retrieve the text from a textbox control on the window, you could send the textbox control a WM_GETTEXT message. And there are similar messages for the other common controls.

The only time you need a window to be focused is if you're trying to inject mouse and keyboard events into the input queue using something like SendInput with the goal of driving the app programmatically. This is folly, not least because of its brittleness. Even if you managed to get the window hidden and active like you want, there is nothing stopping the user from clicking somewhere else, changing the focused window, and breaking everything you so carefully set up. There is almost always a better way to achieve UI automation.

Community
  • 1
  • 1
Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574