Floating controls in dynamic width container in XAML - c#

I am new to XAML and is trying to at runtime add a dynamic number of buttons to a container which scales with the current window width and height.
The buttons should be centered and placed beside each other and if there are not enough space on one line, the button which is too wide is moved above the other buttons and so on, resulting in a "floating" behavior as known from HTML.
If there are enough buttons to scale the containers height larger than the window it should be possible to scroll in the container, this part i dont think is a problem but the "float" behavior i cannot figure out how to do.
I have tried with the available panels but none seem to suit this purpose and i am thinking about creating a custom control which positions child controls in the way i want, but there must be some way this can be achived using standard controls?
I am developing this in UWP as an universal app for both desktop and mobile.
Thanks for any input to my problem :)

Maybe you could achieve what you want with a combination of a RelativePanel and a couple of VisualStates and visual state triggers such as AdaptiveTrigger or some from the WindowsStateTriggers library. With these you could define different visual states, each representing a different layout of buttons and define triggers that apply these states based on some conditions (most likely based on the size of your container). There's a very good example of this approach described in this blog post.

Related

What are the point in layouts/panels?

I have just started getting into learning WPF, and to add controls to the window I just move them from the toolbox and onto the window. Then I can continue moving them to put them in the places I want. Now I have got into layouts/panels, stack panels, canvas,dock panels etc and I am struggling to understand why they are useful if you can just drag and move objects/controls on the screen yourself.
For example dock panels, using the dock property you can put the object on the left,right,bottom,top,lastchildfill. You can dock a textbox to the left by using the property, DockPanel.Dock = "Left", but why can't I just move it there myself?
First off, don't even waste time drag/dropping controls into a WPF app. By placing controls in this manner, you are severely limiting your design potential in WPF. Most serious WPF designers don't even bother dragging controls, they hand type all of the XAML. Arguably, this is how WPF was designed. Leveraging XAML allows your layouts to be totally dynamic in ways that WinForms could never dream of, but you have to hand code the XAML.
Do you see where this is going? Don't drag/drop controls when designing WPF apps! Every conference I've been to stresses this fact! Grid panels are a huge part of WPF layouts, and are crucial to getting your controls to end up where you expect.
The hardest part about learning WPF is figuring out it is not WinForms with nice graphics. It is a totally different beast, with a steep learning curve! Hand coding XAML is extremely tedious at first, but once you learn the names of all the controls and the important properties, you'll be cranking out UIs way faster than the old drag/drop method.
You can move the controls manually, but different layout panels can automatically handle controls positioning when You add new controls or when the window is resized.
Please take a look at description on MSDN and on CodeProject that describes different types of containers.

Adjust your boxes based on windows size in c#

I have been working on a project in c# and I have the starting box size pretty small around, 700px by 450px.
Everything looks great on that size but when I maximize it, all the forms and etc stay the same size and just stick to the corner of the window.
I am curious if there is a way to get the boxes to adjust accordingly to the size of the actual windows form so if they click on the maximize button it doesn't look weird.
I have looked quite a bit online and everything I have tried doesn't seem to work. Also I am using visual studio 2013.
Thanks for the help!
I'm not sure I 100% understand what's going on, and please excuse me if I'm just saying things you already know, but controls inside of forms can be anchored. This helps because--for instance-- if a control is anchored on all sides then no matter how the form they reside in is resized they will grow with it.
The anchor property is in the property window.
As far as forms inside of forms that you would just have to grab the size property of the mdi window and grow the child forms based on this.
You could use the resize event in mdi form to fire off an interface method that all of your child forms implement maybe?
Learn how to use the Anchor or Dock properties to position and size controls relative to their container in WinForms

WPF layout changes (Fill, Full, Snapped)

