Iam trying to remove the frame of my CPropertySheet.
I googled a lot in the last days, but couldnt find a solution.
i thought it would work with:
ModifyStyle(WS_CAPTION, 0,0);
ModifyStyleEx(WS_EX_DLGMODALFRAME, 0, 0);
but it doesnt^^
here is a picture
https://ibb.co/R7b0tdD
i want to remove this 3D border
It is hard to determine, but try removing all border/frame styles but WS_BORDER and make sure to remove WS_EX_CLIENTEDGE style. This is just a guess but I would start with the above steps.
Related
I'm finally getting around to adding icons to our pull down menus:
In this image, you can see that everything but the highlighted line is okay. The highlighted line is fine except for the icon, which is drawn in color, instead of grayed.
I'm basing my code off of a minimalist approach:
http://www.codeproject.com/Articles/16529/Simple-Menus-That-Display-Icons-Minimalistic-Appro?msg=4166441#xx4166441xx
Basically, this only requires that I draw the icon, and I don't have to manage all aspects of a menu item using custom code. Pretty nifty.
It works for our purposes except when selecting a disabled (grayed) menu item.
But when the menu item is grayed and selected, then the drawn icon appears as it would if it were enabled. Wrong. :(
Yet the exact same drawing code works when the background is highlighted/selected.
That leads me to believe that there is some stated contained entirely in the HDC that must control how the icon is appearing - since the following code works under all conditions but selected:
::DrawIconEx(lpdis->hDC, lpdis->rcItem.left+0, lpdis->rcItem.top, pIcon->GetHandle(), pIcon->GetSize().cx, pIcon->GetSize().cy, 0, NULL, DI_NORMAL);
Does anyone know what state is encapsulated in the HDC that would control how DrawIconEx functions? If I can replicate the HDC state during selected drawing as found when not-selected-drawing, I should be able to generate the grayed icons without resorting the 30-50 line implementations that manually gray-scale the icon in memory.
You can use:
DrawState(...)
API function, with DSS_DISABLED flag, but I am not sure about the quality of the output.
What I want to do is force the main frame window background color to be completely transparent.
The only very first method I've found so far is the SetTransparent(wxByte alpha)function. However, this seems to be setting the transparency for the children controls as well - and I don't want that.
I've been trying multiple ways to achieve that, none worked though. Also, most questions regarding this seem to be outdated. Is there any working method (for Windows) which will allow me to set the full transparency for the main frame window?
#Jerry Coffin pointed me in the right direction and I have made a working solution for this. However I still think that mixing both WinAPI and wxWidgets is not the best idea. But well, it works.
wxColour transparentColor = wxColour(wxTransparentColour);
SetBackgroundColour(transparentColor);
SetBackgroundStyle(wxBG_STYLE_CUSTOM);
SetWindowLong(GetHandle(), GWL_EXSTYLE, GetWindowLong(GetHandle(), GWL_EXSTYLE) | WS_EX_LAYERED);
SetLayeredWindowAttributes(GetHandle(), transparentColor.GetRGB(), 255, LWA_ALPHA);
SetLayeredWindowAttributes(GetHandle(), transparentColor.GetRGB(), 255, LWA_COLORKEY);
I need a GroupBox control for something else that showing it in application's window. That's why I want to disable the frame surrounding it (or at least make it invisible by, for example, drawing it with the color that matches with window's background). Both are harder than I thought though, I've been loking for the solution everywhere and found nothing. I don't want to use anything as straightforward as painting over it in WM_PAINT-case in window procedure because there will be that annoying sparkling when I move the window.
I'm running out of ideas, tried a few things on my own, none worked. Anyone have some tips?
I'm writing a Win7 desktop app and want to have it seamlessly transition from windowed to windowed-fullscreen (and vice-versa), and have mostly accomplished this by calling SetWindowLongPtr to update its style immediately followed by MoveWindow to update its size and position. The problem is that the window flashes for one frame to show its style updated, but the new size and position are not shown. The next frame everything looks correct but I'm trying to avoid this single-frame artifact.
I've tried reversing the order in which I call the APIs but it just changes what the artifact looks like. I've also tried hiding the window, calling the APIs, and then showing the window, but this just causes the window to disappear for the one frame.
I know that one option is to create a new window with the desired properties then destroy the old one, but I wanted to find a less expensive alternative.
So is there any way to call these APIs and have them be visually reflected atomically? As a bonus, it'd be nice to also have the multiple resulting WM_SIZE messages coalesced into a single event, but I can manage that myself in the message handler.
Doing this sort of thing reliably is difficult in Windows, particularly since Vista as the DWM can complicate things. It's often a matter of trial and error until you find a solution that works for you.
SetWindowPos has an SWP_NOREDRAW flag that prevents the window from being redrawn in response to the call. So you could try changing the position first, then updating the styles, and finally a third call to redraw the window in its new location. For example,
SetWindowPos(hWnd, 0, x, y, w, h, SWP_NOREDRAW | SWP_NOZORDER);
SetWindowLongPtr(hWnd, GWL_STYLE, dwNewStyles);
RedrawWindow(hWnd, 0, 0, RDW_INVALIDATE | RDW_FRAME);
MSDN says:
Certain window data is cached, so changes you make using
SetWindowLongPtr will not take effect until you call the SetWindowPos
function.
So this should work. Perhaps try using SetWindowPos instead of MoveWindow.
Are you doing anything interesting in your window proc when you get the events that are caused by these calls? In particular, are you "fixing" the size or anything like that?
Check out WM_SETREDRAW; use it to disable redraw, change the window styles, and then call RedrawWindow(hWnd, NULL, NULL, RDW_ERASE | RDW_FRAME | RDW_INVALIDATE | RDW_ALLCHILDREN) to display them atomically.
What do you mean by "windowed-fullscreen"? Is it the same as maximized?
If so, ShowWindow(hwnd, SW_MAXIMIZE) ?
I am trying to get my dialog box to match. I have been all through google, random testing, etc, even read some places it cant be done.
What I have been able to do is to use one of the messages to set font and colors, but nowhere about drawing itself.
I would think it has to be able to do...
Does anyone have any ideas? Or know anything about this?
http://imageshack.com/a/img832/5955/91m.png
It looks like edit controls don't support owner draw, but you can still solve your direct problem. According to the MSDN page for EDITTEXT, by default edit controls in a resource file have the WS_BORDER style set. Looks like you can get rid of it with something like this:
EDITTEXT IDC_EDIT1,17,51,136,14,ES_AUTOHSCROLL | NOT WS_BORDER
For the status bar, you might try using a static control with customized colors instead of a real status bar. Or you could roll your own, specify the window class name in the resource file, and make sure you register the class before displaying the dialog.
UPDATED: Wow, the documentation for status bar is terrible. You can owner draw one, though. Follow these steps:
// where hStatus is the HWND of a status bar...
// You must set simple mode to false, because simple mode doesn't
// support owner draw.
SendMessage(hStatus, SB_SIMPLE, FALSE, 0);
// I'm assuming 1 status bar part for demonstration. Setting the right edge
// for the 1 part to -1 make it take up the whole status bar.
int partWidths[] = { -1 };
SendMessage(hStatus, SB_PARTS, 1, reinterpret_cast<LPARAM>(partWidths));
// There is background stuff that stays behind even with owner draw,
// so you have to set the background color to black, too, to get rid of
// any appearance of borders.
SendMessage(hStatus, SB_SETBKCOLOR, 0, RGB(0, 0, 0));
// There is still a slim border that stays behind, so you need to set
// SBT_NOBORDERS in addition to SBT_OWNERDRAW. The 0 is the index of the
// status bar part. It could be anything between 0 and 255.
SendMessage(
hStatus,
SB_SETTEXT,
SBT_NOBORDERS | SBT_OWNERDRAW | 0,
reinterpret_cast<LPARAM>(_T("Status")));
From there, you must also handle the WM_DRAWITEM for the status bar. Now, as to why I say the documentation for status bar is terrible...
Docs for SB_SETTEXT say the high byte of the low order word of the WPARAM can be one of the values that follows. There are two problems with this:
You can combine them, and you must for this to work. MFC does it, too. I checked.
You might be tempted to write MAKEWPARAM(MAKEWORD(0, SBT_OWNERDRAW), 0). This will not work. By appearances, the SBT_ styles are defined so that they will automatically appear in the high byte of the low word if you just OR them with your index value.
That I had to look at the MFC source code to figure out how to use SB_SETTEXT correctly is telling.
Edit controls do not have an owner-draw mode, however you can subclass an Edit control and process messages like WM_ERASEBKGND, WM_NCPAINT, WM_PAINT, etc, as well as the WM_CTLCOLOREDIT message sent to the edit's parent window.
The answer for part 2, vertical aligning text in an edit:
RECT rect;
GetClientRect(GetDlgItem(hwnd, IDC_TIMEINPUT),&rect);
Rectangle(hdcEdit, rect.left, rect.top, rect.right, rect.bottom);
rect.left+=5; rect.top+=5; rect.right+=5; //rect.bottom+=5;
SendMessage(GetDlgItem(hwnd, IDC_TIMEINPUT), EM_SETRECTNP, 0, (LPARAM)&rect);
Has to be multi-line, and you really do have to play around with different numbers to keep it single lined, and maintain the vertical align. The EMS_SETRECTNP allows you to specify where you want the text to be, allowing the Edit to have a larger height.