I've have quite strange situation here.
https://codesandbox.io/s/7myoj9zp3q
When I want to add new row, I am able to add a new inputs (append to state null values), but I am able to type only one character a time (input looses focus). Am I missing some events or what?
PS - I know that there might be another way around (adding to state ready/almost ready object), but I wanted to get this variant to work.
Fixed by following suggested way read on Mutations Follow Vue's Reactivity Rules https://vuex.vuejs.org/en/mutations.html#mutations-follow-vues-reactivity-rules:
Vue.set(obj, 'newProp', 123)
Related
I'm trying to get a text from a textfield with Get Text, but in some cases this field is optional and the robot crashes because it doesn't have anything in the field.
You have multiple options. It's hard to say which one fits best you so here is a pool of possible solutions:
when NOT using the Modern Design, you can easily use the Element exists activity, self explaining
if you use the Modern Design and miss old activities like Element exists, go to the filter dropdown and select Show Classic, this way you are now also able to choose Element exists
you could also wrap such failing activities into a Try Catch, then your process wont fail, but a Try Catch should always be the last way out
when using the Modern Design, you can try Find Element, if the returned object is empty you know that it was not found, make sure to set a proper Timeout here, otherwise you wait for 30 seconds
but on your case it could be better to use an Image exists or Find Image Matches as you said you are looking for text in a textfield, just inverse it and look for an empty textfield, and if you have no matches all is fine
But to be honest, I would go for the Element exists. Give this a try, but be aware that in the future this activity might be replaced by something else and your process will need a little bit of rework.
I have the following problem:
I want to avoid that one field of the copied row gets copied into the new row. (ME51n)
I thought that I could search somewhere in the debugger for this field name.
Example:
first row has the MATNR: 100-1-15
now i want to search in the debugger for the field MATNR. Is this possible?
(I know this example does not make sense, but my field is not used that often because it's an self-created field)
Or is there an user-exit especially for that?
Use watchpoints for that particular aim that you stated. In official documentation you can learn how to do it. The problem of finding suitable user-exit is not related to original question.
In the very common scenario where you have a textbox, and some kind of validation rule which constraints the valid entries on that textbox. How should a failing validation affect the content of the textbox especially in the case when there originally was a valid value entered before the invalid.
Example: Imagine a form where one can enter a number between 0 and 50. The user enteres 40. Everything is fine. But then the user goes in and changes it to 59.
Obviously IMHO the application should inform him about his mistake asap. But what to do with the values? I think there should be a way back to the 40 as an easy way to a valid state, but I'm not sure when and how to revert it: On focus lost? Only on a special key/ button press?
What do you think?
Edit: I absolutely agree with the first two answers: changing the input automatically is a bad idea. Yet I would like to keep the 'last valid' value available ... Maybe a clean UnDo feature would to the trick?
The approach that I take to field validation like this is pretty simple:
Thou Shalt Not Discard the Users Input
If the entry made by the user is invalid, flag it as such - but don't change the value.
The reasoning behind you is simple - consistency.
Consider, for example, a pair of fields used for entry of a date range where "valid" means that the start date is before the end date.
Now, the user wants to enter a completely new range.
If your system discards invalid entries immediately, you force your user into different behaviour. For entry of an earlier date range, the start date must be entered first; for entry of a later date range, the final date must be entered first. Unfriendly.
Instead, respect the users input - when the start date is entered, freely flag it as invalid, but leave the value in place. Then, when the final date is entered, both fields now validate.
This is also motivation for displaying validation dynamically (as values are changed), but for not limiting the users movement between fields.
Depends on you functional specs really, but yeah falling back to the previous correct value sounds like a good practice ... for a blocking error which will always be blocking.
However do you really want to block your user there? What if the valid range is 0-50 when option b is selected but becomes 0-60 when option c is selected? And the user decides to change the ranged value first? Then the user will be very frustrated at having lost what she considers a perfectly valid value...
Keep that in mind when automatically reverting a change made by a user :) The user may have made a mistake but may also have made the change intentionnaly because he associated it to another change in his mind but can't change both at the same time in the application...
Warn that the value is invalid and let ctrl-Z cancel the stuff the user put there may be a more sensible default.
#Bevan Thou art righteous.
If you want to see an example of how annoying it can be crack open Google Analytics
This unfriendly behaviour is exactly what Google Analytics does when you try to compare dates, and it drives me crazy.
If you enter an end date which is before your start date, it discards your entry and thus forces you to enter information in a prescribed sequence.
It also means that small typo's can mean you being forced to retype a whole date, which just sucks.
I agree with the other answers in not changing the user input, you cannot tell what about it may be wrong, perhaps it was a typo, an missing decimal, swapped day/month/year fields, etc. An undo option to allow them to revert back to previous might be an added nice feature however.
The main items in my view are:
- make it clear what the valid ranges and formats are BEFORE the user enteres the data in the form, via examples or other similar indicators.
- be sure to indicate mandatory fields clearly prior to submision.
- user controls that limit the user to entering valida data - date pickers, spin controls, numeric only controls, max lengths set on textboxes, etc.
- make it clear when validation fails as to what item(s) on the form are invalid and why they are invalid, not just a simple "data is incorrect" global message, espeically if you have a long form with many fields that could have validation issues.
Very simple question: should a dropdown list be used to populate state abbreviations? From my experience, I think most e-commerce sites do this so I would expect that it's acceptable. However, Jakob Nielsen has something to say about this.
I think I disagree; I use the tab key then type the first letter of my state. Heck, even if it wasn't the first entry, I've done this enough times, I would hit the letter repeatedly and get to what I need. I never need the scroll wheel or mouse.
Is there any additional concrete guidance out there on this particular question?
I think this will become less of an issue now that most modern browsers scroll the drop down lists based on each consecutive letter you type, not just reading the first letter as they once did. So, If you type N-Y, the drop down list will scroll directly to NY and you do not have to hit N a bunch of times.
Since a state is a two letter abbreviation, I wouldn't put a drop downlist, I would put a textbox, but I would validate it using AJAX or Javascript to warn the user about an error, right after he entered something wrong.
DropDown / Auto-completion (in my opinion) is useful when the data to enter is longer / more error-prone.
If you insist on using auto-completion or dropdown, you should put long state names, not just the abbrev.
I don't know about concrete guidance, but one alternative I would consider is using an autocomplete text box that forces you to choose from one of the available choices. I agree that a 50-item drop down list is too long and using autocomplete with enforced choice accomplishes the same purpose -- consistent data -- and has the advantage that it is much easier for the user to navigate. If you don't want to limit the choices to just US states you could drop the enforced choice and just let the autocomplete work as a suggestion with the user being able to enter free-form input.
EDIT: As #Martin suggests, I would probably have the autocomplete show the full state name, even if it only entered the abbreviation. This would solve issues of people getting the abbreviation wrong as well, though you could do the same thing in a drop down -- display the name with the abbreviation as the value.
I was going to post NYSystemsAnalyst's answer, but he beat me. I will instead add a caveat... If you use a dropdown list, it must be complete. Do not forget the obvious DC, or the less common but plausible PR or AE/AA/AP, or the rather improbable but still valid AS, FM, MH, MP, PW, and VI.
The official list
I think it depends on if you are asking a user to enter their own address or someone else's address (ship to address). Everyone knows their own state abbreviation, but may know all the state abbreviations.
So for entering your own address a textbox is the quickest and easiest way, but if you are asking the user to potentially enter someone else's address a drop down is probably best.
Of course, if you site has a combination of both types of address, you want your UI to be consistent and use the drop down for both. Also, if you are using a drop down, I would suggest using the state abbreviation and name (AZ - Arizona) when the drop down is expanded (but just show the abbreviation when it is collapsed).
I'm willing to bet that half the users of online e-commerce sites don't know the abbreviations for the states. Think if you're shipping a gift to someone and you can't remember whether its MS, MO or MI. Dropdowns are fine.
I've never had an issue with state drop down boxes (and this is from someone routinely at the bottom in West Virginia). I've gotten into the habit of just tabbing and pressing W and then it will either recognize the "E" and give me the correct state, or it will not recognize the "E" and then I have to hit the down key once or twice (depending on sort order) to get the proper state.
So all in all I am looking at 5 key presses max to get to my state. I don't think it's that bad.
How about a textbox with validation, and a drop-down list if the state abbreviation is invalid?
I've been reading up on LINQ lately to start implementing it, and there's a particular thing as to how it generates UPDATE queries that bothers me.
Creating the entities code automatically using SQLMetal or the Object Relational Designer, apparently all fields for all tables will get attribute UpdateCheck.Always, which means that for every UPDATE and DELETE query, i'll get SQL statement like this:
UPDATE table SET a = 'a' WHERE a='x' AND b='x' ... AND z='x', ad infinitum
Now, call me a purist, but this seems EXTREMELY inefficient to me, and it feels like a bad idea anyway, even if it weren't inefficient. I know the fetch will be done by the clustered primary key, so that's not slow, but SQL still needs to check every field after that to make sure it matches.
Granted, in some very sensitive applications something like this can be useful, but for the typical web app (think Stack Overflow), it seems like UpdateCheck.WhenChanged would be a more appropriate default, and I'd personally prefer UpdateCheck.Never, since LINQ will only update the actual fields that changed, not all fields, and in most real cases, the second person editing something wins anyway.
It does mean that if two people manage to edit the same field of the same row in the small time between reading that row and firing the UPDATE, then the conflict that would be found won't be fired. But in reality that's a very rare case. The one thing we may want to guard against when two people change the same thing won't be caught by this, because they won't click Submit at the exact same time anyway, so there will be no conflict at the time the second DataContext reads and updates the record (unless the DataContext is left open and stored in Session when the page is shown, or some other seriously bad idea like that).
However, as rare as the case is, i'd really like to not be getting exceptions in my code every now and then if this happens.
So my first question is, am I wrong in believing this? (again, for "typical" web apps, not for banking applications)
Am I missing some reason why having UpdateCheck.Always as default is a sane idea?
My second question is, can I change this civilizedly? Is there a way to tell SQLMetal or the ORD which UpdateCheck attribute to set?
I'm trying to avoid the situation where I have to remember to run a tool I'll have to make that'll take some regexes and edit all the attributes in the file directly, because it's evident that at some point we'll run SQLMetal after an update to the DB, we won't run this tool, and all our code will break in very subtle ways that we probably won't find while testing in dev.
Any suggestions?
War stories are more than welcome, i'd love to learn from other people's experiences on this.
Thank you very much!
Well, to answer the first question - I agree with you. I'm not a big fan of this "built in" optimistic concurrency, especially if you have timestamp columns or any fields which are not guaranteed to be the same after an update occurs.
To address the second question - I don't know of any way to override SqlMetal's default approach (UpdateCheck = Always), we ended up writing a tool which sets UpdateCheck = Never for appropriate columns. We're using a batch file to call SqlMetal and afterwards running the tool).
Oh, while I think of it - it was also a treat to find that SqlMetal also models relationships to set a foreign key to null instead of "Delete On Null" (for join tables in particular). We had to use the same post-generation tool to set these appropriately too.