When you create a menu bar, a funny line appears underneath (for XP and Win7 at least). How can I get rid of this line? I know that some applications, such as Firefox and Thunderbird, have done so.
Here's an illustration:
I am programming in C, using the Windows API. My menu is loaded from a resource file.
I'd say that line is supposed to be there (Run a simple application like calc and see) If you look at an application like Explorer (Or IE4-6) in XP, its menu is actually a toolbar inside of a rebar.
If you look at a function like GetMenuBarInfo() you will see there is no border property you can query or set.
If a 1 pixel line is that important, you probably have to A) Do some owner drawing on the menu to paint over that line or B) Implement a custom menu control (MS even has a tutorial for IE/Explorer style menus)
Related
Trying to add a tray menu to a GTK+ (2.24) application on Windows 10, in C. Code is exactly as in this example, except the icon. The result is as follows, menu is not visible and there are up and down arrows instead:
In this example (French forum, code works when an image is provided), only down arrow appears and it is possible sometimes (1 over 10) to actually display the menu entry by right-clicking long time on the arrow.
Question is: is this a GTK+ bug, as stated in several forums, or is there a way to create a menu from a tray icon using GTK+ without implementing a custom-drawn one?
Edit: replaced wrong GTK2 tag by GTK.
I'm currently getting back to some Windows Programming using Petzold's book (5th edition).
I compiled the following example using BitBlt and it doesn't work as it is supposed to.
It should copy the Window's icon of (CxSource, CySource) size and replicate it on the whole window's surface.
What happens, in reality, using Windows 7 is that the bitmap below the window gets sourced and copied into the drawing surface i.e. hdcClient.
I don't understand why it behaves like this knowing that it's clear the DC passed to BitBlt is hdcWindow, which refers to a device context obtained via a GetWindowDC(hwnd) of the current application.
I first thought it was due to the fact the transparency mode is enabled by default, but deactivating it doesn't change anything. BitBlt seems to always take the surface below the application Window!
I don't get it! :)
Anyone knows why it works that way and how to fix it?
Making screenshots with BitBlt() did not exactly get any easier since the addition of the DWM (Desktop Window Manager, aka Aero). Petzold's sample code suffers from a subtle timing issue, it is making the screenshot too soon. It does so while Aero is still busy animating the frame, fading it into view. So you see what is behind the window, possibly already partly faded depending on how quickly the first WM_PAINT message is generated.
You can easily fix it by disabling the effect:
#include <windows.h>
#include <dwmapi.h>
#pragma comment(lib, "dwmapi.lib")
And after the CreateWindow() call:
BOOL disabled = TRUE;
DwmSetWindowAttribute(hwnd, DWMWA_TRANSITIONS_FORCEDISABLED, &disabled, sizeof(disabled));
Another tricky detail is that the first BitBlt matters, the DWM returns a cached copy afterwards that is not correctly invalidated by the animation.
This gets grittier when you need a screenshot of a window that belongs to another process. But that was already an issue before Aero, you had to wait long enough to ensure that the window was fully painted. Notable perhaps is the perf of BitBlt(), it gets bogged-down noticeably by having to do job of composing the final image from the window back-buffers. Lots of questions about that at SO, without happy answers.
It is not supposed to copy the windows icon, it is supposed to copy the windows titlebar part where the icon is located.
There are some issues with this (now 20 year old code):
GetSystemMetrics values cannot be used for window related dimensions anymore since GetSystemMetrics returns the classic sizes, not the Visual Style sizes.
Depending on the Windows version, the DWM might define the window size as something larger than your window (where it draws the window shadow and other effects).
Your example works OK on XP:
(There is a small problem because the titlebar is not square (unlike Windows 98/2000 that this example was designed for) so you see a issue in the top left where it is just white. I also modified the example slightly so it varies the HDC source location)
On a modern version of Windows it seems like the DWM or something is not able to properly emulate a simple window DC and parts of the shadow/border/effects area is part of the DC:
I don't know how to fix this but the example is pretty useless anyway, if you want to draw the window icon you should draw the HICON with DrawIconEx. If you want to draw custom non-client area stuff then you need to find more recent examples, not something that only supports the classic theme.
I want to find and replace code in multiple files.
Does anyone know if the feature "find and replace in multiple files" in Sublime Text 3 is gone?
It used to be a feature for ST2 (shift-command-F), see screenshots ST2 and ST3.
Or is there a other way to do this?
The option is still there, but because you're using a custom theme the bar needs to be taller for you to see the entire contents of the panel.
You can grab the top of the panel and stretch it up so that everything is visible and then back down as far as it will go to make it compact again.
You only have to do this once; Sublime remembers the height of the panel and will use it next time (which is why it uses the incorrect height when you switch to a theme that makes everything in the panel taller).
On a WinForm with an extended borders, when i place a text on the glass area it doesn't appear right.
This is how the text looks like Status
a busy cat http://img833.imageshack.us/img833/4732/95454282.png
![form][1]
how can i fix the text to appear normally?
Text in Winforms is rendered with an alpha of 0. Which makes it transparent when you draw on glass. So you'll see the background color, not the ForeColor you selected.
Drawing text on glass is troublesome, you can't get it easily anti-aliased correctly since the background of the text isn't well defined. Note how the screenshot shows how Windows addresses that problem, the text in the window caption has a milky-white background, thus ensuring that the anti-aliasing properly blends the letter into the background.
Which is what you need to do as well. You get text drawn like that with pinvoke, DrawThemeTextEx() with the DTT_GLOWSIZE flag option. Visit pinvoke.net for the required declarations or use this project. And don't forget to provide a fallback so this window still looks decent on older Windows versions. And newer versions, glass is no longer appropriate for Windows 8.
Ive been googling this alot but can't find any working solution. Im using Shell Integration Library to cerate custom Window Chrome and I also need drop shadows for this window. Some say setting GlassFrameThickness to -1 do the trick but its not working for me. And Jeremiah Morrill suggested using DwmExtendFrameIntoClientArea. Ive tried that and it works, sort of. The shadows looks ok but when the window is shown it is first shown as a glass-frame and then a second later the real content is superimposed. This causes to much flickering for me. Is there any way to get rid of this flickering or is there any better way using only Shell Integration Library?
I had a similar problem where it wouldn't display any shadow when using a custom chrome. It worked fine when using the glass.
I got a shadow by setting GlassFrameThickness="0,0,0,1". The glass didn't show and I got the shadow.
Be warned, the shadow is a simple RECT to Windows, so if you have a funky chrome with transparencies it may look funny.
Also if you support the maximized state be aware the you'll need to set a margin on your top-level panel element of "8,8,8,8" when in maximized mode. All other modes should be "0,0,0,0".
To alimbada, the WindowStyle defaults to None on custom chrome.
The Shell Integration Library uses DwmExtendFrameIntoClientArea, plus handling of several Window messages to get the effects. If you're using the full window rect (i.e. no rounded corners) then setting it to (0,0,0,1) as suggested will give you the drop shadows as you want. If you want to simulate the rounded corners of Aero, then setting it to (8,8,8,8) will extend the glass frame enough that the corners also stay rounded, and then you're responsible for not drawing over the corners of the rectangle. The shape of the drop shadow doesn't change regardless of the glass frame thickness.
The flashing you're seeing when setting the thickness to -1 still exists even when not fully extending the glass frame. What's happening is the window is getting shown while the content is still compositing. What you can do is simplify the default UI so it displays quicker (or you can stage it, bringing in a simnple background first and then replacing it with something usable), or you can create and show the window off-screen, and then move it to the desired start location once the content has been rendered. The easy way to detect when it's probably ready is to invoke a DispatchTimer with Priority=Loaded. That should only get invoked once the basic first layout has been completed.