(I am trying to learn WPF using tutorials and documentation, and trying to develop a user interface for my backend-complete application while I do say. I've heard people say that the learning curve is quite steep. But sometimes I wonder whether what I'm trying to do is actually something that's hard to do in WPF, or if it's simple but I'm thinking in wrong terms, or if it's neither, it's quite simple but I just happen not to know how.)
Here's my current question. I wanted clicking that clicking some part of my UI will bring up a 'popup' where the user can enter more information. I would like a 'lightbox-style' popup, i.e. the popup is modal to the page, it darkens the rest of the page to become the center of attention, etc. These are seen commonly on Web sites.
A bit of searching led me to the WPF Popup control. I added it, put my content in, set the IsOpen property to True, and -- presto! A popup. Then I added an invisible Rectangle that covers my whole window, and set it to Visible as well when I want my popup to open. Great!
So now I wanted to do this dynamically, because sometimes I will be loading a record which will sometimes have a need to open another control (a UserControl) in a popup to edit its information. So I made myself a method called OpenPopup. But I can't seem to find a way to write this method using WPF. In Windows Forms I'd have written: (I use VB.NET)
Sub ShowPopup (form as Form, ctrl as Control)
'Create 'rect' as new dark rectangle control
'Z-order it to the top
'form.Controls.Add 'rect'
'form.Controls.Add ctrl
'Z-order 'ctrl' to the top
'Center 'ctrl'
'Set focus to it
End Sub
But with WPF I run into problems:
1) I can't add it to the WPF window, because it already has a child.
2) If that child is a Canvas, that's not too bad. I can detect that, and add it to the Canvas. I have to find some way to set its Left, Top etc. properties and Width and Height, since those do not seem to be properties of the Rectangle control but rather extended by the Canvas object -- in XAML they're called Cavnas.Top etc. but Intellisense is not showing them when I try to use it in code.
3) But if it's a StackPanel? Then my rectangle will just be stacked below the other controls! And not covering them! Is there a way around this?
4) And if the window contains only one control and no container control at all?
5) I think there were more problems I ran into. But let's start with these.
Thanks in advance for your help.
1) I can't add it to the WPF window, because it already has a child.
Ah, the evils of codebehind. The solution is not to add it to the visual tree, it is to place it in the visual tree, ready and waiting to pounce, but hide it from the user's view.
Here's a sample you can drop in Kaxaml that demonstrates the point. Set the Lightbox Grid's Visibility to Hidden to access the hidden content.
<Page xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Grid>
<Viewbox>
<TextBox Text="SIMULATING CONTENT" />
</Viewbox>
<Grid x:Name="Lightbox" Visibility="Visible">
<Rectangle Fill="Black" Opacity=".5"/>
<Border
Margin="100"
Background="white"
BorderBrush="CornflowerBlue"
BorderThickness="4"
CornerRadius="20">
<Viewbox Margin="25">
<TextBox Text="SIMULATING LIGHTBOX"/>
</Viewbox>
</Border>
</Grid>
</Grid>
</Page>
2) (snip) Intellisense is not showing them when I try to use it in code.
Canvas.Top etal are Attached Properties. Attached Properties are extremely convenient and easy to use in XAML, but they are very confusing and hard to use from code. Another reason why codebehind is evil.
3) But if it's a StackPanel? Then my rectangle will just be stacked below the other controls! And not covering them! Is there a way around this?
I redirect you back to 1. There are also many other container controls in WPF. You should investigate them and observe how they control layout. For instance, my use of the Grid was not to make use of its ability to block off sections of UI for controls, but for its ability to layer controls ontop of each other and to stretch them out to their maximum available size for the available space (the viewboxes are just there to zoom the controls instead of stretch them).
4) And if the window contains only one control and no container control at all?
The root of a window would almost always be a container control. But you control that, so if you needed to add controls to the visual tree at runtime you could easily ensure the child of the window is a container control you could deal with.
5) I think there were more problems I ran into. But let's start with these.
No kidding. My number one suggestion for people in your situation is to drop what you're doing and learn about MVVM. The Model-View-ViewModel is a very simple way to code WPF applications that takes advantage of many of the features of WPF--databinding, templating, commands, etc. It allows you to code your logic not in codebehind (RETCH) but in easy to create and test classes.
Related
I was making some good progress on my App, but ran into a problem that's stumped me. I was hoping someone could offer their expertise?
My app is intended to be a "scoresheet"... one of the PivotItems features a ScrollViewer (Horizontal scrolling, vertical disabled), with a Horizontal-orientation StackPanel inside. This StackPanel contains a "ScoreSheet" UserControl, which is basically a Grid with various text-boxes on it. So... kind of like this (except the ScoreSheet items are added to the StackPanel programmatically):
<controls:PivotItem>
<controls:PivotItem.Header>
<TextBlock Text="score sheet" FontSize="45" Height="80" />
</controls:PivotItem.Header>
<ScrollViewer Width="470" Height="560" VerticalAlignment="Top" x:Name="sv_scoresheets" MaxHeight="560" MinHeight="560" HorizontalScrollBarVisibility="Auto" VerticalScrollBarVisibility="Disabled" IsHitTestVisible="False">
<StackPanel Name="sp_scoresheets" Orientation="Horizontal">
<local:ScoreSheet></local:ScoreSheet>
<local:ScoreSheet></local:ScoreSheet>
<local:ScoreSheet></local:ScoreSheet>
</StackPanel>
</ScrollViewer>
</controls:PivotItem>
The concept was that "Previous" and "Next" buttons are in the ApplicationBar at the bottom of the page, and they trigger an Animation of the ScrollViewer left or right (ie. Current Round * Width of ScoreSheet). By having "IsHitTestVisible" set to "False" on the ScrollViewer, a user can't manually move the displayed ScoreSheet to a weird position, and swiping left/right between PivotItems still works as expected.
That all worked nicely. :)
However... the problem is on the ScoreSheet control, I want a few Buttons and TextBoxes so the user can enter in a score into the grid. By having "IsHitTestVisible" on the ScrollViewer, the taps/etc. just get ignored.
I tried setting "IsHitTestVisible" to "True" and instead running a function on the ScrollViewer's ManipulationStarted event (calling "e.Complete()")... but although that lets me access controls inside the ScoreSheet, I can't swipe left/right between PivotItems anymore.
So… can anyone help? I was thinking maybe I could refine the ManipulationStarted behavior somehow, maybe "passing along" the action to the Pivot control instead of having the ScrollViewer move? Or some other way I can make the ScrollViewer "inactive" but allow the controls within to be interactive?
I'd really appreciate any help.
Thanks for your time!
Firstly, I would say that your intended usage of the scrollviewer breaks the intended design of the scrollviewer and the pivot (a common mistake windows phone developers, including myself, have made). The main reason this is generally considered a bad practice is that it implements a side ways navigation paradigm that is intended to only be provided by the Pivot control and the Panorama control.
With that said, it doesn't mean your particular use is 100% bad, I think that there are times when breaking the rules is okay. I would just encourage you to do some research and really make sure you're not going to confuse the user, or force them to learn a navigation paradigm that they are not already familiar with through the phone's operating system, and apps that properly make use of the controls provided by the SDK.
Okay, so now that's out of the way, if you determine this really is the best design for your app, you'll need to do the following to accomplish what you want:
Instead of Using a Horizontal ScrollViewer, use a Pivot control inside your Pivot control
You'll need create a header template that is essentially empty so that you don't take up any space in the upper area of inner scrolling section.
This also makes a lot more sense because the horizontal scrolling you are trying to accomplish is by "section" instead of a continuous scroll. This saves you the trouble of having to think about exactly how many pixels you are scrolling (instead you can just use XAML to change the width of your PivotItems
Disable the scrolling functionality of the pivot scroll by the user
This can be done a number of different ways of varying complexity, and almost warrants a question on it's own. See here for one way to accomplish this.
Another thing to do (which gives you more control) is to capture the ManipulationStarted, ManipulationDelta, and ManipulationCompleted events on the inner pivot item. if you detect the delta manipulation containing a horizontal component, then inside the method handler for the ManipulationDelta event, set e.Handled = true. To cancel the inner Pivot's ability to handle the horizontal scrolling. That will look something like the following:
// Event handler for ManipulationDelta event on your inner Pivot control
public void OnManipulationDelta(ManipulationDeltaEventArgs e)
{
if(e.DeltaManipulation.Translation.X != 0)
e.Handled = true;
}
As you will discover, this can provide some odd behavior. Ideally, you'll want to figure out what works best for your app, but typically you want to check for more than just != 0 on the X component, and allow the user some little bit of x, just incase they hit the control at a weird angle such that the X component has a value of 1.
Implementing the buttons to move to the right or the left:
This should be pretty simple, just make use of the Pivot.SelectedIndex property.
However, in most cases, this is a bad idea. Be REALLY sure you are a good exception to standard practice (preferably by giving your app to someone who has never used it but owns a windows phone, and see if they intuitively understand how to use your app.
Many thanks to Paul for his input and advice. A Pivot offered some extra flexibility, but still had similar issues to the ScrollViewer control when IsHitTestVisible="False" (in that buttons and other controls on the contained elements would become unusable). Also, aesthetically for this app, I found I preferred the multiple ScoreSheets being right next to each other when the Previous/Next buttons were pressed and they were animated to show the new sheet (as PivotItems, one would scroll out of view before the next scrolled into place).
After some more thought and experimentation, I achieved the desired effect like this:
<Canvas Width="470" Height="560" VerticalAlignment="Top" MaxHeight="560" MinHeight="560" MinWidth="470" MaxWidth="470">
<Canvas.Clip>
<RectangleGeometry Rect="0,0,470,560" />
</Canvas.Clip>
<StackPanel Name="sp_scoresheets" Orientation="Horizontal" CacheMode="BitmapCache">
<local:ScoreSheet /></local:ScoreSheet>
<local:ScoreSheet /></local:ScoreSheet>
<local:ScoreSheet /></local:ScoreSheet>
</StackPanel>
</Canvas>
The "Canvas.Clip" let me hide the ScoreSheets on either side of the currently visible one, and I could animate the Canvas.Left position of the StackPanel when the Previous/Next buttons were pressed.
By avoiding the ScrollViewer or Pivot, there were no events to handle/override, and the controls in the StackPanel could then be accessed as I intended.
'hopefully that might be of help to others. :)
As a new comer to WPF, I would like to clarify my approach to build a UI in WPF. I am using WPF with MVVM. My approach is to use a main window which contains user controls which can run several levels deep in the UI tree. For example, I have an editor in a window. Many items can be edited in the editor and the UI for each items are different, but the editor always shows an OK and Cancel button. So the main editor window with OK and Cancel can be shared between several editors. I am designing the app in such a way that the editor user control will just bind the view model for the item which is edited. So when designing the UI for editing individual items OK or Cancel Button is not pulled in, but simply put the item into the main editor which will provide the buttons. I am pretty sure I can handle the commands correctly with WPF command infrastructure.
If I can make it clear with some xaml here it is.Please dont mind the control placement itself, I mean to explain the basic idea of sharing the Common UI across many items.
<UserControl Name="EditorMainWindow">
<Grid>
<StackPanel>
<ItemsControl ItemsSource="{Binding ItemToBeEdited}">
</ItemsControl>
<Button Content="OK" Width="120" Command="{Binding SomethingforOK}" />
<Button Content="Cancel" Width="120" Command="{Binding SomethingforCancel}"/>
</StackPanel>
</Grid>
</UserControl>
The way I am doing it, the user interface tree can go several levels deep. I will be tremendously benefitted, because if the client ask to change the UI in one particular place, I need not got and change it in many places(provided it is shared).
As I am new to WPF I would like to know if there is any catch in this approach. Could you please tell me if this makes sense or not?
You can save yourself a lot of time. Catel already provides such a window:
DataWindow
It is fully ready for MVVM (Catel is also an MVVM framework) which supports dynamic nested user controls. The nice thing is that it also supports error handling out of the box, so as soon as an error occurs in the window template, the user will see the error in the InfoBarMessageControl.
Greetings
I'm currently making an application in WPF as I'm fairly new to WPF I'm running into some difficulties. I have Googled my question but with no great success. This is the current situation, XAML of main window below:
<Grid Height="279" HorizontalAlignment="Left" Margin="166,0,0,0" Name="gridScoreboard" VerticalAlignment="Top" Width="808">
<!--Scoreboard Image-->
<Image Source="pack://application:,,,/Images/Style/Scoreboard.png" Width="517" Height="91" HorizontalAlignment="Left" Margin="138,1,0,0" Name="image1" Stretch="Fill" VerticalAlignment="Top" />
<Canvas Name="canvasRacePlayer1" Width="14" Height="14" Canvas.Left="33" Canvas.Top="66" Background="Transparent" MouseLeftButtonDown="canvasRacePlayer1_MouseLeftButtonDown" Margin="171,70,623,195" />
<local:ucRaces HorizontalAlignment="Center" Margin="93,62,632,187" Width="78" Visibility="Hidden" x:Name="ucRacesP1" Height="33" />
</Grid>
The user control is hidden from the start (ucRaces), once the little canvas (canvasRacePLayer1) is clicked the user control will be shown. However I would like this user control to 'slide' from right to left from a certain point. As if it would become visible in small steps. I have found information for animations for rectangles and buttons but no success really for User Controls.
Thank you in advance
If you are going to create animations for your WPF project, I suggest that you use Expression Blend. You can design your program using EB and implement the functionality of it using Visual Studio. It will be hard to make animations, writing XAML syntax or C# code.
How would you be able to animate your user controls using EB? Well, it is actually very simple. You need to open your existing WPF project first. Then, go to File -> New Item -> User Control, and create the user control. Then, if you want to add it to your project, switch back to the WPF project currently open in EB and click the right arrows (>>) on the toolbar placed on the left-hand side of the screen and go to Project -> [Your User Control Here]. Now you have added it to your project.
If you want to animate the user control, you have to add a StoryBoard to your timeline. When you are on your WPF project in EB, under Objects and Timeline, click the plus (+) sign and add a new StoryBoard. Now, you have a timeline that you need to use to animate your user control. You can place KeyTime attributes on the timeline and define the path the user control is supposed to follow from location A to location B and also the level of opacity if you want the user control to gradually become visible.
You can add one more user control and implement its logic for the second user. Expression Blend will make your life easier.
Animating your UserControl shouldn't be much different from animating any other WPF object: You can either animate the margin (using a ThicknessAnimation), or drop your user control into a canvas of its own, then animate the Canvas.Left property of your user control. In the latter case, take care to put the property name in parenthesis: Storyboard.TargetProperty="(Canvas.Left)".
FindAncestor RelativeSource only supports 'Self' and 'TemplatedParent',
but I have to bind the width of a popup to the width of the page.
Giving the page a name causes problems because sometimes it will
throw exceptions saying a control with that name is already present in the visual tree.
<Popup IsOpen="True"
Width="{Binding ElementName=BordPage, Path=Width}"
Height="{Binding ElementName=BordPage, Path=Height}">
Background information:
I'm using a SL4 navigation based application here. BordPage is a navigation page,
which I'm using multiple times within the application. So giving it a name in the page itself is not really a good idea,
but I don't know how else I can bind to the width and height of the page.
What I'm trying to do is have a black border (with opacity 0.8) cover the entire screen,
(including the controls of the MainPage). Then on top of that I want to display some other controls.
Since the application is touch controlled, providing the user with a ComboBox to select a value doesn't really work wel. Instead I want to show this black overlay window with a listbox taking up most of the screen so the user can simply touch the value he wants with a single click.
Update: I just realized I can use the ChildWindow class to do this.
But my original question remains.
My general solution for this problem is by writing a custom behavior. It's not a pure XAML solution but it gives you a lot more flexibility.
Create a behavior that searches up the VisualTree to find the right item and then have it set the width of the Popup correctly.
It may be a little more complicated than a straight binding but it avoids all the naming issues.
Put the following in the constructor of your control so you can avoid naming it:
DataContext = this;
I want to create a WPF window that behaves as a modal dialogue box while at the same time facilitating selected operations on certain other windows of the same application. An example of this behaviour can be seen in Adobe Photoshop, which offers several dialogues that allow the user to use an eyedropper tool to make selections from an image while disabling virtually all other application features.
I'm guessing that the way forward is to create a non-modal, always-on-top dialogue and programmatically disable those application features that are not applicable to the dialogue. Is there an easy way to achieve this in WPF? Or perhaps there's a design pattern I could adopt.
Yes, there is the traditional approach you describe where you programmatically enable/disable features, but WPF also opens up several new possiblities that were really not possible in WinForms and older technologies.
I will explain four WPF-specific ways to do this:
You can secretly and automatically replace a window's contents with a picture of its contents using a Rectangle with a VisualBrush, thereby effectively disabling it. To the user it will look as if the window is unchanged, but the actual contents will be there underneath the picture, so you can use it for hit-testing and even forward selected events to it.
You can add a MergedDictionary to your window's ResourceDictionary that causes all TextBoxes to become TextBlocks, all Buttons to become disabled, etc, except as explicitly overridden using custom attached properties. So instead of looping through all your UI selectively enabling/disabling, you simply add or remove an object from the MergedDictionaries collection.
You can use the InputManager to programmatically generate and process real mouse events in particular parts of a disabled window, disallowing any mouse events that don't hit-test to something "approved."
Use data binding and styles to enable/disable individual controls rather than iterating through them
Details on replacing window with picture of window
For this solution, iterate your app windows and replace each content with a Grid containing the original Content and a Rectangle, like this:
<Window ...>
<Grid>
<ContentPresenter x:Name="OriginalContent" />
<Rectangle>
<Rectangle.Fill>
<VisualBrush Visual="{Binding ElementName=OriginalContent}" />
</Rectangle.Fill>
</Rectangle>
</Grid>
</Window>
This can be done programmatically or by using a template on the Window, but my preference is to create a custom control and create the above structure using its template. If this is done, you can code your windows as simply this:
<Window ...>
<my:SelectiveDisabler>
<Grid x:Name="LayoutRoot"> ... </Grid> <!-- Original content -->
</my:SelectiveDisabler>
</Window>
By adding mouse event handlers to the Rectangle and calling VisualTreeHelper.HitTest on the ContentPresenter to determine what object was clicked in the original content. From this point you can choose to ignore the mouse event, forward it to the original content for processing, or in the case of an eyedropper control or an object selection feature, simply extract the desired objects/information.
Details on MergedDictionary approach
Obviously you can restyle your whole UI using a ResourceDictionary merged into your window's resources.
A naiive way to do this is to simply create implicit styles in the merged ResourceDictionary to make all TextBoxes appear as TextBlocks, all Buttons appear as Borders, etc. This does not work very well because any TextBox with its own style or ControlTemplate explicitly set may miss the updates. In addition, you may not get all objects as desired, and there is no way to easily remove the Commands or Click events from buttons because they are explicitly specified and the style won't override that.
A better way to work this is to have the styles in the merged ResourceDictionary set an attached property, then use code-behind in the PropertyChangedCallback to update the properties you really want to change. Your attached "ModalMode" property, if set to true, would save all the local values and bindings for a number of properties (Template, Command, Click, IsEnabled, etc) in a private DependencyProperty on the object, then overwrite these with standard values. For example a button's Command property would be set to null temporarily. When the attached "ModalMode" property goes false, all the original local values and bindings are copied back from the temporary storage and the temporary storage is cleared.
This method provides a convenient way to selectively enable/disable portions of your UI by simply adding another attached property "IgnoreModalMode". You can manually set this to True on any UIElements that you don't want the ModalMode changes to apply to. Your ModalMode PropertyChangedCallback then checks this and if is true, it does nothing.
Details on InputManager approach
If you capture the mouse, you can get mouse coordinates no matter where it is moved. Translate these to screen coordinates using CompositionTarget.TransformToDevice(), then use CompositionTarget.TransformFromDevice() on each candidate window. If the mouse coordinates are in bounds, hit-test the disabled window (this can still be done even when a window is disabled), and if you like the object the user clicked on, use InputManager.ProcesInput to cause the mouse event to be processed in the other window exactly as if it was not disabled.
Details on using data binding
You can use a styles to bind the IsEnabled property of Buttons, MenuItems, etc to a static value like this:
<Setter Property="IsEnabled" Value="{Binding NonModal, Source={x:Static local:ModalModeTracker.Instance}}" />
Now by default all items with these styles will automatically disable when your NonModal property goes false. However any individual control can override with IsEnabled="true" to stay enabled even in your modal mode. More complex bindings can be done with MultiBinding and EDF ExpressionBinding to set whatever rules you want.
None of these approaches require iterating through your visual interface, enabling and disabling functionality. Which of these you actually select is a matter of what functionality you actually want to provide during modal mode, and how the rest of your UI is designed.
In any case, WPF makes this much easier than it was in WinForms days. Don't you just love WPF's power?
What you're looking for is similar to a Multiple Document Interface. This isn't available by default in WPF but there are some efforts out there to support this, both free and commercial.
It will be up to you to identify the current state of the application and enable/disable UI elements in response to this.
I think an always-on-top windows that programmatically disables certain app features is the way to do this. It might be easier to keep a "white list" of features that can be enabled while this form is open, and then disable everything that isn't on the list (as opposed to trying to maintain a "black list" of everything that can't be enabled).
I believe the best approach to solve this is using the InputManager approach mentioned previously. This design pattern allows you to connect commands to your toolbar buttons/menu items etc and each will call a CanExecute handler you specify for your command. In this handler, you would set the command to not enable if your always-on-top non-modal window was open.
http://msdn.microsoft.com/en-us/library/ms752308.aspx