I have an interesting issue with a LightSwitch app I am maintaining, there is room for confusion so will try and explain at length and answer any clarifying questions.
I have a LightSwitch AddEdit screen using the default 'Flip Switch' control for Boolean values in a table, set to Yes/No Option (so shows Yes or No as values, actually saves 0 or 1), when creating a new entry, the control shows 'No' by default. The issue is that depending on what permission the user has the control behaves differently, either:
1) the expected/desired behaviour: The flip switch is set to 'No' by default and if the screen is saved without touching it 'No' is saved to the database (What the user sees and what is saved is consistent, a flip switch is never NULL).
2) The unexpected behaviour: The flip switch looks like it is set to 'No', but when user attempts to save the screen, gets a warning "Error: Cannot continue. There are validation errors on the page" because there are Boolean values that do not allow NULL (the relevant flip switches are highlighted with 'This field is required') the user can toggle the flip switch control to Yes and back to No, at which point the screen will save (touching the control seems to set it to a value from NULL), but disturbingly the other flip switches that do allow NULL are saved as NULL instead of the 'No' they show on the screen, this is confusing and problematic and will require users to re-enter all the NULL entries once I fix this bug.
The troubleshooting I had done so far shows that the behaviour is contingent on what LightSwitch Access Control permission the user has set, if they are in one group(SystemAdministrator) they get behaviour 1 in another(DatabaseOperators) they get 2.
It also appears contingent on being an 'add' rather than an 'edit' if adding a new row as a SystemAdministrator, the data will be added as behaviour 1. if editing an existing entry you get behaviour 2 as both permissions.
I tested commenting out the VB code that filters the permissions for the data source for this table (TableName_CanRead, TableName_CanWrite, TableName_CanInsert, TableName_CanUpdate, TableName_CanDelete, TableName_CanExecute, TableName_Filter) as that seemed to be a likely point of difference and it did not change the behaviour.
I am hoping that someone more familiar with the LightSwitch environment will be able to point me to another likely place where this issue is coming from and give some hints on where to look or further troubleshooting steps.
I currently can't see how the permission group is effecting the flip switch control behaviour so markedly
The best practice for your scenario in my opinion is the following:
on the screen created code block, use the following code for each switch:
myapp.SCREENNAME.created = function (screen) {
if (screen.TABLENAME.theFlipSwitchA == null) {
screen.TABLENAME.theFlipSwitchA = false;
}
if (screen.TABLENAME.theFlipSwitchB == null) {
screen.TABLENAME.theFlipSwitchB = true;
}
}
This will ensure the null values are replaced with the correct TRUE or FALSE values at the start, and will only change if the user changes them.
In Addition
There are 2 views available for a flip switch aswell being Yes/No and On/Off, which can be accessed on the properties of the selected Flip Switch:
One thing to make sure is you use the Data Binding property to specify the value, not the Name like you usually would on a forms application for example.
Related
We have a view in which the users current location can be used.
We are doing the standard 'can we use your location' when the view is 1st shown (and the user hasn't previously said no). If user says yes then it looks up the current location and then shows this.
If user says no (or this isn't the 1st time) then the view stays on screen with the choice of either entering a location textually or pressing the 'use current location' button. Clearly if user has declined location previously we then prompt for permission again if they press the 'use current location' position.
We have this currently implemented through a 'prompt for permission' property on the View Model which the view then subscribes to. If the user says 'yes' we (the view) executes the 'userconfirmed' command in the view model otherwise we execute the 'userdeclined' command (in the view model).
Whilst this works, it just doesn't feel right. We've seen the UserError code and could potentially use this but it feels a bit strange using a mechanism potentially for errors to prompt the user for permission. Clearly this is a scenario which MVVM implementations have numerous different solutions but given the concise nature of ReactiveUI we expected a subtle solution.
Suggestions anyone?
The UserError framework would work well for this scenario, it's probably what I would do. The advantage of using UserError is that you can simulate all of the scenarios really easily (i.e. user declines first view, decides yes later; user clicks yes; etc etc).
Define a subclass of UserError (LocationPermissionError or something), then register a handler on your View that is only interested in LocationPermissionError.
in a List view I want a particular control (textbox) to have a red background color if it has a certain value. I have tried the following:
Click on the textbox then click the Data icon in the context sensitive controls that appear. I can then see that the name of the control is First_NameTextBox. I then click anywhere on the List view and click the Actions icon in the context controls that appear to the right of the view. I select "On Current". I then create two steps that should be executed whenever a new record is activated:
If [First_NameTextBox] = "somevalue" Then
SetProperty
Control Name [First_NameTextBox]
Property BackColor
Value #FF0000
End If
However, this turns the textbox red no matter what the value in First_NameTextBox is. How do I reference the CURRENT value of the textbox?
Conditional formatting based on a field value is not available for the List View in a Web App.
If you've built web pages (with or without a templating engine), the design limitations of Access can be frustrating.
Another kind of frustration comes from moving a form in Access from the native Access environment to a browser-based display.
I've felt the first kind of frustration, but so far I've avoided the second kind. I keep MS Access and HTML-rendered forms far away from each other.
Conditional Formatting in the List View of Access Web Apps is Available its just way harder than it should be.
Input "If Statement" under the "Current Macro" by clicking outside any text box or label then traveling to the top right of the view and you will see the Lightning bolt which allows two options, "On Load" and "On Current".
SELECT ON CURRENT
Don't forget You will need to set the control back to the original color by using the else. (also, for some reason I have to flip the Colors so where you would think red would go, Put White.
Example:
IF = "" True Then
White
Else
Red
END IF /DONT ASK ME WHY!
Summary: your Code is Sound, Just input it under the Views Current Macro Location
This is my first post, i spent DAYS looking for this information and found in the deep google somewhere so i hope this helps you.
For the last few days i have been trying to figure out the best way to get AutomationElement for a specific control in a vb6 application.
My initial way of doing so was by doing a search with the following condition:
new PropertyCondition(AutomationElement.NameProperty, controlName)
I was under the assumption that this was working correctly for about a week in a little test VB6 application.
but i few days ago i realized something... when i dragged a vb6 textbox into the form, the 'Name' property and 'Text' property were both set to 'Text1'
So when i searched with:
new PropertyCondition(AutomationElement.NameProperty, 'Text1')
it return the correct element, but if i then went and set the 'Text' property to '' the same search would bring nothing back.
Question: Has anyone found a way to get a AutomationElement based on a the VB6 control name
What i have tried:
getting the MSAA equivalent interface and looking at the 'Name' property - Result: ''
http://msdn.microsoft.com/en-us/library/windows/desktop/dd318490%28v=vs.85%29.aspx
getting the control based on other properties (AutomationId, RuntimeId) - Result: AutomationId - not all controls seem to have this property available - RuntimeId - changes each time the app runs
I have looked at alot of different sites the main one is listed below - while some say they have manage to get it working - i don't believe i can see how they do it.. or i just dont understand it :$
http://blogs.msdn.com/b/brianmcm/archive/2006/01/17/getting-the-winforms-id-of-a-control.aspx
While i have access to the demo app, i will not access to the production app as that has been created by a third party.
What i plan on doing from here is to get the Automation element based on their position on the form..
Thank you
Can't comment due to low rep. Do you absolutely HAVE to have an AutomationElement?
You may want to look at invoking [user32.dll] (http://pinvoke.net/default.aspx/user32.EnumChildWindows). Look at FindWindowEx, GetWindow, EnumWindows, EnumChildWindows, GetWindowText, etc.
You need the handle of the parent window, so you can use this loop to get it. From there you can use the other functions to get the information you need about the control.
IntPtr hWnd = IntPtr.Zero;
foreach(var process in System.Diagnostics.Process.GetProcesses())
if(condition)
hWnd = process.Handle;
Comment with the exact information you need out of the VB6 window, and I'll give you better code.
You can use the relational position of the AutomationElement in a specific Window (or any other container for that matter), in order to detect it. For example, if you have 5 TextBox AutomationElements in your main window, and you're certain that the order will not be changing, you could create a PropertyCondition on the TextBox class name, and then use the FindAll method to return a collection of AutomationElements and iterate through it, querying the BoundingRectangle property to find out which is the lowest one (or middle, or any other position, for that matter).
I would create a helper method that would return a Dictionary<int,AutomationElement> with the key being the visual position of the AutomationElement, and the value being the AutomationElement itself.
This way you can avoid using a specific Point on your screen (any window size change or element positioning will easily break your code) while not being bound to the AutomationId property.
In the programming of a table-based application module (i.e. the user mostly enters tabular data in an already laid-out table), how would you reject user input for a given cell?
The scenario is: the user edits the cell, enters something (text, picture, ...) and you want them to notice when they finish editing (hitting enter, for example) that their entry is not valid for your given "format" (in the wider meaning: it can be that they entered a string instead of a number, that their entry is too long, too short, they include a picture while it's not acceptable, ...).
I can see two different things happening:
You can rather easily fit their entry into your format, and you do so, but you want them to notice it so they can change if your guess is not good enough (example: they entered "15.47" in a field that needs to be an integer, so your program makes it "15")
You cannot guess what to do with their entry, and want to inform them that it's not valid.
My question specifically is: what visual display can you offer to inform the user that his input is invalid? Is it preferable to refuse to leave the editing mode, or not?
The two things I can imagine are:
using colors (red background if invalid, yellow background for my case 1 above)
when you reject an input, do something like Apple does for password entry of user accounts: you make the cell "shaking" (i.e. oscillating left and right) for one second, and keep the focus/editing in their so they don't loose what they've typed.
Let's hear your suggestions.
PS: This question is, at least in my thought process, somehow a continuation and a specialization of my previous question on getting users to read error messages.
PPS: Made this community wiki, was that the right thing to do on this kind of question or not?
Be careful using autocorrection such as forcing user input to fit your format. See:
Is it acceptable to normalize text box content when it loses focus?.
It’s generally better to prevent invalid entries in the first place than to autocorrect them later. For example, if only integers are allowed, then you ignore any keying of the decimal point (along with all letters and most special characters). In some environments, you may want to provide a quiet audible signal that input is ignored (e.g., a dull thud).
As for when you need to alert the user to an error, how about a callout? Draw a bright line from the control or point in question (field, status annunciator, button, menu, location of a drag and drop) to the margin of the window and put a brief message (two or three words, like "Unrecognized date") in a balloon. Placing the message on the margin should keep it from occluding anything of interest in a crowded table.
The sudden appearance of the call-out should be sufficient to catch user attention, so it's okay to let the user move on to other cells in case they want to fix the error later. For efficiency, you may want to hold the user in the error-related field when the error originally occurs (since often the user wants to correct it right away), but then allow the next tab or mouse click to navigate the user away.
On mouseover or when focus is on the control associated with the error, the line is highlighted (to distinguish it from other callout lines that may be present) and the balloon expands to a full error message, providing more details on how to fix the problem (up to two sentences). Allow the user to drag and drop the balloon to a new location in case this occludes something of interest.
Include a Help button in the expanded balloon for further details. You can also include a button to fix the error (e.g., Retry, Reconnect, or set to default value).
The balloon disappears automatically when the error is fixed. Undo reverts whatever caused the error (e.g., reverts the field to its original value), which should clear the error.
If the user scrolls away from the place associated with the error, the balloon shrinks to an icon that remains in view so that the user is less likely to forget about it. Maybe an exclamation point in a triangle is a good icon. Place the icon beside or in the scrollbar track to indicate its relative location in the table, so the user can quickly scroll to find it later. Mouseover expands the icon to its full message. Perhaps clicking the icon can scroll to the right place in the table and put focus in the relevant control.
Balloons could also shrink to icons if they start visually interfering with each other. You may even want to include a control in a balloon to allow the user to force it to assume an icon.
For consistency, use for all errors, not just those associated with fields in tables.
The last time I did such a form (on a web page) I put a red box around the offending input.
I thought it was really neat... until a user asked me "Why's there a red box around this cell?"
What'd be nice is also displaying why the input's incorrect: "This field accepts only numbers", say.
You could display an icon in the cell, or a tooltip. The tooltip could open automatically or when mouse pointer hovers over the icon. It could disappear automatically when user edits another cell or when some timeout expires.
You can go with arrow tooltips like Adobe Flex's error tooltips. It focuses the attention to the error and supplies a brief description.
I have this application where the users can change text files and when they forget to save them, a little message pops up reminding them that the changes are not saved and asks them if they want to save the changes or not with two buttons "Yes" and "No". It also has a little checkbox that says "Disable this warning". And as the same says, if the user checks it, the message will never pop up again when the text files have unsaved changes.
A couple of questions:
1) Should the checkbox value (if they checked it) be remembered if the user only selects "Yes", only selects "No" or any of them?
2) Let's assume the user checked the checkbox so is not warned again about unsaved changes. What should be the expected behavior the next time the user forgets to save the changes?
Should I always assume a default action (yes: save changes, no: discard changes) after the user disabled the warning? If so, which action?
Or should I always save the changes or always discard the changes accordingly to the last user action right after the he disabled the warning?
What you're doing is a common UI pattern but IMHO I think it's not a good user experience. Here is an alternative that I think is much better:
New files save automatically every minute or so (vary this by how long it takes to save);
It saves to a temporary file;
If the user saves a file then give it a name and save it to that location;
If the program crashes then the temp file is still there. The program should ask what you want to do with it when you start up;
Closing the program should have a simple checkbox "Save Now?" (Yes/No). None of this "Are you sure you want to..." rubbish. Not saving should leave the file as a temp file;
Getting rid of the temp file requires selecting a Discard action (with confirmation of "Discard Now?");
Opening an existing file has the same save every minute functionality except that the saves are to a temporary file. Never modify the original unless the user explicitly saves the file, at which point copy the temp file over the original.
Temporary files should be visible on a collapsible pane (or equivalent) including the date of the last edit and preferably a preview to remind the user what it is;
There should be no option to disable this behaviour. It's not invasive or intrusive. As Joel says, every time you give a user an option you force them to make a decision. Options are way overused.
To specifically answer your question: you should never discard anything unless the user asks you to.
Controlling Your Environment Makes You Happy is a must-read on usability. Don't Make me Think! is too.
Since the checkbox says "Disable this warning", that's exactly what it should do. Don't be wishy-washy with what you're presenting to the users, just do what you say you're going to do!
If they forget to save their changes and they aren't warned, then they should not have checked the box. You are correct to always discard changes when the warning is disabled.
Make the checkbox say '[ ] And always do this'.
Then it's clear that if they select 'No', and check it, it'll always choose 'No', and vice versa.
Or should I always save the changes or
always discard the changes accordingly
to the last user action right after
the he disabled the warning?
I believe that should be the expected behavior. It would be nice if you had a hint on the screen of the default action that will take place.
I recommend the book About Face 3: The Essentials of Interaction Design for some really good GUI designing ideas.
1) You should also have a “Cancel” button that aborts the exiting, allowing the user to return to the document to see if s/he wants to save it or not.
2) “Disable this warning” is a little too geeky. Try, “Don’t show this warning again.” This tells the user that the warning will not be shown and implies no saving will happen in future cases. That’s probably not a good idea, and you should reconsider providing such a warning-suppression feature at all.
3) Far more often in this situation a user will want to save things than not, so that’s what your app really should do if there’s no warning. The checkbox in that case should be “Always automatically save changes when exiting.” This implies no warning will be shown in future cases.
4) If you do 3, you also need an alternative way for user to recover from totally botching up the file and not wanting to save. It could be an Undo dialog that allows the user to make big jumps backwards or maybe a menu item like “Go back to previous saved version.” Ideally, this feature should be available even after the user exits and re-opens the file.
5) If users can be made aware of 4), consider making 3) the default or sole option --don't have the warning at all.
All this assumes that periodic implicit saving is not an option.
Better option is Auto save the document into drafts. It is possible to do that asynchronously.
I say, always automatically save. Forget the dialog. If they want to exit without saving, make that an explicit action on the file menu.
Think of how often you want to save versus those times you don't. The ratio is probably 100 to 1 or even 1000 to one. You want to inconvenience the user 999 times to protect them once?