I'm creating a Win32 GUI application using Code::Blocks and MinGW. I am using this tutorial as a guide. Everything worked well until I decided I needed a listbox to display files in the current directory. I don't want the list box in a window by itself, I want it inside the main window. The tutorial I was following wasn't very helpful on this part, so I still don't know how to create a listbox. Using the resource editor somehow, I think. Could someone please help me?
I assume you have a window procedure somewhere (let's call it WndProc) for your main window (let's call it hWndMain).
Add a WM_CREATE handler in WndProc if it's not already there.
In the WM_CREATE handler, add a call to CreateWindowEx to create the listbox as a child window of hWndMain:
const HWND hWndList = CreateWindowEx(...);
The picky parameters of CreateWindowEx that are essential here are the class name "LISTBOX", that the style parameter must include the WS_CHILD flag (plus the other essential listbox flags, of course) and that the parent parameter must be hWndMain.
For the other parameters, use your brain and read the docs.
Related
I would like to create a custom File Open dialog where I can replace the default context menu options shown when the user right clicks one of the files in the list, with my own context menu.
Based on articles such as this one, and this one, I tried adding:
UINT CALLBACK OfnHookProc(HWND hDlg, UINT uMsg, UINT wParam, LONG lParam)
and then refer to it using
ofn.lpfnHook = OfnHookProc;
I guess the ideal solution will be a class derived from OPENFILENAME. Not sure how.
For the Explorer-style Open dialog box:
The default templates are not available for modification.
The hook procedure does not receive messages intended for the standard controls in the dialog box.
So there seems little possibility to replace the default context menu via editing or subclassing the open dialog itself.
From the user's perspective, the chief benefit of the common dialog
box is its consistent appearance and functionality from
application to application. Hiding original controls or otherwise
changing the intended functionality of the original controls is a less appropriate customization.
However, there is a workaround maybe help:
Add your context menu item to the default one as an addition. Like this:
Refer to "Creating Cascading Menus with the ExtendedSubCommandsKey Registry Entry" for more detailed information.
Note: Modifying registry will affect all application instead of only your own application. So make sure keep this modification in a mini, required scope. For example, if putting this change in HKEY_CURRENT_USER\Software\Classes is enough don't put it in HKEY_LOCAL_MACHINE\SOFTWARE\Classes.
As mentioned by #remy-lebeau, you can do that using window subclassing as listed below:
get hWnd of the File Open dialog
replace WndProc via SetWindowLong(hWnd, GWL_WNDPROC, ..)
after that you will be able to track mouse position and handle WM_RBUTTONDOWN
To get window handle, you can use FindWindowEx, EnumWindows or even SetWindowsHookEx. Don't forget to pass unhandled messages to the original window procedure.
Hi i Want to Add Window(Gui) to my ConsoleApplication in C++
How to do this?? I need something called Hwnd? I tried to use it and it does not work for me
Basically what I want to do is a MessageBox that will be every time somewhere else on the screen .. but I realized that you have to do it with HWND.
I need Tutorial How to create windows with hwnd
I try:
HWND GetWindow(HWND hWnd, UINT uCmd);
Check if the following code meet your requirement:
#include <windows.h>
int main()
{
MessageBox(nullptr, TEXT("Hello World!"), TEXT("Message"), MB_TOPMOST);
}
It will like this:
You've used multiple tags, I have a winapi solution, not a winforms one.
You can use a std. MessageBox by calling the function, but they can't be „evolved“ into your custom windows for any reasonable „price“ so they can only notify user and ask simple yes/no questions. For „real“ windows, let's forget MessageBox.
The simplest custom window is a std. windows Dialog. It uses the pre-defined window class #32770, so you don't have to register your window class, create a message loop etc. The simplest way to open it is DialogBoxParam function. You must make a .rc dialog script (there are lots of visual editors), compile it with a resource compiler, link into your .exe and pass it's name as the parameter for DialogBoxParam.
Here's an example of a window inside a console application (C++ part only), using this DialogBoxParam call
DialogBoxParam(GetModuleHandle(NULL),"EXAMPLE",NULL,ExampleWindowFunction,NULL);
It's here: https://pastebin.com/Crkdy5FB
It also contains image drawing (you probably don't need it yet, it's left from another winapi example). Use it as a sandbox, you'll probably quickly understand how it works and what role the hWnd plays here.
I understand your problems. GUI got so overcomplicated so it's hard to understand what exactly you don't understand. It prevents from asking a good question.
I'm trying to get the HWND of a QMdiSubWindow which I added to a QMdiArea.
I used the following code to get the handle:
Dialog* subWindow = new Dialog(this);
QMdiSubWindow* sw = ui->mdiArea->addSubWindow(subWindow);
(HWND) hwnd = id->winId();
To test if it worked I used the following code:
SetWindowText(hwnd, "Hello, World!");
Nothing happens. If I run the following code:
SetWindowText((HWND) this->winId(), "Hello, World!");
It works correctly for the main window. The code is placed in the constructor of the main window. The type of the subwindow class is QDialog.
Any ideas how to get it working?
You probably have à correct HWND but it may actually not be the one you are looking for (one visible window could actually be made of a few nested ones: you may believe you picked up the right one when you actually wish to pick up its child or parent).
I suggest that you use Microsoft spy tool, use the finder tool to select the mdi widget you are interested in (directly on your displayed GUI), spy tool will give you its HWND. Then you can check Qt reports you the same id.
Is there any way to change name of process?
I am developing App in MFC c++, but I want it to be invisible for HWND FindWindow(Name Window, Clasename of Window) function.
It is easy to change Caption of main window, but I have no idea how to change classname of Window.
To set the window class name of your main window in MFC you first call AfxRegisterClass (doing this in InitInstance, before the window is created) with your desired classname and then in the mainframe class override CMainFrame::PreCreateWindow and modify the passed in CREATESTRUCT with your desired classname.
This can be useful if you want another process to easily find your main HWND, but it is not very useful to try and make your window invisible to FindWindow.
I want to change the message handler for an old legacy app we use but don't have the source for any more. In a dll that we do have the source for I'm wanting to intercept the window messages and then pass them onto the app. Is this possible? I tried something along the lines of:
WNDPROC lpfnWndProc = NULL;
void GetHandler()
{
HINSTANCE hInstance = GetModuleHandle(NULL);
HWND hWnd = GetActiveWindow();
WCHAR lpClassName[1024];
GetClassName(hWnd,lpClassName,1024);
WNDCLASSEX wc;
GetClassInfoEx(hInstance, lpClassName, &wc);
lpfnWndProc = wc.lpfnWndProc;
wc.lpfnWndProc = NewMessageProc;
RegisterClassEx(&wc);
}
However GetActiveWindow fails and just returns NULL. Is there a simpler way to do this. Infact I'd be happy if I could just simply add another message handler.
It is not clear whether you want to subclass specific controls, or all windows of a particular window class.
If you want to subclass specific controls, the section Subclassing Controls in the MSDN describes how to do this, both for ComCtl32.dll version 6 and above, and the legacy procedure of directly replacing a control's window procedure.
If you want to subclass all controls of a particular window class you would have to change the entries stored in the registered window class, using SetClassLongPtr. Note that this will only affect windows subsequently created with that window class. This is a bit of a Catch 22, as you need to have a window handle when calling SetClassLongPtr, limiting the applicability of subclassing a window class.
As for the code you posted, there are a number of issues:
Your call to GetModuleHandle retrieves the wrong HINSTANCE, namely that of the calling application. Since you need the module handle of the module that registers the window class you have to pass the name of the .dll that implements the controls.
Calling GetActiveWindow may or may not return a value, depending on whether or not the calling thread actually does have an active window. In your case it apparently doesn't, so you need another means of retrieving a window handle, such as FindWindowEx.
Your final call to RegisterClassEx doesn't do what you think: It will simply fail, since you cannot re-register a window class with the same name of an existing window class. You need to call SetClassLongPtr instead, as illustrated above.
I'd actually use SetWindowSubclass after getting the HWND of the window you want to modify the behaviour of. SetWindowLong was deprecated as a way to change the WndProc of a window back around the time that CommCtrl.dll version 6 came out. MSDN can tell you all about that particular part of history and its motivation - just look up SetWindowSubclass.
As it stands, assuming the calling thread has an active window, your code will simply create a new window-class with the same attributes as your target window, albeit with a different WndProc - it wont set the wndproc of an existing window.. - (hence my mention of SetWindowLong and SetWindowSubclass)
EDIT: Or at leaast, it would of not for the oversight I made on that point. As pointed-out in a comment below, this call to RegisterClass will actually fail - you can't register the same className more than once.
You should also probably look at the FindWindow function - just give it a NULL lpWindowName, and the (known) class-name of the target window. In the event that the desired window is not the one that's returned, you could use EnumWindows. Simply call GetClassName in the callback function you supply to EnumWindows, subclassing any/all windows whose class-name matches the class-name of the target window.
Once this window has been subclassed, you can consume its messages as you wish, passing them onto the original window-proc as needed.