I'm seeing non-standard behavior (as compared to tools like Word and Visual Studio 2013) in my C++ Windows Forms application. We use Application::Run and then ShowDialog to show various modal dialogs. When one of the modal dialogs is up and I place another application window partially in front of the modal dialog, I can click on part of the modal dialog and it brings it back into the foreground as I expect.
However, if I instead click on part of the main window (shown with Application::Run) the modal dialog isn't brought to the foreground. This makes it hard to bring my application back so I can work on it. Ideas?
A simple MFC app created in VS2013 works as it should too. You can witness this with the About box which is shown with DoModal. I would have expected ShowDialog and DoModal to be equivalents. A simple C++/CLI or C# winforms application acts fine.
And this only happens in out application when our main window is maximized.
It turns out that is caused by our use of the Syncfusion UI libraries. They will be fixing the bug.
Is it possible to add custom controls to a console window? You can use GetConsoleWindow() to get the window's handle, and then add your own menu items or consume all its events. I can't find any examples of people adding extra controls though.
I am developing a small, high performance serial terminal app. It is a console application - RichTextBox is too slow and has issues that make it unsuitable for VT100 terminal emulation.
I want to add some little graphics to show the state of the serial control lines (RTS/CTS/DTR/RI etc.) and perhaps a capture on/off toggle button. Ideally I'd like to add them to the window title bar. Bitmaps are all that are required.
After lots of research I found that it isn't easy, or even possible really.
You can add controls to the window with CreateWindow(), but of course only in the client area which is taken up entirely by the console text box. However, you can at least create floating controls that way, which hover over the text to provide status info etc.
You can put controls in the window borders but only with some hacking on XP or a new API that was introduced with Vista. The problem with this API is that it requires you to draw your own program icon and title text, and the console window doesn't seem to cope with it very well.
You can't add your own menu items because the console window doesn't pass the messages.
In the end I used the function keys for everything and gave a status indication by changing the console window icon.
How can I make the child window appears in taskbar, in win32 program?
(the WS_EX_APPWINDOW Extended Style, help only for top-level window)
Normally only popup windows can appear in the task bar, but you may be able to use the ITaskbarList interface to do this.
According to the docs for ITaskbarList::AddTab,
Any type of window can be added to the taskbar...
I've not tried this myself so I don't know if this will work with a child window but it's the only method I can think of that might be successful.
See http://msdn.microsoft.com/en-us/library/windows/desktop/bb774652(v=vs.85).aspx for more information.
I have a dynamically created toolbar on a plain Win32 dialog. My buttons are added with & shortcuts which correctly puts underscore to characters following ampersand but pressing Alt+(char) causes a beep and the button is not clicked.
It has been a while since I have done Win32 API development. Is there something that needs to be done to a dynamically created child window (toolbar) in order for the accelerator keys to work?
This could be something really obvious that I am missing...
Well... You have to write code to handle these keypresses and convert them into WM_COMMAND messages. The traditional way to do this is to define an accelerator table and process them using TranslateAccelerator() - but of course, you're free to do it however you like... Just make sure the keys you handle jibe with the keys you underline!
You might also find this KB article helpful: How to use accelerator keys within a modal dialog box in Visual C++... Or, for a more in-depth (and MFC-free) look at implementing custom message processing in dialogs, check out Raymond Chen's articles on the dialog manager, specifically part 4: The dialog loop and part 9: Custom accelerators in dialog boxes (but seriously, read the whole thing, you know you want to...)
The beep indicates that the command isn't handled by any window in your app.
Since you created the toolbar dynamically, I would guess that the toolbar window isn't set up properly as a child window of your main window (i.e., it's parent and owner window are not set).
To test: click on the toolbar so it has the focus, then press Alt- and it should work.
We're writing Windows desktop apps using C++ and Win32. Our dialog boxes have an ugly appearance with "Windows XP style": the background to the static text is grey. Where the dialog box background is also grey, this is not a problem, but inside a tab control, where the background is white, the grey background to the text is very noticeable.
In the past we have done a lot of our own drawing of controls, but these days we are trying to use the standard look'n'feel as much as possible, and to avoid overriding standard behaviour as much as possible.
We are using the Win32 API, which is getting a bit dated, but I think the problem occurs even with ATL. We are creating a DIALOGTEMPLATE. The text is in a "static" control (0x0082). The only flag we set for the style is "SS_LEFT". The text control is inside a tab control: "SysTabControl32" with only one flag: WS_CLIPSIBLINGS set on it. I've experimented with SS_WHITERECT and WS_EX_TRANSPARENT and other settings, to no avail.
All of this gets drawn with the standard Windows dialog box message handler. My main question is "what are we doing wrong?" rather than "how can I work around it?", although I'll settle for the latter if no-one can help me with the first.
Any ideas?
The usual way of implementing pages in a tab control is required to access MS's solution to this problem :-
Instead of creating individual controls in the tab area, create a modeless child dialog for each page and have the controls on that. Create the page dialogs with the main dialog (not the tab) as their parent and as the user switches between tabs, simply show and hide the relevant page dialog.
In the WM_INITDIALOG handler for each page, call the uxtheme API EnableThemeDialogTexture
With the ETDT_ENABLETAB flag this automatically changes the background color of the dialog and all its child controls to paint appropriately on a tab.
If you have overridden WM_ERASEBKGND or WM_CTLCOLOR* in your pages DialogProc you will need to revert to default handling (return FALSE) as these methods are where the dialog code is going to do its heavy lifting. The style bits should simply be set as though the child page dialog page was going to be created on a normal windows 9X tabbed dialog.
The reason why the background is gray is because that is the default.
To override it, you can process the WM_CTLCOLORSTATIC message in the parent window and return a custom brush.
Your problem is not with ATL or WinAPI. In MFC there is the same problem.
Set Tab control as parent window for Static controls. But I think that overriding WM_DRAWITEM is more flexible solution.
I've got Win32/MFC applications with labels inside tabs on dialogs, and the background colour looks fine on them (that is, it reflects the XP-look theme, rather than being flat grey) without any obvious special handling.
Under the hood what's supposed to happen is that the label posts a WM_CTLCOLOR message to its parent, which sets the device context up appropriately: the default handling in Windows should set the appropriate background colour, at least for dialogs and tab controls.
One possibility is that you're doing something non-standard in your handling of WM_CTLCOLOR: is it over-ridden somewhere in your application? Possibly you have some old code that is setting the label background colour in this way.
(Also, as Rob asks, are you using a manifest to get comctl32 6.0 into your application?)
We're not overriding the WM_CTLCOLORSTATIC message. There's no occurrence of this string in our source code and nothing like it in our message handlers.
We've worked around this problem by overriding the WM_DRAWITEM message for tab controls to paint their contents with the grey background (standard for dialog boxes without tab controls) rather than the white background (standard for the contents of tab controls).
brush = CreateSolidBrush(GetSysColor(COLOR_MENU));
FillRect(lpdis->hDC, &lpdis->rcItem, brush);
SetBkColor(lpdis->hDC, GetSysColor(COLOR_MENU));
wtext = ToWideStrdup(c->u.tabcontrol.Tabs[lpdis->itemID].name);
rect = lpdis->rcItem;
rect.top += DlgMarginY - 1;
rect.bottom += DlgMarginY;
DrawTextW(lpdis->hDC, wtext, -1, &rect, DT_CENTER | DT_VCENTER);
free(wtext);
DeleteObject(brush);
This is obviously a workaround, not a proper answer to my question.
Incidentally, we initialise the "common controls", of which I believe the tab control is one, using code like this...I don't suppose this is related to the issue?
#pragma comment(linker, "/manifestdependency:\"type='win32' " \
"name='Microsoft.Windows.Common-Controls' " \
"version='6.0.0.0' " \
"processorArchitecture='*' " \
"publicKeyToken='6595b64144ccf1df' " \
"language='*'\"")
...
hCommCtrl = GetModuleHandle("comctl32.dll");`
if (hCommCtrl) {
ptrInit = (TfcInit_fn) GetProcAddress(hCommCtrl, "InitCommonControlsEx");
if (ptrInit) {
data.dwSize = sizeof(INITCOMMONCONTROLSEX);
data.dwICC = ctrlClass;
if (ptrInit(&data) )
gCommCtrlsInitialized |= ICC_TAB_CLASSES | ICC_BAR_CLASSES;
}
}
Have spent an amazing amount of time to try to fix a problem so seemingly simple, tried almost every constant for hbrBackground without success.
As an amateur found that the most simple & time efficient fix was to simply create a "Static" class child window that envelops the entire window. Just another hack level fix though