If a window is created with transparency (RGBA) on one screen and the user moves the window to another screen. Can the other screen not support transparency?
XCreateWindow(display, xparent, 0, 0, 1, 1, 0,
vinfo.depth, InputOutput, vinfo.visual,
CWEventMask | CWOverrideRedirect | CWBitGravity |
CWColormap | CWBackPixel | CWBorderPixel, &attr);
Show I verify the visual again if the Screen changes?
You get a good answer here:
3.1 Visual Types
For each screen of the display, there may be a list of valid visual types supported at different depths of the screen. Because default windows and visual types are defined for each screen, most simple applications need not deal with this complexity. Xlib provides macros and functions that return the default root window, the default depth of the default root window, and the default visual type.
see also: 2.2.3. Screen Information Macros
Related
I am creating a dialog with a tab control. Each tab should show different set of controls, so I have created child dialog boxes in resource editor to behave like pages.
I have used instructions from this post to do this.
In resource editor I made dialog boxes without border, set their styles to Child, removed system menu, and I have set flags Control and Control Parent to true.
In my child dialog box procedures I have handled WM_INITDIALOG by adding EnableThemeDialgTexture(handleOfmyDialog, ETDT_ENABLETAB); and returning TRUE. No WM_ERASEBKGND, WM_PAINT or WM_CTLCOLORDLG have been overridden.
In main dialog box that contains tab control, I have created "child dialogs" with CreateDialog function, and have used MoveWindow to properly position them.
I did not use EndDialog to destroy "child dialogs" on IDCANCEL or WM_CLOSE, I think that they will get destroyed automatically.
I have used Visual Studio 2013 on Windows 8.1 to do all this.
There seems to be no problem on Windows 7 and Windows 8.1, but maybe my eyes are playing tricks with me, since the background color of the tab control is similar to the default background color of the dialog box. The problem is best seen on Windows XP, as shown on the picture below:
How can I make background color of "child dialogs" ( and their child controls like checkbox/trackbar/radio button/static control ) to be transparent ( match the background color of tab control )?
Thank you.
This is a pretty straight-forward problem. You can't see the mistake on later Windows version because they no longer use a gradient for the "texture". EnableThemeDialogTexture() worked just fine, your dialog certainly has the same texture as your tabcontrol. The brush origin starts at the upper-left corner of the dialog. Like it does for the tabcontrol. But the dialog is not positioned correctly, now the gradients are mis-aligned and the dialog no longer blends.
You need to move the dialog so it is located correctly inside the tab page area. The relevant line of code from the MSDN article:
// Size the dialog box.
SetWindowPos(hwndDlg, NULL,
0, 0, // <=== here!
rcTab.right + cyMargin + (2 * GetSystemMetrics(SM_CXDLGFRAME)),
rcTab.bottom + rcButton.bottom + (2 * cyMargin)
+ (2 * GetSystemMetrics(SM_CYDLGFRAME))
+ GetSystemMetrics(SM_CYCAPTION),
SWP_NOMOVE | SWP_NOZORDER);
Positioned at (0, 0) in the client area of the tabcontrol, now the gradients align.
Hans’ observation is right, but with the wrong conclusions.
Indeed, EnableThemeDialogTexture() worked: There clearly is a gradient on the background of the Slider control. And indeed it does not line up with the tab control’s background.
However, this is not an alignment problem. The gradient you see on the Slider control is the correct gradient according to EnableThemeDialogTexture(). The gradient on the background is actually the wrong one. You can clearly see it with enhanced contrast – the background gradient is blocky and coarse, while the Slider’s gradient is perfectly fine.
I observed this exact behavior when the main window had the WS_CLIPCHILDREN style set while the Z order was wrong (tab above child). Move the child dialog boxes to the top of the Z order via SetWindowPos(child, HWND_TOP, 0, 0, 0, 0, SWP_NOACTIVATE | SWP_NOMOVE | SWP_NOSIZE) and it should align perfectly and not be blocky any more.
I am using the code below to capture a screenshot of a window using bltblt. However the titlebar appears completely black in the captured screenshot. I am running the code on Windows 8.1. Is there a way i can correctly capture the title bar.
// Retrieve the handle to a display device context for the sourceWindow
hdcScreen = GetDC(ss);
// Retrieve the handle to a display device context for the dest window
hdcWindow = GetDC(hWnd);
//Get the client area for size calculation
RECT rcClient;
GetWindowRect(ss, &rcClient);
if (!BitBlt(hdcWindow,
0, 0,
rcClient.right - rcClient.left, rcClient.bottom - rcClient.top,
hdcScreen,
0, 0,
SRCCOPY|CAPTUREBLT))
{
MessageBox(hWnd, L"BitBlt has failed", L"Failed", MB_OK);
goto done;
}
EDIT:
The window i am displaying the screenshot in would cover the entire desktop and will be constantly updating the screenshot of the window just behind it. Also, the window displaying the screenshot will always be the topmost window.
The information you want is not all available from the window DC. Themes get painted over the top.
If you want an exactly visual representation you need to find the screen coordinates of the window (or part of it) and then blit from the screen DC.
If the window is not displayed, you may have an insurmountable problem. As far as I know the theme (since at least Windows Vista) is not part of the Window DC but is painted over the top using non-GDI techniques. The GDI simply does not have the capabilities to paint sophisticated blends and transparency effect. Until Windows 8 it was still possible to select the old classic themes but now they're gone. You may find that the title bar simply isn't painted in the NCPAINT handler any more.
Is it possible create MFC form that cold stay on the top of all applications on PC not allowing to do anything else without entering required information.
Win32 doesn't support system-modal dialogs any more, as far as I'm aware. This is a relic from 16 bit Windows versions.
You can try yourself with a MB_SYSTEMMODAL type MessageBox.
Closest thing would be to utilize a screen-sized window to display a dimmed desktop background while your dialog is shown. This simulates the behaviour of the user account control -- except that you still can switch tasks.
You can obtain something similar setting your window on "TopMost". You can do it on property sheet in design mode, or programmatically with this line:
SetWindowPos( pWnd->m_hWnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE );
Hope this will fit your needs.
I am using CMFCTabCtrl in my dialog based application.
I need to add CPropertyPages to each tab or adding controls to each tab page.
I know from microsoft sample we can add control dynamically as follows
m_wnd1.Create (WS_CHILD | WS_VISIBLE, CRect (0, 0, 0, 0), &m_wndTabConfiguration, 1);
m_wnd1.SetFont (&afxGlobalData.fontRegular);
m_wnd1.SetWindowText (_T("Edit 1"));
m_wnd2.Create (WS_CHILD | WS_VISIBLE, CRect (0, 0, 0, 0), &m_wndTabConfiguration, 2);
m_wnd2.SetFont (&afxGlobalData.fontRegular);
m_wnd2.SetWindowText (_T("Edit 2"));
m_wndTabConfiguration.AddTab (&m_wnd1, _T("One"), 0, FALSE);
m_wndTabConfiguration.AddTab (&m_wnd2, _T("Two"), 1, FALSE);
Which is working fine.
But i want to design controls layout statically and show in tab pages.
Any help is heartily welcome...
If I understood your question correctly, you want to add controls on the different tabs in the CMFCTabCtrl? If so, I believe you can create the controls statically via either:
(1) Using the visual editor that comes with visual studio 2010, the visual editor will modify the .rc file of your project (can be found under the Resources filter) accordingly.
or
(2) You can edit the .rc file of your project directly by adding entries for new controls inside your dialog box.
Whichever method you choose, you will have to however place these controls in the correct positions ontop of the tab control! You then map the windows message that is related to a tab change by the user (check MSDN for proper info on the message id etc) and map it to a function in your dialog class (lets say OnTabChange) where you then determine which controls to hide and which to show (control.ShowWindow(SW_HIDE) or control.ShowWindow(SW_SHOW)) based on which tab is currently active/selected. The mapping is done similiar to how you would capture a button click event etc.
I am trying to create a full-screen control panel window with many controls: buttons, sliders, list boxes, etc.
I can create a dialog window and add controls to it, but everything is scaled in dialog units. I just want to create a window in the GUI editor that is scaled in pixels, not derived units like dialog units.
I can sort of lay out all the controls in the GUI editor and then resize the window programmatically to full-screen using SetWindowPos, but the dialog window in the GUI editor will not look the same as the final product. I want it to be WYSIWIG in the GUI editor.
This is the front end for a small dedicated instrument control computer running XP. The SDK is written in MFC. I have to add and change controls frequently. The screen is small, 7" # 800 x 600, so of course I am developing the program on a different computer. I don't want the program window to change when I change monitors -- I want it fixed at 800 x 600, and I want the controls to be fixed in size and layout as well.
There must be a way -- this is more basic than the default functionality.
Thanks.
Dialog Units are based on properties of the font used by the dialog. A horizontal dialog unit is equal to 1/4th the average width of the current font.
A vertical dialog unit is equal to 1/8th the average character height of the current font.
I'd recommend using method 2 (MapDialogRect() for a 4 x 8 dialog) to figure out how many DLUs 800x600 corresponds to on your output display then make a reference form equal to that size. You can later use that reference form while you're designing.
p.s.-I'm glad Visual Studio no longer emphasizes dialog units since they were always a pain to deal with.
Thanks. I was able to make a reference form by just resizing the form manually in the GUI editor over and over again until it exactly filled the screen... No kidding that dialog units are a pain. From your response, I guess in the current Visual Studio there is a better way to do this? (This is my first experience with Windows programming).