I am working on a project with MDI forms. My problem is when I open an MDI child borderless form. For a moment I see this...
and then appears to be OK...
Any idea what can cause this?
Note that title bar and bottom bar is custom controls. FormBorderStyle is none!!!
Windows doesn't actually support changing the border style for MDI child windows. The operating system lets you do it, but it is an unsupported configuration and quite likely to be buggy.
WinForms is supposed to insulate you from these types of concerns, so this is really a design flaw. It should be throwing an exception when you try to modify the FormBorderStyle property of an MDI child. Implementing MDI support probably wasn't Microsoft's biggest priority. It was essentially dead even when WinForms was first released way back in 2001-ish. The entire MDI paradigm is no longer supported, and no longer recommended for use in software.
As you've seen, you can hack it so that it kind of works. But you get this flickering effect because Windows is trying to draw the non-client area that is supposed to be there.
Two better ideas:
Stop using the obsolete MDI paradigm and find a different, more user-friendly way to implement your UI. For example, separate, top-level forms. Or a series of tabs.
Stop using ugly custom "skins" that break with the operating system's standard visual appearance, cannot be customized or disabled by the user, and tend to be buggy.
If you absolutely have to do this, and want to make it look good, then you will essentially have to re-implement the MDI paradigm yourself. Create a standard form that will serve as your de-facto parent. Then, instead of using MDI child forms, you will use a series of UserControl classes (or a Form with its TopLevel property set to False). Then you can remove the system-drawn border, allowing you to draw everything yourself. The UserControl objects will then be displayed as children of the "main" form, just like any other control would be. So far, so good. Now, the ugly part is that you'll be responsible for managing these children yourself: showing them when necessary, hiding them when necessary, allowing the user to drag them around within the "main" form, logic for "maximizing" and "minimizing" them, etc. You'll have to write your own code to do that. I strongly recommend against it; getting this type of thing right is going to be rather difficult and of dubious value once you get finished.
Related
One could create a control by starting from a container control (like panel) and add other existing controls (like buttons, textbox, etc) on it. But in some cases, there are no such suitable primitive controls and one has to draw things from scratch.
Avalonia UI's Visual Studio extension has a UserControl template, and it seems that it allows adding existing controls using XAML, which is the former case of the previous paragraph. But how to draw from scratch? Where is WinForm's OnPaint() equivalent or WPF's OnRender() equivalent? Is there any example of creating a control from scratch in Avalonia UI?
or WPF's OnRender() equivalent
It's called Render, the name is pretty much the only difference, DrawingContext's API closely resembles WPF one.
I hear RelativePanel and SplitView are new layout controls for Windows 10. What is cool about the RelativePanel put as concisely as possible?
UWP is more focused on making a single app which will run on all the platforms. These panels are also called as Adaptive Panels. It has taken care of Adaptive UI very beautifully in app development.
RelativePanel is better than StackPanel to implement the desired layout for multiple screens using the same base code.
It has attached properties eg. RelativePanel.Below, RelativePanel.Above, RelativePanel.RightOf, RelativePanel.LeftOf which is very useful for making the different UI for different Device family using the same code.
RelativePanel is even more powerful when it is combined with VisualStateManager. You can see the example here.
MSDN has all the answers but here is a summary as concisely as
possible.
RelativePanel defines an area within which you can position and align
child objects in relation to each other or the parent panel. It is
essentially a layout container that is useful for creating UIs that
do not have a clear linear pattern; that is, layouts that are not
fundamentally stacked, wrapped, or tabular, where you might naturally
use a StackPanel or Grid. If your UI consists of multiple nested
panels, RelativePanel is a good option to consider.
Using RelativPanel's attached properties (such as
RelativePanel.Below, RelativePanel.Above, RelativePanel.RightOf,
etc), you can position a UI elment relative to another UI element as
well as relative to the panel (e.g.,
RelativePanel.AlignVerticalCenterWithPanel).
RelativePanel, used in conjunction with AdaptiveTriggers, can be a
powerful tool to create responsive UI that scales well across
different screen sizes. If you want to explore further on this, there
is a sample you can download and experiment with.
I just have it in my mind. And I can't explain it so here it goes.
A system that only uses 1 form?
It have a two panel, left and right.
The left is consist of buttons
Then the right is associated on the buttons and will change whether what button will be clicked.
Any ideas?
My preference is to do this via custom controls, rather than panels... but panels can work too.
There are a number of ways to do this:
Keep all of the controls layered on top of each other, and then set the Visible property to false for controls/panels you don't care about and to true for the Control/Panel that you do
Move the controls you don't care about out of the visible area
Remove/Add the Controls/Panels from Form's controls collection entirely
I think you can also get a TabControl to put the tabs along the left side, with some formatting that looks more like buttons, such that what you want will be handled without needing to write any code to switch layouts
Any of those can work. Whichever option you use, I have two recommendation for controlling layout and making the transitions smooth.
Call SuspendLayout() before making any changes, and then call ResumeLayout() when you're done. This will help avoid stuttering or a partially rendered form.
Look at the TableLayoutPanel Control. This control will allow you to arrange your top-level panels so that they can be resized with proportion. If you also then dock your individual panels, you can quickly build your program so that it resizes correctly.
You can have several panels, one on top of another. Change their visibility, depending on which one you need at a given moment.
Option #2 would be using a vertical tab control (or a tab strip - see another answer there).
I created a winform application. The size of each screen is 1361, 768 in pixels. This worked great for larger screens and/or laptops. But now I have to move my application to 10inch screen tablets, which means my application does not fit.
I have never had to deal with this issue before, how can auto adjust each form size and adjust all of the controls and panels when viewing on smaller screens?
I am using VS 2012.
Making forms fully scalable in WinForms is possible, but it takes a bit of work. The good news is that most of this work is done at design-time, arranging the controls properly so that everything is done for you automatically by the framework. It's drudgery, but it isn't difficult. Rejoice that you don't have to write the scaling code by hand, form-by-form, like you did with VB 6.
There are four fundamental properties that you will need to acquaint yourself with:
Anchor
Dock
Margin
Padding
The last two should be quite familiar web developers who know CSS—they do the same thing here. Padding controls the inner margin around a control, while margin controls the outer margin. You will need to set these correctly to ensure that your controls can "breathe", because the automatic scaling code is just going to jam them up against one another.
The "standard" margins around a control in a Windows desktop application are approximately 12–15 pixels. You should make sure that you leave at least this much room. Then add additional margins/padding as you see fit to separate things. I keep these layout specifications bookmarked for reference. This is another good reference.
The next step is to instruct the layout manager how you want the controls to be arranged and resized. The key to this is to think in terms of container controls and child controls. The form itself is a container control, and you can set its child controls to either Anchor or Dock within its boundaries. One or more of those child controls can itself be a container control, and its child controls can be Anchored or Docked within its borders. The nesting is virtually unlimited, but for your own sanity and reasonable redraw performance, you'll want to keep it to a reasonable minimum.
A good way of doing this is to use the two provided invisible layout helpers, FlowLayoutPanel and TableLayoutPanel. Personally, I don't find the former very useful very often, at least not for standard Windows applications. But the TableLayoutPanel is invaluable.
Generally what I will do is fill my entire form with a TableLayoutPanel (margins = 0, dock = fill). Then I will add individual controls (or sometimes another nested TableLayoutPanel) to its cells. Those child controls will have their margins set appropriately, and will have either their Anchor or Dock properties set, depending on whether I want that control to have a fixed size or resize dynamically.
Before you get the hang of how these properties interact and how it all works, you'll probably need to play around with your layout a bit. Make a backup of your forms and then just dig in. Or, you might find it easier to start designing each form from scratch (you can still copy-and-paste individual controls in order to preserve their other properties). Eventually, it will all start making sense to you, and you'll be up and going in a jiffy.
The great thing is, once this is all set up, all you have to do is ensure that your form is resizable. Then, whether the user manually resizes it or uses the maximize/restore button, it'll automatically fill their screen size. This also works well for all DPI settings, which is another common Achilles' heel of WinForms devs.
Try to get the resolutions variables to adjust your screens, there is an answer to get these variables using the Screen class
Getting Screen Resolution
DevExpress has a great control call the Layout Control. This control helps to maintain consistent whitespace between controls as the form is resized. It does take a little study to use the control effectively but once you understand how to use this control the results are consistent and you are able to speed through form design.
I have the following question:
The current project I'm working on is full of inherited controls, allowing us to tweak the behavior a bit in comparison to the default behavior. Now i created a sort of notification control (composed of an image an tooltip control) which I want to add to most of our control collection. This would allow usage of thise notification anywhere we need.
I tried dragging my own control to the design view of the inherited control and I pass on the properties that should be set on my own composed control.
Rendering however seems to be a problem. Since the original control is an inherited control, the size of that control can vary. My notification should be appearing behind the control:
[control][notification]
control being the inherited control, notification being my own control.
Is this possible on the inherited control? The only other option I see is making 2 versions of the control, one clean inherited and a composed one with both (in which case I would need to relay all databindings, which I don't want).