I have a WinForms application. All ToolTips are appearing too far below the hovered controls. It happens on tool bars and menus.
I think the reason is that form's font is changed. It is MS Segoe UI 9px.
Is there a solution to move ToolTip to its default place in general for the whole app?
The screen shot is on Windows 8 "Segoe 9px" font. 100% font scaling. The issue appears on other DPI settings and on other windows versions also.
Edit
I compared ToolTip position of my app and VS2012 and Chrome. In my app, ToolTip appears one cursor height below the bottom of the cursor. In VS2012 and Chrome, ToolTip appears one cursor height below the hot point of the cursor (about 2 pixels below the cursor).
Cursor not visible in screen shots:
Edit 2
I checked other winforms apps with default font settings. The ToolTip also appears one cursor height below the bottom of the cursor. It seams this is the default position for winforms. However it doesn't look well compared with other software.
It looks like it can be fixed only with overriding the default ToolTip behavior.
Default tooltip in winforms toolstrip have several problems. I've built custom toolstrip that has custom tooltip available at http://www.codeproject.com/Articles/376643/ToolStrip-with-Custom-ToolTip. I am not 100% sure whether it will solve your problem out of box, but you can fully customize how tooltip appears by altering code.
Related
This program uses winforms and c# (no wpf). I have a panel with buttons on it and getting it to scroll is no problem. However, when the program is on a hi-resolution touch screen -- like a Surface 7 -- trying to touch in the exact right spot to get it to scroll is hit and miss. I've searched and have yet to find a way to make the grab area (so to speak) of a vertical scroll bar wider so that when you touch the screen, the control actually picks up the event. Any ideas on how to do this?
If your application is DPI unaware, then it is enough to set the scrollbar width to SystemInformation.VerticalScrollBarWidth.
Let me explain put it in just a few simplest lines.
I made a new C#/WPF application project in VS 2013 ultimate (x64).
On MainWindow I insert (for example) a button at bottom-right, actually anywhere..
See image below, but the position of the buttons at runtime does not match what it looks like when I am designing
As you can see from the marked up spots in the 2 images, the controls are mispositioned.
I tried to change some XAML attributes, setting min/max sizes, and so on and on. I am running a fresh-install Windows 7 Ultimate (x64) OS, with "Windows 7" aero theme.
I played around MainWindow/Grid properties (tried almost every one), also when I loaded up some custom theme (for example: Expression Dark) issue persists.
Don't get excited so much. Have some control on your temper.
It seems that you have not set the Right Margin of the button you have circled Red in the above image. Try to set the appropriate margins from the Property Window of the corresponding button and see what happens!
I would like to use a ScrollBar in my app but I don't want the default end-arrows showing up; I want to be able to use other "external" controls for activating the scroll bar. Any ideas?
Please don't - scrollbar arrows are an essential accessibility feature when a document is too long to scroll by dragging the scrollbar and when a user lacks a mousewheel or the means to use it, then the only way to scroll is by clicking on the arrow buttons.
(Apple gets away with it because all of their modern hardware supports touch-scrolling, but us on the Windows camp don't have that luxury)
I see that many applications do not have a title bar, but still have the window controls in the upper right corner. These are also styled differently than the normal windows form controls. Is it possible to achieve this effect in WPF?
Here are some examples:
Zune Desktop software:
http://i548.photobucket.com/albums/ii356/elpedrogrande/btns2.gif
Photoshop:
http://i548.photobucket.com/albums/ii356/elpedrogrande/btns3.gif
GoTo Assist:
http://i548.photobucket.com/albums/ii356/elpedrogrande/btns1.gif
They do this by setting the window style bits so it is created without a title bar. And then draw their own, making it look like a custom one. Which is the main reason that all these programs have caption glyphs that are not identical.
You'd accomplish the same in WPF by setting the WindowStyle to None. And a whole bunch of code to get back the behavior that Windows implements automatically with the title bar. Google "WM_NCHITTEST" to find out more.
I'm very new to C# and I've run into a problem and haven't been able to solve it. I have a row of buttons that have .png images assigned to them. The images are in .png format to allow transparency, and smoothing the edges in GIMP leaves some semi-transparent pixels. I've set the Image List Toolbar (imglToolbar)'s properties to recognize "Transparent" as the designated color to show up as transparent. I'm working in Visual Studio 2005.
The strange thing is that everything looks great when I'm viewing the Visual C# form preview window. The icons look exactly as they should. However, once I actually build the project, the buttons treat every semi-transparent pixel near the edge of the image as if it's black. It seems like it can't handle one that's both transparent and has color.
Image of it via the Visual C# form editor:
alt text http://img5.imageshack.us/img5/2577/whatiwanted.jpg
Image of what it looks like when built:
alt text http://img690.imageshack.us/img690/7241/whatigot.jpg
Any ideas as to why this is happening?
I just found the answer, at least to my specific situation.
The form I'm dealing with is a top-level MDI container. For whatever reason, having the icons set to 32 bit color doesn't allow for these semi-transparent pixels to be properly interpreted. Setting it to 24-bit, on a whim, completely solved the problem. Not sure if this is some situation that has come up as a result of some unseen factor, but the color depth change fixed my problem.
Also for those who may come here with a similar problem, make sure the window isn't a child of an MDI container. While looking for information, I found MDI children don't support TransparencyKeys at all.
I ran into this problem as well; changing the form's IsMdiContainer property to false solved it.