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).
Related
I'm developing the custom UI layout system for our custom SBO forms. I.e. catching form's resize event and arranging the controls according to our specific layout logic. The problem is that, apparently, SBO tries to arrange controls according to its (clunky and primitive) logic on every form resize first! My code handling the resize event and rearranging the items works, but there is a noticeable performance delay, as items are essentially re-positioned twice on each form resize - once by SBO itself, and then by my code.
Is there any way to stop SBO arranging controls on our custom forms during resize, so that they will be positioned only once by my code (in the resize event handler)?
This page by Boyum IT helps to explain what the resizing rules are.
There's additional information on this page
To summarize those pages, every form is split into 4 quadrants, which are effectively pinned to the corners of the form that they belong to.
That means that as you resize the form, these quadrants separate from each other, leaving large sections of space between them.
I don't believe that there's an easy way to prevent this behavior out of the box, but you can manually override it using the B1 UI API, by setting the LinkTo property of the Items to match the ID of one of the Items in the top left quadrant, which causes the given item to move with the same behavior as that of the item specified in LinkTo.
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.
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.
In the layout I'm writing, there's an area where a different control is shown, depending on various conditions.
Can I place all of these controls at design-time, or I must "re-attach" and "remove" each control at runtime?
You can host a panel inside a TableLayoutPanel cell. Or any other control container. In that you can put as many controls as you want.
For example, you could use a nested FlowLayoutPanel. So you may not need to manually perform layout management.
As I understand it, a Panel isn't meant to have any visible "chrome." The StackPanel, Grid and Canvas don't have any visible elements (with the exception of the gridlines, which they say are only for debugging layout.)
In my example, I am going to create a Custom Panel that uses Attached Properties to lay out its children controls. However, I want my Custom Panel to present a visible "grid" of sorts in the background. The look of the grid (sizing and positioning) will depend on the size and position of the child elements.
What are some of the ways to achieve this? Being very new to Silverlight and XAML in general, my first guess was to create a Custom Control which includes my custom panel for layout.
I think I'll be able to figure out the specific code, but I need to be pointed in the right direction in terms of what building blocks are appropriate for this scenario.
You are correct that custom Panels cannot show any extra chrome; they can only display their Children (Grid being an exception).
To do what you want to do, you could create a custom Panel which just adds extra Children to display the chrome. This would not be a good design though (since users of the Panel would see these extra items in the Children collection).
The best idea is to do what you said: create a custom Control that exposes a Children property. This control could internally use a private custom Panel to lay out these elements (e.g. TabControl uses a special TabPanel for laying out the tabs). In the Controls default template, you might want to use TemplateBinding on the Panels' Children property to your Control's Children property.
Panel can add Adorners to its children, read this article about adorners: http://msdn.microsoft.com/en-us/library/ms743737.aspx