I am working on a Win8 app destined for the Windows Store. Hurdles I am trying to overcome is how to deal with the different ways an app can be displayed.
Currently, my main pages is a LayoutAwarePage so it has logic to handle different visual states. However, my question is more how to make my page render differently depending on its state.
I thought, initially, that you basically created a layout for each state that the application supports. But it seems like the VisualStateManager portion of the XAML is just an area where you make piecemeal modifications to the design (hide an element, change an alignment).
I am working with a grid that has many columns and rows to organize my controls and it looks great in fullscreen. However, this doesn't work at all in the snapped state, as most of my controls become hidden off screen. I could certainly add a ScrollViewer control, but this is basically a hack and a usability nightmare for a user.
Thanks for any insight!
It might be that your app doesn't lend itself to snapped view. You are allowed to simply display a message / image that states this. Alternatively, consider just showing the columns that are most important.
The standard MS way seems to be to replace horizontal oriented controls with vertical ones - maybe a listview or something would look better. You'll probably find your code easier to read if you have one control for snapped and another for full screen.
Not exactly related to your question, but Blend works very well with XAML to allow you to manipulate the grid or show the relevant control.
Here is a very good guide from Jerry Nixon.
http://blog.jerrynixon.com/2012/12/walkthrough-implementing-snapview-in.html

Windows 8 native custom control

I want to make a custom control with the Windows 8 API in C# so that it will run on an RT app distributed through the store.
I looked through what I can add to a project and found Templated Control and User Control. Both allow me to organize other controls and some logic into a new control for reusability.
But this isn't what I want. I want to be able to custom paint and create controls. I would be shocked if they removed this but am honestly uncertain if I can. I'm basically looking for what class to inherit from and what method / event to override to let me draw the control myself.
I found a way to use the Templated Control option that I wasn't aware of before. Essentially my custom control has a canvas that I 'paint' with objects (lines, images, etc.) by adding them as children and manipulating them in events.
This tutorial helped me figure out what I was doing.
I've seen other people say they created a rectangle and painted it with a special Brush, either a ImageBrush (where they drew an image in the background) or a DrawingBrush.
Hopefully one of these two approaches can help anyone looking for the same thing I was.

How can I create a button with an embedded close button

I am trying to create a panel which will have a set of "buttons" on it.
These buttons should have the following behaviour:
Appear similar to a tag (with
rounded edges)
Contain a red
cross to remove the filter/tag from
the panel, similar to the way internet
explorer tabs have an embedded cross to close the individual tab.
allow the user to click
on the tag and respond like a normal
button (as long as the click is not
in the red cross)
Number 1 is no problem, this is just appearance, however, regarding numbers 2 and 3, I am not sure if there is already code out there do to something similar...and I dont really want to reinvent the wheel if I can avoid it!
My question is: Does anyone know if there is something out there in infragistics which will do this simply, or will I need to write this myself by subclassing winform buttons?
Thanks in advance!
Is this new development or maintenance of an existing project?
If it is maintenance, you have a somewhat tougher time ahead. You'll implement a UserControl, probably segmented into two buttons. Use docking to get the behavior as correct as possible. The far right button would contain your cross image; the left (which would need to auto-expand as you resize the control) would contain your primary button behavior. Play with the visual styles until you get them right (EG, removing borders, etc).
If this is new development, and you haven't gotten too far into it, you might consider using Windows Presentation Framework (WPF) instead of WinForms. It will be easier to build the control and get it to look exactly how you want it. WPF includes an extremely powerful control compositing system which allows you to layer multiple controls on top of each other and have them work exactly as you'd expect, and it carries the added advantage of allowing full visual control out-of-the-box.
Either way, this is more work than dropping in an external component ... I've used Infragistics for years, and I can't think of anything they have which is comparable. The closest, but only if you're building an MDI application and these controls are for window navigation, is the Tabbed MDI window management tools -- and there, only the tabs (which replace window title bars) have this behavior.
I don't think that infragistics can do something like this. The UltraButton control can't.
Implementing a own control wouldn't be that hard.
your probably going to have to make a costume control for this type of work.

Categories