I've been writing a custom drawn tab control for a few days now and for the most part everything is pretty and it does an amazing job ... except when I use it on my Windows 10 computer (at run-time).
I've gone back to the most basic few lines of code to trace the error and I can't for the life of me figure this out.
Below is the only code being used, in a nutshell I'm designing a horizontal aligned tab control.
using System.Drawing;
using System.Windows.Forms;
namespace WindowsFormsApplication1.UI
{
class TabControlTest : TabControl
{
public TabControlTest()
{
Alignment = TabAlignment.Left;
SizeMode = TabSizeMode.Fixed;
}
}
}
I've simply added the custom tab control to the form, added a couple of group boxes for reference purposes and changed the background colour of the form to grey so you can clearly see the tab control.
Now, at design time the 2 group boxes (1 in the tab control, 1 on the form) align perfectly.
But at run-time I see a very different result.
As you can see the tab part of the control is now larger than it was at design time and the resulting change means the contexts of the tab have also moved.
If I do this on a Windows 7 computer everything is displayed as it appears at design time, as it should!
I've added ImageSize but it makes no difference.
ItemSize = new System.Drawing.Size(30, 150);
I've reinstalled VS on my (Win10) development machine. I'm at a loss to explain why and how to resolve this.
Any/all help would be immensely appreciated.
Looking at your tab width in your comparison images, I believe this is another issue caused by automatic Windows control scaling. I found that it is the dpiAware option is automatically set when it's run from within Visual Studio and then reverts back to the default Windows Scaling that windows Implements when outside Visual Studio.
To prevent that auto-scaling when run outside Visual Studio altogether you need to Notify the OS that you're application is dpiAware by calling the Win32 P/Invoke SetProcessDPIAware() method from within your Main() before Application.Run() is called, like the example below demonstrates. This will let your controls use the native resolution which your designing the coordinates from.
static class Program
{
[System.Runtime.InteropServices.DllImport("user32.dll")]
private static extern bool SetProcessDPIAware();
static void Main(string[] args)
{
if (Environment.OSVersion.Version.Major >= 6)
SetProcessDPIAware();
Application.Run(new UIMonitor());
}
}
Alternatively, if you want to keep the scaling, you may be able to set the GroupBox location based off the Width of the Tab Control instead of a specific location. (Or by using some combination of Control measurements instead of exact picel placement.)
Related
I have noticed this issue many times since Visual Studio 2010 but not all times. Now I am using Visual Studio 2019 most recent version. At design time I create controls like labels and buttons which shows very smooth text of Segoe UI font. After running Winform app the text on Labels and Buttons get creepy and not clear and smooth.
I have attached Image for your reference to see the difference.
I have also checked Application.SetCompatibleTextRenderingDefault(false); and form AutoScaleMode and also DoubleBuffered but with no luck. Is this a long time bug in Visual Studio or some settings of the system.
Kindly provide me a perfect way around of this issue. Thanks
see this by #Hans Passant:
https://stackoverflow.com/a/13228495/2696230
it has worked for me
[STAThread]
static void Main() {
if (Environment.OSVersion.Version.Major >= 6) SetProcessDPIAware();
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1()); // Edit as needed
}
[System.Runtime.InteropServices.DllImport("user32.dll")]
private static extern bool SetProcessDPIAware();
Not sure if you want the smoothness only approved for you (on your computer) or for everyone using your application.
If the goal is to only approve it for you then enable Cleartype and make sure to use a mordern font.
If not, then you can make a picture of your text and use a PictureBox instead of a TextBox, Label or whatever you are using and insert the picture of the text to the PictureBox.
You may also create a custom class and use this instead of your item, then you can override the OnPaint event and change the Graphics TextRenderingHint. Check out this Link to see how it can be done with a Label.
I am writing an application in .NET that has a plugin interface. That plugin interface provides several ways to draw information (controls) onto the surface of the application window. While there are several reasons why I am doing this, the main reason is to provide custom colorization to text, either through the use of a graphic or directly manipulating the color of the text based on the background color. I do this through the use of a "text mask" which is a black and white bitmap that works as an "alpha" map to let the Paint method know where to apply the texture/color changes.
The plugin developer has the option of using regular text (such as with a label), mask text (which is drawn to the mask rather than as a regular control), OR letting the user decide. To go along with this, I have provided a modified label class that can either be drawn "normally' (when the text mask is not set for the control), or to the text mask when the User OR Developer decides (depending on what the plugin developer wishes to offer to the user). Here is the class's code so that you understand how this is being done:
public class MaskingLabel : Label
{
private static readonly SolidBrush maskBrush = new SolidBrush(Color.White);
public Bitmap Mask { get; set; }
public MaskingLabel() : base() { }
protected override void OnPaint(PaintEventArgs e)
{
if (Mask == null)
base.OnPaint(e);
else
{
Graphics g = Graphics.FromImage(Mask);
g.DrawString(Text, Font, maskBrush, Location);
}
}
}
The problem I am running into is that this approach requires that I handle controls in a very specific order so that the form is drawn correctly. I need to find the most efficient approach to get the tasks listed below done in the order given. I have thought of three possibilities discussed further down. For reference, this is the order in which tasks must be done:
All "MaskingLabel" controls that have the bitmap object set to the mask must be drawn first so that the mask is created before the next step.
The mask is applied to the background picture.
The resulting Bitmap is drawn in a way similar to the way a background would be drawn (except that it is modified first).
The rest of the controls are drawn as normal.
Is there a way for me to insure this happens without separating the controls manually? My first guess is no. As such, I have a few guesses below about how I should go about this. I was hoping someone with more in depth knowledge of GDI+ could offer some insight.
One idea that has occurred to me is to draw the masked controls during the OnPaintBackground method. However, I don't want to waste time by painting the controls twice. This means I would need to filter out which controls are drawn during the main Paint method which effectively leads us to option 2 (FAIK):
I can manually filter out the controls which draw to the mask so that they don't get added to the control. My question here though is would they get drawn at all? Can I manually force them to invoke the OnPaint method?
If doing that wouldn't work, then perhaps I can create a separate derived panel control to serve as a "backdrop" child control that acts as the background picture which can be forced to be drawn first?
EDIT (With Part of the answer):
I realized after posting this that I already have part of the solution built into my project. Still, I think it is a legitimate question to ask, so if anyone can add insight beyond what I have done in my description below, it is welcome.
Specifically, my project has only two controls that are added to the "root" form: a bar that goes to the top (docked at the top when it is shown), and a transparent panel that occupies the rest of the space (with a dock style set to fill). So my solution would be to add the mask controls to the main form and add all the rest to the panel. This only leaves one remaining issue to be resolved: How do I make sure that the panel and the bar are drawn last? (As part of step 4 in the first list?)
I have two UWP apps and after testing them out with Continuum I noticed the app bar of the OS (the bar with the Start button) at the bottom of the screen (it can be at each of the 4 edges of the screen, of course) was covering part of my app.
Now, I'm already using ApplicationView.GetForCurrentView().SetDesiredBoundsMode(ApplicationViewBoundsMode.UseVisible) before calling Window.Current.Activate(), but that doesn't seem to solve the issue.
1) Why is it that setting the DesiredBoundsMode property doesn't seem to work here? Shouldn't that automatically resize the window
content to the visible bounds (ie. excluding system overlays like the
navigation bar or the app bar)?
The workaround I'm using for now on Windows 10 Mobile devices is to subscribe to the VisibleBoundsChanged event and then manually adjust the margins of my Window.Current.Content item to make sure it doesn't show anything behind covered areas of the screen.
Basically, I use the Window.Current.Bounds property and the ApplicationView.VisibleBounds property to calculate the occluded areas on the different edges of the app window, and increase the margins from there.
2) Is there a proper/better way to do this?
I mean, I'm quite sure there's another method that should be used to avoid this issue (considering there are tons of different situations like Continuum, navigation bar etc... that I don't think are supposed to be manually handled one by one).
Thank you for your help!
Use the subscription to the event VisibleBoundsChanged. This is the best solution that I found.
var curr = ApplicationView.GetForCurrentView();
if (curr.IsFullScreenMode == true)
{
ApplicationView.PreferredLaunchWindowingMode = ApplicationViewWindowingMode.FullScreen;
curr.FullScreenSystemOverlayMode = FullScreenSystemOverlayMode.Minimal;
}
else
{
ApplicationView.PreferredLaunchWindowingMode = ApplicationViewWindowingMode.Auto;
curr.FullScreenSystemOverlayMode = FullScreenSystemOverlayMode.Standard;
}
In the software products I'm currently working on, we have several 3D View controls. Appeared the need to have overlay information on top of these 3D Views. I won't go into too much background details, because it is not the point, but here are the constraints we face :
we must use two different 3D View controls
we don't have the source code for them
they are embedded in Windows Forms controls, and all our own GUIs around these controls are in Windows Forms
we use .NET Framework 3.5SP1 and Windows 7
We want to be able to display various overlay informations and controls on top of these 3D views, because we usually demo our products by showing full screen 3D views on big screens, and not show our GUIs, which have the necessary information and controls.
Back in the days we used only one type of 3D view, I managed, via various hacks involving reflection, to hook my own overlay window system written in DirectX (based on WorldWind .NET overlay widgets, the 3D view was indeed based on WorldWind at the time). The next version of the 3D View product made huge changes to the rendering core code and of course made these hacks incompatible (yeah, I had it coming, I know :-)). Moreover, we are now using, because of different needs in other products, another type of 3D View, closed source as well.
I emphasize the fact that we don't have the source code for them because we can't have access to the rendering loop and therefore cannot hook a windowing system made for 3D Engines, such as CEGUI (search for it yourself, I'm not allowed to post much hyperlinks yet, sorry).
Consequently, I had the following idea : since our 3D Views are embedded in winforms controls, why don't we code our overlay controls in plain winforms, and overlay it on top of the 3D views? The advantages of this solution are huge :
this would be compatible with both 3D Views, enabling us to reuse overlays across engines, if needed
we would be able to reuse custom controls or forms we already developed for the rest of the GUI. Indeed, it is a pretty big project, and we are beginning to have quite a library of such controls.
The only slight (!) problem is that we want to be able to manage overlay transluency, like I did with my former system in DirectX. We can't afford fully opaque overlays, because it would clutter the view too much. Imagine something like a barely visible overlay, becoming more opaque when the mouse is hovering over it for example.
Windows offer the possibility to have child windows inside other windows or controls (Win32 API doesn't really make a difference between windows and controls, this is pretty much a MFC/WinForms abstraction as I understood it), but since it is not top-level windows, we cannot adjust the transluency of these, so this is not something we can use. I saw here, that this is however possible on Windows 8, but switching to windows 8 is not possible anytime soon, because our software is deployed on quite a few machines, running 7.
So I started an intense googling session on how could I work around such a problem. It appears I must "enslave" top level windows to my 3D View controls. I already tried out something like that directly in winforms, having a form owned (not parented, there is a clear distinction, read about it in the previously linked MS page) by a control, and "following" its movements on screen. As expected, it kind of worked, but the issues are difficult to overcome. The most important is a clipping issue. If the parent form of the owner control changes its size, the overlay form is still shown in full. In my sample, I have a simple form with a menu, and a black panel containing a calendar (to show clipping differences between child controls and owned ones). I "enslaved" a borderless form containing a property grid to the black panel. It successfully follows the forms movements, but if I shrink the main form, I get this :
Clipping issue screenshot
Note how the calendar is clipped correctly (child window), and the overlay is not (owned window). I also get weird effects when minimizing/restoring the main form. Indeed, my overlay disappears when minimizing, but when restoring, it just "spawns" while the restoring animation of the main form is occuring. But this is less of an issue, and I guess can be worked around by handling proper events (but which ones?).
From what I understood, I must handle at least some of the clipping myself, using win32 API calls and hooks. I already begun to document myself, but it is quite complicated stuff. The Win32 API being a real mess, and myself being a former Unix developer introduced to Windows programming via the great .NET framework, I don't have any real experience in Win32, and therefore don't really know where to begin, and how to make myself a path in this jungle...
So if a winapi guru is passing by, or if someone has some other idea to achieve my goals given the constraints above, I'll be glad to read about it :-)
Thanks in advance, and apologies for being such a stackoverflow "leecher" by subscribing only to ask a question, but I don't have no direct internet access on my workstation (yeah, for real, I have to go to a specific computer for this), so participating in this great community is not that easy for me.
Finally, here is my sample code (designer code available if you ask) :
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
Point _myLoc;
private void formToolStripMenuItem_Click(object sender, EventArgs e)
{
var ctrl = new PropertyGrid();
var obj = this.panel1;
ctrl.SelectedObject = obj;
var form = new Form();
ctrl.Dock = DockStyle.Fill;
form.Controls.Add(ctrl);
form.Opacity = 0.7;
var rect = obj.RectangleToScreen(obj.DisplayRectangle);
form.StartPosition = FormStartPosition.Manual;
form.Location = new Point(rect.Left + 10, rect.Top + 10);
var parentForm = this;
_myLoc = parentForm.Location;
form.FormBorderStyle = FormBorderStyle.None;
parentForm.LocationChanged += (s, ee) => {
int deltaX = parentForm.Location.X - _myLoc.X;
int deltaY = parentForm.Location.Y - _myLoc.Y;
var loc = form.Location;
form.Location = new Point(loc.X + deltaX, loc.Y + deltaY);
_myLoc = parentForm.Location;
};
form.Show(this.panel1);
}
}
Clipping can be easily implemented using Region property. Each window can have an associated Region object, which defines window rendering constraints:
static void ManualClipping(Control clipRegionSource, Form formToClip)
{
var rect = clipRegionSource.DisplayRectangle;
rect = clipRegionSource.RectangleToScreen(rect);
rect = formToClip.RectangleToClient(rect);
rect = Rectangle.Intersect(rect, formToClip.ClientRectangle);
if(rect == formToClip.ClientRectangle)
{
formToClip.Region = null;
}
else
{
formToClip.Region = new Region(rect);
}
}
usage:
/* ... */
parentForm.SizeChanged += (s, ee) => ManualClipping(panel1, form);
form.Show(this.panel1);
I have a very simple WPF user control that is mixed in with a windows forms app. It has a list box that renders its scroll bar without the thumb (image below). I narrowed it down to a plugin in my app that uses Managed DirectX (MDX). If I remove the plugin, the scroll bar is just fine. I know MDX is deprecated, but I don't think today is the day to consider an upgrade. Has anyone ever seen their scroll bar get messed up, or has any idea what I should do?
And I should add, that this control also lives in a plugin. There is no way for the 2 plugins to reference each other.
<UserControl x:Class="MAAD.Plugins.Experiment.Visual.TestEditor"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Height="403" Width="377">
<ListBox Margin="12" Name="listBox1" />
</UserControl>
Update: You can read about the solution below.
As it turns out, I stumbled on the solution today while working with a client. If you add the CreateFlags.FpuPreserve flag to your device creation, the scrollbar should go back to normal.
I've seen this bug too. It is not a SlimDX issue per se, but rather due to DirectX using 32-bit math on the x87 FP stack.
Use the FpuPreserve flag when initializing your device and the problem should go away.
My suggestion is to get rid of your MDX plugin.
I've used both WPF and MDX, though not in the same project. Both libraries talk to DirectX and ultimately will store state at the native level, which can cause problems. With WPF I've had rendering issues related to my video drivers and the fix was to upgrade the video driver to a newer version.
Initializing DirectX can affect the ways DirectX (and your CPU!) performs for your whole application . For example, when you initialize MDX by default it will set the CPU to do all floating point calculations in single precision, for the whole process, regardless of how you declare your original value. As you might imagine this lead to a lot of head scratching for a long time as to why we were getting different results in the application and our unit tests.
I suspect that when MDX is initializing it is enabling, or disabling some feature or setting in your graphics card (or possibly some software setting) that is affecting the WPF pipeline somehow.
I wish I could be more helpful. Good Luck.
I had this problem as well. As mpg found, adding the D3DCREATE_FPU_PRESERVE flag to the device creation will fix it. if anyone is wondering what the code looks like:
d3d->CreateDevice(
D3DADAPTER_DEFAULT,
D3DDEVTYPE_HAL,
(HWND)this->Handle.ToPointer(),
D3DCREATE_HARDWARE_VERTEXPROCESSING|D3DCREATE_FPU_PRESERVE,
&d3dpp,
p);
Have you tried SlimDX instead of MDX? SlimDX is a newer wrapper around DX and is actively under development. Perhaps you could do in SlimDX the same thing you use your MDX-Plugin for and the scrollbar functions normally again.
Peter is right about the interaction of WPF and MDX. WPF uses DirectX internally. So changing settings in MDX (or SlimDX) can change how WPF behaves. You could also try to take a look at the code of the WPF scrollbar (for example with the .NET Reflector, IDA, whatever you need) and check the settings the Scrollbar relies on.
Are you on Vista? We've seen a lot of SlimDX/WPF simply vanish by creating a Direct3D9Ex device instead of a normal one when running under Vista targets.
I took everyone's advice and ported my app to SlimDX. It wasn't too bad (almost every class/method/field is named exactly the same in SlimDX as MDX). Unfortunately, I still had the same issue. I was able to simplify Both SlimDX and MDX down to the following app:
public partial class MainForm : Form
{
Direct3D Direct3D = new Direct3D();
Panel slimPanel = new Panel();
public MainForm()
{
InitializeComponent();
CreateDevice();
BuildWindows();
}
void BuildWindows()
{
var listBox = new System.Windows.Controls.ListBox();
listBox.ItemsSource = Enumerable.Range(0, 100);
var elementHost = new ElementHost();
elementHost.Child = listBox;
elementHost.Dock = DockStyle.Fill;
Controls.Add(elementHost);
slimPanel.Dock = DockStyle.Left;
Controls.Add(slimPanel);
}
void CreateDevice()
{
PresentParameters presentParams = new PresentParameters();
presentParams.BackBufferHeight = slimPanel.ClientRectangle.Height;
presentParams.BackBufferWidth = slimPanel.ClientRectangle.Width;
presentParams.DeviceWindowHandle = slimPanel.Handle;
var device = new Device(Direct3D, 0, DeviceType.Hardware, slimPanel.Handle, CreateFlags.HardwareVertexProcessing, presentParams);
}
}
The scroll bar won't show. I was able to get the scrollbar to show if I made sure the listbox got to paint before the Device was created.
The final solution was to add a WPF ListBox to my form in the constructor then delete it after the form finishes loading. I'm not sure if this is a bug in WPF or DirectX, I might try submitting a bug with Microsoft.
BTW, I can't get XNA to cause this issue.
I'd second the reservations of the previous posters regarding MDX in the context of WPF. One shot into the dark though:
Have you tried targeting your control for .NET Framework 3.5 SP1 already? There has been significant work regarding DirectX/Direct3D interoperability and performance, see for example:
Paragraph 'Graphics Enhancements' in What's New in .NET Framework 3.5 Service Pack 1
Paragraph 'WPF Interoperability with Direct3D' in What's New in .NET Framework 3.5 Service Pack 1
Some of those enhancements might eventually yield positive side effects regarding your problem.