Is it possible to set visibility on a Grid or other element based on the visual state of another control? I'm just starting to wrap my head around the VisualStateManager concept (having found that style triggers can't be used in universal apps) but can't work out if this can be done or not.
To my specific scenario, am I able to set the visibility of one or more elements if a specific item/index in a ListView is currently selected? If so, how?
I would maintain the ListView selection in a property of the viewmodel and bind Grid.Visibility to that property. You will need an IValueConverter to convert from the selected item's datatype to System.Windows.Visibility, which is required for Grid.Visibility binding.
In case the logic to determine visiblity is more complex, e.g. requires application state, you could add a property bool IsImportantItemSelected to the viewmodel and bind Grid.Visibility to this property. This approach allows you to keep the complex logic in the viewmodel. You'd need an IValueConverter again to convert from bool to System.Windows.Visibility.
Related
I'm looking for advice on how I might implement a custom property on a page type that supports inheritance.
The sort of functionality I'm looking for would be similar to how the "Use output cache" radio buttons work on the Properties > General page in portal mode.
So I want to be able to create a property on a page type, see radio buttons like this, and then based on whether I choose yes, no, or inherit it will go back up the content tree to find the value to apply to that property (if inherit is selected of course).
I hope that makes sense.
Thanks
Jay
Not sure if I understand. So you want have a dynamic property for your page based on parent's value at the moment of creation. You can access parent object like so:
{%EditedObject.Parent.FieldName%}
You may try to create field with radio button control to choose a value.
0; No
1; Yes
{%EditedObject.Parent.FieldName%}; Inherit
Hope this gives you some ideas
I have a managed action with returns bool when a button is pressed.
Depending on if true / false is returned I want to be able to change the properties of controls on the dialog. Not limited to just the text value.
Is this possible, for example the visibility, etc?
It is possible, however you will have to make sure there is a set-property control event (after your managed code custom action do-event) that touches a property related to anything you want the UI to update. If you change a property value within the managed code, or via the wrapper InstallShield provides, the Windows Installer UI doesn't track the change and update in response.
So, for example, you could wire your return value to the property RETURNVALUE, and then add a control event that sets better named properties like MYCONTROLTEXT or SHOWMYCONTROL; the control or its conditions would be wired to those better named properties.
I'm currently building a custom control to be used as an application's view navigator (classic OneUI style). First of all: this is a 8.5.3 based project, and unfortunately there's no way to use Extlib stuff or other extensions / plug-ins. So we have to build all the tricky stuff ourselves using only what came "out-of-the-box" with 8.5.3.
I'd llike to build my navigator using a repeat control containing <xp:link> controls. Datasource could be an array of javascript objects where each single object would look like this:
var navEntry = {"entryLabel" : "label-of-link",
"entryTarget" : "target-url-of-link",
"entryStyle" : "style-to-emphasize-selected-link"}
Each array element then would describe a single navigator entry.
Since the navigator will be used in all possible "DominoView" Xpages it yould make sense to build the array of JS objects at the Xpage level and then pass that info into the custom control.
I'm aware that there are multiple ways to do this, and one could be "Custom Control Properties". If there was a way to pass my JS object array.
(Hope I could make clear what I'm trying to do here...)
That object looks like a HashMap to me really. You should be able to pass that in to a custom control via custom property if you use the type java.util.HashMap I'd think. You'll need to type it in I'm sure. I've passed custom objects in by using java.lang.Object.
The custom control will get loaded during the Page Load event, and usually properties have to be available at that point. If they're loaded during the Render Response phase, that's too late. So your SSJS object will need to be Compute on Page Load.
To use contents of a repeat control, you would need to set repeatControls=true, otherwise the repeat is only built during render response. Until then it's just a single set of controls with no data in them. However, Im pretty sure repeatControls="true" means you only get the number of rows you define. You can't change it via a pager.
You can manually define the type of the custom property. For a standard SSJS Object you use "com.ibm.jscript.std.ObjectObject", for a SSJS Array you use "com.ibm.jscript.std.ArrayObject" etc. As editor for the custom property, I set the string editor ("String value").
I have a MainView which has an associated MainViewModel in my WPF application, assigned via its contructor.
App > start up uri > MainWindow.xaml
public MainWindow()
{
InitializeComponent();
var viewModel = new MainViewModel();
DataContext = viewModel;
}
My MainView holds as many as four nested views or child views who are hidden and displayed based upon the button that has been clicked on the MainView. So we toggling the visibility property vi a binding which gets updated via command bindings assigned to each button on the MainView.
Each nested View does not have an associated ViewModel, all bindings found on child views find their information in the MainViewModel. So binding system ends waling up the UI tree of the app to find out that the parent 'MainView' has an associated ViewModel.
So overall there is 'ONE' -> ViewModel. This seems to work fine and but as expected this VM has gotten to big and needs re-factoring. It holds information that contextually it should not. But this is a proof concept application. So i decided to keep it simple and make sure it was do-able.
PROBLEM:
When i tried assigning a empty view with an empty view model I noticed binding errors in the output window and as expected weird and broken behaviour. Which makes no sense ... Is there a more clear and concise way of letting WPF know how to handle any bindings it finds in a nested view control? I thought if each view's constructor assigned itself a corresponding VM as shown above, then it should work as this logically makes sense. Unfortunately all buttons on the MainView stop working when the corresponding view it is designated to switch on and hide the others has an associated ViewModel. On some buttons it works and the others it does not? This is really weird?
As mentioned in my answer above, the problem was that WPF binding system was struggling to to resolve bindings at run time. The main view has its associated view model instantiated and assigned via the Main View contructor and this pattern is repeated for all nested views that the MainView also houses.
By default, I tend to use the implied binding syntax which means that without explicitly specifiying a source the binding system will try to resolve the name you supply in the binding. So it's all implied and nothing is explicitly set!
Upgrading each nested view to have its own view model makes this auto discovery/resolution of bindings go a little crazy and I have not explicitly told the binding system where to find the property I am looking for hence the output window binding errors.
This leads to unexpected behaviour as the output window was telling that it was trying to resolve binding expressions in nested views --> viewmodels. When in actual fact that VM it is looking in, IS EMPTY!
So clearly the binding system is good when you do not explicitly set a source property inside the binding syntax. It is clever enough to find things on its own. In my case it needed some extra help, as it was unsure as to where to find things.
SOLUTION:
Remove the constructor declaration for the MainViewModel in the MainView constructor.
Scope in an xmlns for ViewModels namesapce into your MainView.xaml
Create a window resource inside the MainView .xaml
Give the resource a key.
Upgrade all your bindings in the MainView xaml file to include source property.
Give the source property a static resource binding that points to your ViewModel key value set up in step 4.
Only do step 6 for bindings who refer to the ViewModel that is associate with the MainView.
All nested views are to be left alone, they should handle their own bindingds in their own xaml files. The MainView simply instantiates them and places them onto the UI. For me this was the case, I did not have any more bindings concerning my nested views. All Bindings that lived on the MainView.xaml file referred to data in the MainViewModel.cs. This makes alot easier when viewing your problem.
For some reason the editor was being awkward so I chose to omit any sample code but the steps above are descriptive enough to follow the steps that I took. Above is what worked for me.
ANOTHER WAY OF SUMMING UP THIS PROBLEM
Most books teach the shorter binding syntax
What happens when more than one data context is available?
How is the binding system supposed to know how to resolve your short hand binding expressions.
I have a ListBox control defined within MainWindow and its IsManipulationEnabled property is set to true. I have the manipulation events (OnManipulationStarting, OnManipulationInertiaStarting and OnManipulationDelta) defined in the MainWindow. The goal here is to achieve a translation on the Listbox control, more like a flip functionality.
However, these events are never raised. I am assuming that the selection events are in turn gobbling these events. When I use itemscontrol instead, it works fine. But the problem in using itemscontrol is that I do not get a selection state. Another option would be to work on raw touch, but manipulations are way easier.
Why do the Manipulation events not fire on Listbox?
Thanks in advance!
The default template for an ItemsControl doesn't contain a ScrollViewer but the ListBox does. The ScrollViewer handles those events when the PanningMode is something other than None. By default a ScrollViewer binds several of its properties (like PanningMode) to that of its templated parent. Try setting the attached ScrollViewer.PanningMode property to None on the ListBox.
<ListBox ScrollViewer.PanningMode="None" />