Is there a way that I could partially select a list item with sap.m.ListBase mode set as MultiSelect?
Something like this for some of the entries in the list:
https://sdk.openui5.org/entity/sap.m.CheckBox/sample/sap.m.sample.CheckBoxTriState
In the official UI5 API reference for sap.m.Checkbox, there's the property partiallySelected. But for the sap.m.ListBase, I couldn't find anything.
To anyone who faces this problem, I found a solution,
So earlier I was relying on the checkboxes provided by the list's MultiSelect mode and then displaying the items as StandardListItem but I later replaced it with CustomListItem and in it, added my own checkboxes, in which I could set the partially selected property.
I hope this helps :)
I don't think the tri-state makes much sense in combination of sap.m.ListBase and mode="MultiSelect". According to the SAP Fiori Design Guideline checkbox sections regarding "Tri-State":
Usage
[...]
You want to group multiple suboptions under a parent option, and require an intermediate selection state (tri-state). The tri-state indicates that some (but not all) suboptions are selected.
[...]
The main purpose of this state is to represent the mixed selection states of dependent input fields. If some (but not all) of the dependent fields are selected, the checkbox shows a partially selected state. This is only a visual state and can’t be achieved by a direct user interaction.
Unless the list control is of type sap.m.Tree, displaying tri-state checkboxes in sap.m.ListItemBase without any suboptions deviates from common UX patterns and thus might be confusing for end users. I'd suggest reviewing SAP Fiori Design Guidelines (or other design guidelines in case of freestyle) and re-evaluating whether checkbox is really the correct UI element for the intended interaction design.
Related
I've asked this question on the Data Studio community page with no response, and haven't been able to find the answer elsewhere.
I need to stop 2 charts on a page from inheriting the page level control that I have set. From searching around, it appears that there used to be an option to disable filter inheritance, which would achieve exactly what I need. However, that option seems to no longer be available.
I've tried manually setting chart level filters that include all of the information I need, but they still seem to be overridden by the page level controls I have set. I've tried creating calculated fields that hard code the information I need, but they are also overridden by the page level controls regardless.
The comparison that I need to make is between an individual store's customer churn, and the average churn for all stores. The report is an overall report for all stores, with the ability to choose an individual store from a dropdown control to narrow down the results, so I can't set it up with chart-level filters as that would defeat the whole purpose.
Does the filter inheritance option no longer exist, or does it not apply to controls? Is there another way around this that I'm missing?
Thanks in advance! :)
Screenshot of the filter inheritance options missing:
No filter inheritance
Example Data Studio report:
Example report
UPDATE: I have figured out a temporary workaround, which is to set up a separate data source that does not include the fields referred to within the controls. However, this is not a workable solution for reports with a number of pages and a number of controls added, as it effectively requires a new data source for every control that I need to exclude (and sometimes that isn't possible).
Group
One way to ensure that the two specific charts (referred to as Excluded_Charts in this answer) are not influenced by Controls (in this case a Drop-down list and a Date range control) is to Group all charts except Excluded_Charts, which would result in the two charts operating independently from the rest:
Right-click on a blank space in the Report
From the drop-down click on Select > All charts and controls on page
Ctrl+Click on both charts in Excluded_Charts to exclude them from selection
Right-click on one of the selected charts
Click on Group from the right-click menu
Additionally, to make sure that the Date range control does not affect Excluded_Charts select both charts in Excluded_Charts and change the default date range from Auto to Custom.
Ungroup
To reintegrate Excluded_Charts back with the rest of the charts in the report:
Select the grouped charts (selecting a single grouped component will highlight all grouped components)
Right-click on one of the selected charts
Select Ungroup from the right-click menu
Additionally, remember to change the default date range of the Excluded_Charts back from Custom to Auto.
Editable Google Data Studio Report (Embedded Google Sheets Data Source)
I seem to have found a solution - the issue is that I was looking at filter inheritance rather than controls. Controls can be limited in scope by grouping them with the charts you want them to apply to.
Thank you very much for your help #Nimantha! I would have never figured this out if you hadn't pointed out that I was referring to filters rather than controls.
I've got a combobox that is triggering an accessibility error from the Accessibility for Insights tool (https://accessibilityinsights.io/en/downloads/). The combobox can be seen in the mobile phone field with the country flag selector here - https://configure.awardsplatform.com
This is the error message I get from Accessibility for Insights:
Wai-aria 1.1 guidelines say the textbox is necessary - https://www.w3.org/TR/wai-aria-1.1/#combobox
However, I'm confused because Wai-aria 1.2 guidelines (still in development apparently) don't have it as a requirement - https://www.w3.org/TR/wai-aria-1.2/#combobox
And this example combobox also doesn't include the textbox - https://w3c.github.io/aria-practices/examples/combobox/combobox-select-only.html
There's conflicting information here so I'm unsure whether it's required or not. Does anyone know?
Short Answer to "Does a combobox require a child element with the role of textbox?"
Under current (aria-1.1) standards: yes.
Longer Answer
The standards will change soon(ish), you are looking at future guidance that has not yet been finalised. Under current guidance your country selection is using the incorrect role.
Why are you getting an error?
We are still working with aria-1.1 standards.
The definition of a combobox in the aria 1.1 standards is:
A composite widget containing a single-line textbox and another element, such as a listbox or grid, that can dynamically pop up to help the user set the value of the textbox.
As for the example combobox you gave, you may have been looking at an example intended for aria-1.2 (although I still don't believe it would be valid then as it should still set the value of some kind of input, but we will see when everything gets officially released as I think the 1.2 definition of an "input" still needs to be better defined)
For now a combobox is an <input> (or equivalent) with a related list that can be used to set the value of the <input>. A key feature is that you should still be able to manually enter a value.
What should you use instead?
For your example a <select> (or equivalent such as role="listbox") would be far more appropriate as a user cannot manually enter a country.
Even when new guidance comes out a listbox will probably still be a better choice from the definition currently in place.
I've got a massive UI that I'm designing. The way that my employer wants it, there are at least 100 labels. Now, I've always thought that in cases like this, breaking up the UI into smaller custom controls was the ideal way to go. However, someone recently told me that custom controls are really only for code re-use. What is the actual suggested practice for this?
EDIT
The finished form will look like this:
Now, I'm using WPF for the UI, and I'm thinking of breaking this down into smaller bits.
Based on your image i see some repetitions, each of this repetitions could be a custom UserControl
But it depends on the usability is it easier to write a custom UserControl so do it but if it would reduce the readability of your code and it also adds additional complexity don't do it
here are an example of what could be separate UserControl's
the green ones are possible useful encapsulations of logic
the orange ones maybe need some not market stuff (don't know enough about your software)
the red ones are the maybe's based on the intern use (from the visual part they are repetitions so the should custom UserControl)
Since your UI is read-only, I'd suggest using a grid.
Are you new to WPF? To break the View into bits WPF offers you CustomControls and UserControls. They are two very similar things yet completely different from each other. CustomControls are Buttons, Labels, TextBoxes, DataGrids...etc. They are basically simple stand-alone controls. UserControls are groups of stand-alone controls serving a purpose such as example a Button and a ComboBox next to each other so user can select something in ComboBox and confirm that by clicking the Button.
If you wish to display data from database I suggest you DataGrid which will give you a table-alike look with rows and columns and all that. If you wish to place few buttons next to DataGrid on which the user may click to insert a new row or to edit a certain cell then I suggest you to wrap all that with a UserControl which you can reuse in other places where you have to display and change data from database too.
You should be using a datagrid and can customize its template to render individual cells as Textblock (lighter version of Label) from a rendering perspective. The main difference between Textblock and Label is very minor things such as access keys and disabled state behavior. But from a WPF object hierarchy - Textblocks are much lighter. But besides that point - from your employer perspective - once you have customized the grid template and render them (so as they look as textblocks/labels) - your employer should have no problems.
Also as somebody suggested above - if you want to logically break sections of the UI since they maybe coming from a different table in db - then User controls is the way to go (for maintainability of code)
Let me know if you are looking for more technical details or need help further technically.
There is nothing wrong in making and using custom controls or user controls or defining some data templates which will be reused depending on how your data is organized.
For sure the UI looks pretty messy and some sort of grid should be used with templates for example where there is similar data. I also have the suggestion and first think about the data and the functionality before starting and let the UI be driven by that. For sure you will the reuse controls/templates. If you think in front on the model and behavior the UI can afterwards more easily changed.
Create your viewmodel correctly, implement the functionality in commands, use bindings, after that the UI will come naturally, reuse controls, use several grids, make the UI more user friendly using several regions, tabs, windows or anything that makes the user more comfortable.
Scenario:
I have one GUI where i have multiple user controls as:
One UserControl on left side of form that contain data filter and selection feature.
Another User Control on right side display/ Report data on selection from left side user control.
Last on is Menu band that control the view of above two control on some menu selection and the view of these controls change but data remain same with some conditional modifications.
That i have do somewhat. Used a global class that have some event which will be raised to make changes/ modification in these views.
I did somewhat accordingly, but i want to implement it in a maintainable way so that if i need to make some modification in functionality then i need not to change whole system.
Is there any design pattern or Model to implement such functionality where you can maintain such type of functionality in win forms?? if yes then please provide some information with some implementation..
I know this is little subjective question, but if reference links provided then much better.
Thanks in advance.
You want a model object shared between the different parts of your UI that implements the INotifyPropertyChanged interface. Use a BindingSource to link the controls with the model.
I need a ListBox which will contain several options. I need checkboxes exactly(style), not radio buttons. Is there any way i can allow only 1 checked checkbox at the moment? I'm using MVVM, so i can't just check or uncheck them manually, it's against the rules.
And if i can't make such functionality - is there easy way to style radiobuttons to look like checkboxes?
Aside from a flawed requirement*, the only way to do this is to uncheck all checkboxes, then check the particular indexed checkbox.
Or alternately (cos it does the same thing, but sounds longer), iterate through all the indicated checkboxes and find whichever one is set to true that is not the one you want checked, then set it to false.
flawed requirement: A series of checkboxes indicates to any user that they are allowed to select zero or more items. A series of radiobuttons indicates that they are allowed to select only one. This is something that has been drilled into users since before Windows 3, and that all non-IT will not question. You'll break their mental model, which is worse than looking pretty. Please have management revise this requirement.
HTTH. YMMV.
If you are using MVVM and what to stick to the "rules" then your ViewModel should have a property to which the checkboxes bind. Its the up to code in the ViewModel to ensure that state of this property is correct.
So code in the ViewModel where one property gets set to true may need hunt through a collection to find similar items whose matching property needs to be forced to false. The View then simply reflects the current state of the ViewModel.
Well, in the end, i used this solution