I believe that the GetConsoleScreenBufferInfo method gets information about the window passed as a parameter into it into a CONSOLE_SCREEN_BUFFER_INFO structure. Can this information be used to recreate a window? Or is there a method which can create a window taking CONSOLE_SCREEN_BUFFER_INFO as a parameter?
There is no function that I know of that will create a new window given a CONSOLE_SCREEN_BUFFER_INFO structure. There certainly isn't such a thing described in the Console Functions reference.
I'd be interested to know why you want such a thing. Are you trying to create a duplicate console window? If so, you should note that a process can be associated with only one console. And you can't create a console window that's not attached to a process. The console goes away when the last process detaches from it.
Related
So I`m very new to win32ui, basically just starting. I was once using BitBlt wit python win32api module and as far as I remember to draw on top of display (so any application - if they are opened) I had to get specific context handle. But my memory is hazy on whether it simply was NULL or was it some specific context? Null doesn't seem to work, so I wonder how to obtain that general context? I really want to avoid to create fully transparent un blocking window.
The GetDC API allows you to get a device context for any given window. Alternatively,
If [hWnd] is NULL, GetDC retrieves the DC for the entire screen.
You can use the device context for the entire screen to read from, reliably (with restrictions). Rendering into a device context for a window you do not own won't be reliable, though. While it won't fail straight away, the window owner can overwrite your rendering at any point. There's no way for you to even be notified about this.
If you need to render on top of the screen you will have to create a top-most (transparent) window yourself, and use its device context. Make sure you ask the question: What if two programs did this?
We have a kiosk mode application for Windows Mobile 5 that was going strong for a year at least in production. It uses window subclassing through the SetWindowLong windows API function to override the behavior of the taskbar to prevent users from ever leaving our application or other explicitly allowed applications.
My callback overrides the handling of a few window messages and calls the default handler for other messages. This is done by storing the previous function pointer returned by SetWindowLong, and using it inside of the new function by calling CallWindowProc on it.
Then we had to update the application to be compatible with Windows Mobile 6.5.3, and started having a bunch of problems. I followed this article to disable the bottom menu buttons which are new on 6.5. On a single application, it works fine and the menu respects my callback. As soon as the user opens up another application through ours, that window seems to be recreated, and I had to devise a mechanism to detect foreground window changes and then "resubclass" the window again.
In my code, I don't have control of when exactly this window is recreated, so my first attempt was to use the GetWindowLong function to obtain the current callback address and test it against my own function address. I learned the hard way that I can't just compare the values like that, since it does not always return the function pointer.
Because I'm not able to test if my method is the current handler that way, I end up sometimes setting my method as the handler, and the previous handler is also my own method (in this case, the window was not recreated and thus already had my method set). This results in an infinite loop, since my callback ends up calling itself indefinitely.
How can I know if my custom function is the one being used by a certain window, so that I can avoid this infinite recursion?
Don't use SetWindowLong(GWL_WNDPROC) to subclass a window. Use SetWindowSubClass() instead (like Raymond Chen said):
Subclassing Controls
Safer subclassing
Amongst providing safer subclassing semantics (such as allowing multiple subclasses at a time), it also allows you to associate user-defined data with each subclass. So you could use GetWindowSubclass() to check if you have already subclassed the window or not.
Or, you could simply keep track of whether or not you have already subclassed the window. A simple boolean variable will suffice. Once your subclass is in place, you MUST remove the subclass before the window is fully destroyed. So, for instance, when the subclass receives the WM_NCDESTROY message, you can remove the subclass and clear your boolean at the same time, and then the next time you see the window again your boolean will tell you that you need to subclass the window.
Send the custom message to window. Handle this message in your custom function to return some value that will indicate that it was your custom handler.. and so on.
if(SendMessage(hwnd, mymsg, 0, 0) != myvalue)
;// It's not your handler
In an MFC program I am trying to access controls that are in one window (class) from another (sibling or daughter) window with code in a different .cpp file. Typically you access a control with a DDX_Control variable defined in the class .cpp file.
DDX_Control(pDX, IDC_STATUS, m_Status);
The code for the other window is in a different file, so I don’t have access to the control variable (m_Status). What I have done is used FindWindow to find the main window, then GetDlgItem to find the control I am interested in:
CWnd * tmpWnd = CWnd::FindWindow(NULL,"MainWindow"); // find the main dialog box
CStatic * tmpStatus = (CStatic*) tmpWnd->GetDlgItem(IDC_Status);
tmpStatus->SetWindowText(“Status Report);
This works fine in the debugger, but fails when executed outside the debugger. FindWindow gets the window ID correctly, but GetDlgItem returns null.
Ideally I’d like to access the control variable (m_Status) from the other window, but I don’ know how to do so. I understand the GetDlgItem is less than ideal under any circumstance.
One solution would be to send a message to the main window class and tell it what to do, but I’d have to have a routine to handle each control and know how to handle whatever kind of data I am sending.
Is there a “right” way to do this?
Thank you
The ultimate answer is to cast to the original class:
((CspDlg *)AfxGetMainWnd())->m_Status.SetWindowText("Report");
Since you created the "main" window you have an object or pointer for it. Or, you can call AfxGetMainWnd() to get a pointer to it. Then you can use that to access a public member such as m_Status. All of your windows are interconnected and it should not be necessary to use FindWindow to find any window in your own program.
The fact that some variables may be defined in another file is not relevant. That can be handled with suitable use of #include "theotherfile.h" and object pointers/references.
I'm learning Win32 assembly. Have some question I search but not suitable result.
Anyone can explain for me What difference between control's window handle and controlID.
They have nothing in common. Every window has a handle, returned by CreateWindowEx(). Such a window can have a few extra properties attached, like a menu handle. The hMenu argument in CreateWindowEx(). If the window doesn't have a menu, a child window won't have one, then you can use that argument to pass an arbitrary other bit of data. It will be assigned to the GWLP_ID property (see GetWindowLongPtr). Also note the GWLP_USERDATA, an extra property that's entirely yours to use as you see fit.
Dialogs take advantage of this, a dialog template that you create in the resource editor gives you a way to number the child controls. With a helper function like GetDlgItem() to get the handle back for a control with a specific number. Which is pretty necessary for dialogs since it is Windows that create the child controls from the dialog template so you don't know the window handles for them yourself.
I'm using SHGetFileInfo to get the icon of specific file type. The MSDN says about the SHFILEINFO:
hIcon
Type: HICON
A handle to the icon that represents the file. You are responsible
for destroying this handle with DestroyIcon when you no longer
need it.
To get the icon from HIcon, I use Icon.FromHandle. Again, MSDN says:
Remarks
When using this method, you must dispose of the original icon
by using the DestroyIcon method in the Win32 API to ensure
that the resources are released.
It is even more confusing as SGHFI_ICON description contains the following information:
SHGFI_ICON (0x000000100)
Retrieve the handle to the icon that represents the file and the
index of the icon within the system image list. The handle is
copied to the hIcon member of the structure specified by psfi,
and the index is copied to the iIcon member.
From this description, it seems like the handle is kept by the OS and I shouldn't actually destroy it.
My question is then: if, and if so, when should I dispose of the icon handle?
Immediately after Icon.FromHandle() ?
When I no longer need the icon created from Icon.FromHandle() ? (in such case I guess that I'd rather copy the icon, release the original and return the copy to avoid handle leaks)
Never (it will be done automatically somehow? Many examples of SHGetFileInfo - even on SO - does not include any code releasing the icon handle)
The system doesn't keep icon handles, it keeps image lists. When you use the SHGFI_ICON flag, SHGetFileInfo creates an icon by calling ImageList_GetIcon against the system image list. You can do this yourself by passing the SHGFI_SYSICONINDEX flag instead to retrieve just the icon index.
The icon should be destroyed when you're done with it.
No, you really do have to call DestroyIcon yourself. The Icon.FromHandle() method is pretty useless to help you with that, it still requires you to call DestroyIcon. You've got to implement your own garbage collector code to know that the icon is no longer in use so it is safe to pinvoke DestroyIcon.
This is cruel and unusual punishment. The Icon class does in fact have a constructor that can create an Icon object from a handle and owns the handle, automatically calling DestroyIcon when the Icon object is disposed or finalized. They however made it inaccessible for unphantomable reasons, major bummer. Reflection to the rescue, you can bypass this silly restriction and still use the constructor, find the code in this answer.