I have an application that is full screen and has multiple panels and layouts which all works fine. However when testing it on another screen resolution things go wrong. So far I have been able to adjust everything based on the resolution width but the height has become an issue. I began scaling everything and realized I would have to re-adjust all of the fonts based on the new label sizes. There are quite a few labels and textboxes which is a lot of work to do everyone of them. I have been searching and found Windows WPF, but I've never used it and I really don't want to have to move everything over to it. I was wondering if there was an easier way to do this without starting over.
Related
More precisely, when I use certain display scales in Windows (those that don’t produce perfect 1:1 pixel layout. 150%, 175%, etc), the text doesn’t always redraw itself in the exact same position during every redraw. It is as if it dances a bit. However, if I scale the display perfectly (100% or 200%, for example) the effect is nonexistent.
Is there a fix for this? I spent so much time developing a custom text editor with Win2D’s CanvasControl being used draw the UI text, then discover this. I absolutely cannot continue development under these circumstances, as I am not aware of a better alternative to Win2D’s CanvasControl for presenting text for a custom text editor.
Any advice helps! Thanks!
UWP is optimized for high resolution. The unit used is effective pixels (epx). In different resolutions, the application will scale accordingly.
In order to apply consistent performance at various resolutions, there is a very important concept:
The sizes, margins, and positions of UI elements should always be in multiples of 4 epx in your UWP apps.
So you can check your app and resize text and controls to fit this principle.
See more in this document: Introduction to UWP app design
I am currently working in Windows Form Apps and am making what will essentially be a map editor for a game. The way i have gone about this is by having a central TabControl where each TabPage contains a custom PictureBox control and all the other UI controls are around this central TabControl. The PictureBox uses its Paint event to draw everything that is placed on the map, and therefore draws multiple images of many sizes, rotations and scales etc to the single PictureBox. This has all gone well so far. The TabPage is essentially used as a view window for the PictureBox and is of size (1280x720).
The problem is with the scale to which the maps are being produced. The avg (and also maximum) map size on screen is around 19200x10800px and can be made up of hundreds of items at any one point. When drawing just a backdrop image of size 19200x10800px the PictureBox starts to flicker when it redraws and makes the program unusable. As the map is so big you are able to pan around them and this is where the flickering really shows. Also i do not want to use a 19200x10800px image source if possible for the sake of file sizes and the scaled image quality isn't an issue at all.
I have done heaps of reading on why this might be and feel like I have tried everything up until this point. So far ive tried:
Having the background image only 1920x1080 and scaling it up by 10x
Starting with a 1920x1080 image, programatically resizing it and drawing this image
Slicing the background into multiple segments (i tried many different amounts) and drawing only the ones that the view window can see (tried this for both a small(1080p) and large(10800p) images)
Using graphics clipping so that only the things on screen would be drawn
Used Double Buffering on both the picturebox and the form that the picturebox is on
Converting the image at initialisation to an "optimised bitmap" with faster formatting and then drawing the bitmap
I've probably tried a couple other things along with minor optimisations but its taken me so long ive forgotten the rest. From what i've read its most likely something to do with the control redrawing too slowly for some sort of performance reason or a limitation with picturebox's, however exactly what is going on i cannot tell due to lack of experience with form apps controls.
Currently to draw the background in the Paint event i have either:
g.DrawImage(image, new Rectangle(0, 0, (int)(image.Size.Width * levelScale), (int)(image.Size.Height * levelScale)));
or
g.ScaleTransform(levelScale, levelScale);
g.DrawImage(image, new Rectangle(0, 0, (int)(image.Size.Width), (int)(image.Size.Height)));
Where g is the Graphics object.
Have I hit the limit of Win form apps capabilities or is there something i may be missing?
Any and all help appreciated,
Thanks in advance.
Just for formality I though id answer my own question just in case anyone else would like to know the outcome.
Based off the overwhelming consensus that winforms was just not made to do the things I was trying to do with it I decided I had to move to some other platform. Suggested to me was WPF, DirectX and OpenGL but after some extensive searching around I found what I think is the optimal solution.
In order to utilise the power of DirectX hardware acceleration MS has made it so that you can embed XNA graphics devices into a winforms application. Essentially you can create custom controls that run in the normal winform style that have access to a much higher caliber of graphics control. In this manner (with a bit of extra work) I have replaced the picturebox I was using with a custom graphics control which handles all of the drawing. This has worked very well, and on the up side i havent had to take too much of a hit to my development time.
For those looking for more info refer to this question which has further links that should help. Once again thanks to all those who gave their advice!
This is a quoted answer from the URL at the bottom. There are code examples at the link at the bottom. Hope this is helpful; not sure if you tried this yet and maybe it'll help you get a little more juice out of the existing picturebox control. As explain in the other answers, it sounds like you will be forced to a more powerful solution in the near future regardless (DirectX/OpenGL or WPF)
** Partial quote from http://social.msdn.microsoft.com/Forums/en-US/68ecd1f6-2eeb-45ce-a881-24c62145ab0e/c-picturebox-problems
"I'd guess the real problem is that it takes too long to redraw the images. GDI+ is pretty slow, it doesn't use any video hardware acceleration. To speed it up, be sure to avoid rescaling the drawing and to use the Format32PArgb format. It is about 10 times faster than any other format. Load the images into a Bitmap with the right format first."
If you have a LOT of items (Maybe realized as controls), forget about the standard event mechanism of Windows Forms. Some time ago, i've written a logic gate editor/simulator which supported lots of thousands of gates in the editor and was really fast. There, I've used the canvas and draw the gates as custom "images" instead of putting them as controls. You'll have to write a custom GetUnderlyingGate function which resolves the current gate / tile (Is your editor a tilemap editor?) from a coordinate array. Also, there were some visible area optimizations.
Maybe, when i'm back home, I'll upload some sourcecode and notify you.
We have a bunch of forms with alot of PictureBoxes on them. They're basically a representation of an engineering system with pipes connected to pumps and whatever. Each element is it's own picturebox, so there's a few hundred.
The problem we have is that when we take the app to a large 40"+ TV, there's too much space everywhere and it doesn't look the way it does on the developer's screen. So we designed it for these large TV's but when we look at it on a normal computer screen it's all wrong.
So how do we design the form with pictureboxes for the actual images to resize and reposition the controls relative to the size of the resolution it's being viewed on? If we simply anchor everything then the image sizes themselves are not relative to the display it's seen on.
Much appreciated!
In a Winforms solution you will have to do at least some of the resize calculations if anchoring and docking do not provide you with the required results.
If it is really important to you to be able to design the UI in Visual Studio I recommend writing custom controls that expose the desired resize properties and resize behavior and perhaps even a custom designer to support the design time features.
It might not be feasible but you could consider having a look at WPF, it has a ViewBox control that might simply be the answer to your needs.
I have a C# application that has an existing WinForm that I now need to display upside down.
The application will be displayed on a touchscreen Windows 7 device. If two people are using the device, one person is viewing it right-side-up while another user will be simultaneously viewing it upside-down. I will need to have one control displayed right-side-up while another control is displayed upside-down, each duplicate forms. Both need to be functional. It is not necessary for the title bar and Windows close, maximize, and minimize to be rotated.
Is there a way to easily rotate this Form and all of its contents without having to rewrite it from scratch?
Unfortunately, rotating controls is not directly possible in WinForms.
At least, not if you want them to retain their functionality. It would be relatively simple to draw the control into a bitmap, rotate the bitmap, and then draw that back to the desired location on the form. But you would obviously lose the ability to interact with the controls. They would just be static representatives of their original selves.
But making functional upside-down controls just isn't going to happen. I mean, you could try to write a bunch of custom drawing code for owner-drawn controls, but you'll still run into a bunch of bugs, corner cases, and compatibility problems. The Win32 controls that WinForms is based on just don't support this. No big surprise, really, considering they were invented some 20–25 years before anyone thought of computer screens that you could carry around in your pocket and rotate in any direction. There is a good reason that UI technologies like WPF came out around the time that touch screens and tablets did.
There are some possibilities that can be explored when it comes to flipping the entire screen, but that's not going to help when you want different controls going different directions. (And I guess it betrays my vantage point as a desktop app guy when I say this, but that just sounds like an incredibly confusing UI.)
If you absolutely have to have this, someone else is going to have to give you another route to hack it, perhaps along the lines of Dhawalk's comment: hosting the WinForms control inside of a WPF app that does provide built-in support for rotated controls. I don't know enough about this to make any concrete suggestions down that path. From a few minutes of searching, it appears that WindowsFormsHost does not actually support rotation transforms, so this may be a non-starter anyway.
I have a C# Windows application (i.e. not a web app) in Visual Studio. The original development environment was a Dell Latitude D800 with a 1920x1200 pixel screen. Since the large number of pixels made the text very small, I adjusted lots of different default fonts in the name of readability.
I have moved development to new laptop, a Latitude D630 with 1440x900 display. The app was moved by creating a new project on the new machine, and adding the existing objects/files/etc.
THE PROBLEM is that many of my forms are no longer displaying uniformly. Some are now too large so that items on the right are out of the frame, and others are smaller with excess space on the right of the frame. It is as if the value of a 'pixel' is now different from one form to another. These changes persist when the executable is installed on production machines.
Any idea on what happened, and how to restore order? Thanks.
A good bet would be to check your font DPI setting. By default its set to 96. Its part of your windows display settings.
As best I understand, that would not explain why some forms are affected differently from others.
Winforms contains a lot of technology designed around the problem of making the display of forms reasonably resolution-independent. But a lot of this technology requires you to understand and use it - anchoring, docking, layout panels, and automatic scaling, for instance. If you've misapplied these properties, you often don't know about it until the day that you first test your app at a different resolution.
Unfortunately, there isn't really a magic bullet answer to the question "why are my forms screwed up?" Your forms are screwed up because resolution-independence wasn't designed into them. There's a whole host of possible problems: you could have controls anchored to the wrong things, someone could have "fixed" a layout problem by overriding automatic scaling on a control, really, it's endless.
Often, the best way to fix this kind of problem in a legacy app is to slowly build up a prototype duplicate of the offending form in a test application and watch its behavior when you resize it and change your screen resolution. That'll help you identify how the form should originally have been designed; you can then take what you've learned back to the original form and fix it.
And then design this into your development process from the beginning. One of the reasons that I don't have these problems in the big UI-intensive desktop app I'm building is that I've made every form in the program resizable, and I resize them during testing all the time to see if they're screwing up. I also test with different screen resolutions as a matter of course. These are the kinds of problems that are really hard to solve once they've become systemic; spotting them early keeps a lot of misery out of my life.
Some experimentation reveals that the declared size of a form apparently affects the size of objects in the scale (length and width units per screen inch) of the form when displayed as a maximized MDI child.
I have no idea why it should affect that.