I am developing a C# WPF application utilizing MVVM pattern
In my app user via mouse (or touchscreen) sets offset values for the Pan-Tilt Motor. Since movement should be somwhat percise, I decided to create a UI helper element, which currently looks like this:
I want it to look nice and dandy, so that values wont be obscured or intersected with other lines:
But at the same time I want to stick to MVVM pattern, and such behaviour, although not hard to implement per se, requires a lot of bindings, logic and triggers. That clutters my XAML and View Model a lot, so here comes my question:
What is the common way/best practice of encapsulating such element (which is basically a complex dynamic figure) into some abstract form, hiding all irrelevant to the main app logic within it?
The desired solution wold look something like this:
<canvas>
<i:Interaction.Triggers>
<!--MouseUp, MouseDown, MouseMove Commands...-->
</i:Interaction.Triggers>
<i:Interaction.Behaviors>
<!--Getting Mouse X and Y values...-->
</i:Interaction.Behaviors>
<MouseUI MouseUiClass="{Binding MouseUiClass}"/>
or
<MouseUI Start="{Binding MouseUiClass.Start}"
End="{Binding MouseUiClass.End}"
IsFinished="{Binding MouseUiClass.IsFinished}"/>
</canvas>
I did consider to use UserControl but I struggle to understand how to properly display it because dynamically resizes, and start and end point can be placed in any part of canvas.
Related
My app has a bunch of paragraphs which are compared together. This is implemented using a generic ItemsRepeater that creates as many Grid elements as there are paragraphs. Inside each grid is a TextBlock with the paragraph number, and a RichTextBlock that contains the paragraph. The hierarchy is therefore like this:
<ItemsRepeater>
<Grid>
<TextBlock />
<RichTextBlock></RichTextBlock/>
</Grid>
<Grid>
...
</Grid>
<Grid>
...
</Grid>
</ItemsRepeater>
This results in a text selection as follows:
Only one RichTextBlock can be selected at a time. However, I would like to allow text selection of all paragraphs of the ItemsRepeater. How is that possible?
Edit
I'm open to other approaches. I've tried manually filling in a StackPanel or RichTextBlock with items. That's not a problem. However, because the numbered paragraphs need to align, I need to be able to set their height to match each other. From what I can find, only elements that derive from FrameworkElement have the ActualHeight and Height properties I need for that. However, FrameworkElements like TextBlock and RichTextBlock also do not allow multiple selection, which is the problem I'm trying to solve in the first place. Someone posted a response to a similar question about WPF, but it uses a strange solution I don't think applies.
So the question could also be framed as: how is it possible to find and set the height of a Run within a TextBlock or RichTextBlock? Using that idea, it was impossible to get/set the run height inside a paragraph. I'm not bound to using ItemsRepeater, but that has also not yielded a useful result. I'm seeking to avoid resorting to HTML/Javascript for this.
UWP does not expose enough APIs for you to do that. I have worked on a similar issue with RichEditBox on UWP and there is no good solution that I have found. But if you really want to, there are two main approaches to achieve that:
Implementing the selection yourself by sniffing the mouse events and render the selection on top of the controls. There are so many corner cases, specially if you want to have a proper accessibility tree for the control that you are building.
Alternatively, you can create a WinRT C++ project where you would have access to more APIs, build a control and render it onto a canvas that is created with your C#/Xaml app.
The good news is that you are not permitting people to edit (RichTextEdit) and it is just view (RichTextBlock) so you do not have to worry about the automatic corrections, IME, Url detection, etc.
Edit: Originally I mentioned WinRT C++, but I meant C++/CX. It might work with WinRT too, but I have not tried.
I was assigned a very obscure project where basically every control, every design element is an image. I was provided with design files for every element of the app.
I even informed the people who gave the assignment that it's probably a very bad idea due to many different reasons, and it would be better to do everything manually but I still have to do it with images. Every time I add something - I see that everything is fine in the designer , but when I run it on my Lumia 925 everything shifts a little bit in different directions, even the buttons.
Any suggestions on the proper way to do this? To have custom templates for buttons which are basically images in a way it will not shift and I would see the same thing in the designer and on the device.
You have a great solution for controls called Behaviors, just add the extension in the project and add the following everywhere you need a Tap like the following, (that's an example just for tap you could use the event tap):
xmlns:Interactivity="using:Microsoft.Xaml.Interactivity"
xmlns:core="using:Microsoft.Xaml.Interactions.Core"
<Image>
<Interactivity:Interaction.Behaviors>
<core:EventTriggerBehavior EventName="Tapped">
<core:CallMethodAction .../>
</core:EventTriggerBehavior>
...
</Interactivity:Interaction.Behaviors>
You have all the behaviors and actions here:
https://msdn.microsoft.com/en-us/library/microsoft.xaml.interactions.core.aspx
and how to add them in the project here:
http://blogs.windows.com/buildingapps/2014/07/22/tips-and-tricks-for-using-xaml-controls-in-your-universal-windows-apps/
Then add the logic in the methods you call from the images. There are plenty of behaviors done, to begin storyboards, to change properties...
Apart you can use a ViewBox control that it scales everything in the screen to not be scaling every image. Try that.
First, please forgive (and correct!) any misconceptions - I'm brand new to anything .NET.
Me and my team are building an application in Silverlight, using the MVVM pattern. Right now, we a viewmodel for an object with various properties (e.g. its background color). The VM implements INotifyPropertyChanged so that when those properties are updated, listeners are notified.
The problem is that these are drag-and-drop objects on a canvas, and we want to run some logic every time the position on the canvas is changed. However, my understanding is that because Canvas.Left and Canvas.Top are attached properties I can't treat them the same way as I did the properties native to the object.
Is there any way to make these attached properties work with INotifyPropertyChanged? If not, what's the best way to react to changes in the Canvas.Left and Canvas.Top properties.
Thank you very much!
Two things:
(1) To keep with the MVVM pattern, I would suggest using style triggers for these attached properties and leave them out of your View Model altogether.
(2) Along those same lines, I wouldn't have your view models know about concepts like "background color" that are purely view concerns. If there is something in your business logic/VM that keys a view concern like color, you can use value converters to translate from what the view model knows about to what the view needs to do.
Im just starting out with wpf (in blend 4) and i would like to create an application that has a side menu for changing the content. What i am looking for is something like in word 2010 under the file menu. if you click the menu on the left side the content on the right side changes accordingly. i have read articles about nesting a page.xaml into a frame and change the frames navigation source to each page. Is this right? When i do that a navigation bar appears at the top. I can get rid of that easy but it seems like i am taking the wrong path at what i want to achieve.
Thanks in advance.
Just to chime in on this, both the TabControl and the Frame-based solutions are somewhat like the extremes of a spectrum. The tab control effects a very close coupling between the tab state and the displayed UI (e.g., you might find it difficult to change to a dialog for which there is no explicit tab item), whereas the frame enables relatively loose coupling, but might be overkill for this scenario, as it aims to support full-blown linear navigation with a history/page stack. (Prism, for example, offers a similar mechanism through its "regions" concept.)
A middle ground could be to have a main "window frame" UI with a placeholder element, and have your individual "pages" derive from UserControl, making them regular UI elements. To switch to a specific page in your UI, you would instantiate (through code or XAML resources) the corresponding user control, and set it as the Content property of the aforementioned placeholder element. (This is basically the same mechanism you mentioned for VB, where you hide/show subforms.)
So there's a range of options to choose from, depending on the actual constraints of your scenario.
The simplest code to do that is creating a TabControl with TabStripPlacement="Left". For example :
<TabControl TabStripPlacement="Left">
<TabItem Header="Tab1" />
<TabItem Header="Tab2" />
<TabItem Header="Tab3" />
</TabControl>
You can apply Styles to further change UI, colors and look & feel.
I'm a bit confused as to what a viewmodel's role is beyond databinding. I have a menu built in silverlight. The menu has x number of menu items which is determined at runtime. One of the features I would like to add to this is that each menuitem has a different text colour when hovered over.
Is it the role of the view to have a colour selector method or should the view handle this in it's code behind?
Normally I would keep the coloring/styling in XAML if possible - My view of the ViewModel is that it is responsible for providing all the data (ie. not graphical stuff) from the Model in a manner the View can consume.
If it was complex logic that determined the color and it was to be reused - I might be tempted to put it in the ViewModel tho.
The view model is used by the data binding process as a "safe" way to allow you to sort/filter/group the records as seen by a specific control without (necessarily) making changes to the actual bound data set (that is, unless/until you tell it to). (FMI read Bea's article here.)
I agree with Goblin here, in that the presentation aspects like color might be best kept separate in the XAML, for example in the DataTemplate used by that control.