This question already has answers here:
How to make the UI responsive in Winforms [closed]
(2 answers)
Closed 4 years ago.
We have developed POS system using windows application ,but there is a requirement to make it responsive ,which is not possible.
We have tried to use Flow panel but 100% responsive not done.
we have another option to convert it into WPF but it will require more time.
any one have suggestion to make windows form application which adjust according to screen resolution.
You can evaluate TableLayoutPanel and ensure that columns and rows are defined as percentage instead of absolute values. You would also need to work out docking and anchoring for individual controls.
If you are looking for layout to switch from, say, horizontal to vertical, then you will need to work with resizing event of the form.
Pretty much, you can't make a WinForms app respond well to different resolutions: it's possible, but it's a heavy amount of work and probably won't be too wonderful when you are finished.
The problem is that although all controls can be Anchored and Docked so they resize automatically, that doesn't have any effect on text within the controls: so you end up with a large button with tiny unreadable text in the middle, or a tiny button with huge unreadable text in the middle.
While it's possible to get round this by handling the Resize event for each control and working out what font size to use based on the new display area, that's not trivial and generally takes a fair amount of trial and error, plus the odd "fudge factor" thrown in to deal with strange cases.
You can do it, but it's serious work - WPF handles it a lot better!
The other solution is to redesign your UI to work well at multiple resolutions in the same way tat Visual Studio does: a central "work space" with all the tools in panels which float or dock round the edges. But for a POS system, that probably isn't practical!
Related
What I need can probably be described as "reverse-anchor", "reverse-dock" or something like that (I have chosen to mention this just because "reverse-anchor" happened to be the first thing to come into my mind as a keyword candidate when searching for questions and answers that might already have been submitted discussing this subject, perhaps this will help people thinking a similar way to find this one in future). WinForms controls implement the Anchor property to set up adaptive resizing on containing control/form size change but I need the opposite - the form to resize adaptively to the controls.
A thing adding a minor bit of complexity to the task is that the controls meant to be added/removed/shown/hidden/enabled/disabled (and resized perhaps - this functionality is not really needed directly so far but I suspect it can turn to be required for compatibility with non-default Windows visual styles and themes that have potential to affect controls sizes unpredictably and can change at any moment of the app running) are not going to be the last ones on the form - a row of buttons will always be in between of the last control of the volatile group and the window lower border.
The actual task is to design a form that will display a collection of objects with a row of controls (a label, a text box and 0-2 buttons) corresponding each of them and it is strongly preferable to use just the very basic "common controls" avoiding grids, lists and stuff like that in this case (wrapping them in an additional container controls like panels is perfectly acceptable though, abstracting them in a separate "user control" can be considered too if this can really make the solution easier, more reliable or otherwise better, using hand-written code manipulating controls and form sizes is perfectly acceptable too (I can hardly expect a "set a magic property and it's done" kind of solution to exist for this task) but I haven't found a reliable algorithm so far (when to change what properties and what formulae to calculate new values with)).
The maximum capacity can be safely limited to something near 10 (or 20, perhaps, but not more - more would be just absolutely unreasonable to display on one form (provided scrolling is not an option)) so both ways are acceptable: to add/remove the controls in runtime or to put them on the form in the designer and just manipulate Visible and/or Enabled properties in the code. By the way I have found a problem with Visible - it gets switched off and back on by the framework internals before the form is rendered and other controls Anchor properties come in the game but I don't think it's a good idea to rely on this to happen always and the same way so just adjusting the form Size property on a control Visible property change does not feel really convenient).
What might be some good ideas relevant to implementing this behaviour?
PS: As far as I know this is a natural feature of WPF but I am to use WinForms to make the app runnable on Macs and, perhaps, other non-Windows platforms with help of Mono.
I'll tell you about some clues may help you:
1- correct to build your own Procedure for manipulating all the matter.
2- i advice to use a Wizard methodology (Next / Back buttons) so if the plate form is small like tablet or smart phone, so the mentioned procedure will decide how many Controls combinations (Label, text box, option button...) will be in each frame of that wizard and keep the remaining for Next button.
3- By the way if you will hide some controls use the original event fires to run the mentioned Procedure. (like a basic button to start the form so don't depend on visible / resize events).
4- Resize the size of each form of the wizard in the last part of the mentioned procedure.
If still a problem exists tell me and i hope i can help :-)
This is only an issue if you have Drop Shadows turned off in appearance settings.
I noticed some of our applications form windows had no borders. Specifically they have been missing the 1 pixel thick border for the left part, right part and bottom part of the form window. All of the forms had in common that they were using FormBorderStyle FixedToolWindow or SizableToolWindow. When it is like this it is hard to distinguish where one dialog stop and another one begins.
We find it plausible that some of our users will have their computers set up like this without the ability to change it.
Is there a way to get the dialog windows looking better without doing anything crazy like manually drawing all borders?
Quoting part of a comment by Hans Passant:
By design for Win10, the left/bottom/right borders are transparent. Still quite visible against the large drop-shadow, so visible that is hard to tell that the border is transparent...
Our application has its own grahpical style that made it especially hard to distinguish where one dialog stops and the other one begins.
The quick solution for us was to stop using FormBorderStyle FixedToolWindow or SizableToolWindow.
Long term we are going trough all our dialogs and the graphical style of our application to make the dialogs more easily distinguishable from each other with or without borders.
This question already has answers here:
.Net controls changing size between computers
(3 answers)
Closed 9 years ago.
First time i'm developing a Windows Form Application with C# . I'm using Visual Studio 2012.
My form's size = 1096x508. Also i set Minimum Size and Maximum Size properties to 1096x508 .
This is screenshot of my app ,
But when i execute this app on another computer, result like this :
As you see, red line (at bottom of app) invisible. Because applciation's height is 508 px (as expected) on my pc but 416px on other computer. Because of this , red line staying out of Form. So we couldn't see it.
In shortly, my Form's size 1096x508px but it's only 823x416px on another computer. Can you tell me why there are difference? And how can i fix this? There are resolution difference between this screens.
The behaviour of your application on those computers may be caused by different dpi (dot-per-inch) settings of the Windows operating system. In order to check that please compare the actuals values in Windows display settings (100%, 125%, ...).
If you want to have your program independent from dpi settings you may try to work with different panels (control containers). Your status bar could have a fixed with, while the game area is a docked panel (filling the remaining space).
In general, staying independent from actual dpi, is a difficult topic. Most of the time you can work with autosizing controls, but you could run out of space if, say, two labels overlay.
The main issue, as you have already discovered, is that computers with a different DPI setting will cause the controls to scale.
What Hans was suggesting in his linked answer is that you need to re-design your form so when it gets re-size messages it will handle them accordingly.
The main way this is normally handled is setting the Anchor property or the Dock property of a control. By default a control will anchor to the top left corner of it's parent container. When it is told to scale it scales down and to the right. By changing the anchor point to be the bottom only it will make your bottom control move up instead of moving down off of the boundaries of the parent.
I have a Windows Form with 9 identical user controls that are directly adjacent to one another. On my screen the form looks fine, but when running a coworkers machine, the window gets resized and the user controls overlap. Does anyone know how i can prevent them from overlapping? I don't mind that the window is resizing on different machines, I just don't want any lost information or partially hidden elements.
Thank you in advance.
You could use a FlowLayoutPanel. It won't work in every situation, depending on what kind of controls you intend to place inside it. I'm not sure what your user control look like, but I just added a FlowLayoutPanel and added about a dozen buttons inside it, and it takes care of
adjusting the layout for me when the end-user resizes the form, maintaining padding around each button and avoiding overlapping.
If your user controls can flow around each other, and it doesn't matter if they are side by side or one over the other, you may want to check this out.
I'm building a control that comprises 15x15 = 225 buttons, and needs to be resizable. Because it's a grid, anchoring and docking won't work. I've tried both TableLayoutPanel as well as handling the resize event to manually place and size controls. In both cases, resizing is unacceptably slow. Suspend/Resume Layout in the resize function when I'm manually handling the layout doesn't help.
Is there something fundamental that I can change to speed things up, or is this just a limitation of the native controls? I understand I can build a custom control from scratch, handling the clicks and painting myself -- though I'd prefer to stick with the native controls if possible.
Edit
I know it's a lot of buttons. My question is a technical one; not one about UI design.
WinForms doesn't handle displaying this many controls at the same time unfortunately.
If I were in your situation I would first consider if I could split up the form in several pages. In many cases that would be easier to understand for the user as well.
But in your case that doesn't seem to be an option. Are you making something like a minesweeper style game? There you have a grid of buttons that all are clickable. In such a situation I would suggest you go for a custom owner drawn control where you consolidate all the buttons in one control. Don't build a composite control that contains 225 buttons - that won't help at all :-)
A final option could be to switch to WPF. WPF uses hardware accelerated rendering so it may be faster, but with so many controls not even that may help.