In our Aurelia app we utilise barcode scanning on various dialogs. So we created a barcode component. When using a barcode scanner for this component we noticed that some characters are lost during scanning. Within the barcode component we utilise an input field to capture the input of the scanning or user typing into the field - on pressing the enter key the component sends an event containing the barcode - which the dialog intercepts and does some work.
I attempted to get this component to fail in the aurelia skeleton-navigation app (on github "skeleton-navigation\skeleton-typescript") as it does in our application however it works consistently - that is no characters are being lost.
I then went back to our app. If I reduce the barcode component to just a simple input field as below it also fails. If I take out the value.bind or value.two-way the input field has no loss of characters.
<input type="text" value.bind="barcodeValue1"/>
<input type="text" value.two-way="barcodeValue2"/>
There are many difference is the package.json file for example our app is using:
"aurelia-framework": "npm:aurelia-framework#^1.0.0-rc.1.0.2".
aurelia-skeleton is using:
"aurelia-framework": "npm:aurelia-framework#^1.0.0"
There is one solution we can see and that is to introduce a delay on the scanner between characters however we would like the binding to work and were also thinking it may be a bug in Aurelia. We are currently re-writing the component NOT to use the binding ability. The problem in our application occurs in Internet Explorer and works fine in Google Chrome.
This is probably a bug in IE. I believe this problem can be solved by changing the updateTrigger to 'change'
<input type="text" value.bind="barcodeValue1 & updateTrigger:'change'"/>
You can also try debounce
<input type="text" value.bind="barcodeValue1 & debounce">
http://aurelia.io/hub.html#/doc/article/aurelia/binding/latest/binding-binding-behaviors/1
Make sure your scanner is pressing "enter" or "tab" after typing the code.
Related
I'm trying to have users fill out an HTA form, submit it (which will CC them a copy) and have it automatically print to a specific network computer that will only be used for this purpose.
I was able to get the form to basically print the window by using the following code:
<input style="margin-right: 5px;" type="button" name="Print" value="Print" Onclick="print()">
However, that just brings up the print dialog box that makes me choose a printer, and people won't be able to select this printer I need to use.
I've looked and tried a few things, but this has been the only thing that has worked so far. I don't want users to be able to change anything (number of copies, etc.). I just want it to print their input once they click "order".
Thanks!!
-EDIT-
I tried using "window.print()" as the OnClick event of the submit button, which would work, but it just brings up the print dialogue box for users to choose a printer. I need it to just automatically print it out.
I am using html textarea to simulate a command prompt. On typing a command command (e.g. ipconfig) and hitting Enter key, the command output gets appended to to the text. To read the output I have added aria-live="polite" attribute to the textarea which works fine with NVDA screen reader. However, JAWS on IE, starts reading from the top every time a command is entered. How do I make it read only the newly appended text like NVDA does?
So far I have tried aria-relevant="additions", role=log, role=alert attributes but nothing seems to work.
enter code here
<textarea id="commandPrompt" aria-live="polite"
rows="5" cols="45" wrap="off" spellcheck="false">
</textarea>
IN theory, you should be able to define precisely what should be read using aria-relevant and aria-atomic.
Unfortunately, Jaws doesn't follow standards very well. These two attributes are known not to always work as expected with Jaws, depending on the browser used, the element to which they are applied, etc.
This is probably not the answer you wanted to have, but if Jaws doesn't do what you expect, the only solution is most likely to put the text to be spoken in another element.
In a div or span you are much more mikely to have the expected behavior.
I'm looking to use the number_field_tag as it works great on mobile devices to allow the user to input with a 10 Key interface. However, the data that they will be entering on their mobile device may contain sensitive information (i.e., part of their Social Security Number).
How can I mask the inputted data as it is being typed while maintaining the 10 Key interface? By using the password_field_tag, it would revert the keyboard to a standard QWERTY.
Not really ruby-on-rails specific, but you could use this in HTML to get a password input that only accepts digits and shows the numeric keyboard on some mobile devices.
<input type="password" pattern="\d*">
I found a CSS solution that works on my mobile. I can use the webkit option to do this.
input[type=number] {
-webkit-text-security: disc;
}
Or for just a particular class as well.
.employee {
-webkit-text-security: disc;
}
Works on Galaxy S4 and Chrome so far with what I've tested.
The best iOS keyboard for entering USD currency values (pictured below) includes numbers 0-9, the decimal symbol, the comma symbol, and the dollar sign. As far as I know, the only way to get this keyboard on Mobile Safari is to use <input type="number">.
Unfortunately, iOS currently has built-in validation for the number input type which screens out commas and dollar symbols. Since this validation "feature" is embedded in the browser and Mobile Safari hasn't yet implemented the novalidate directive, there is currently no way to do this validation manually.
Using <input type="text"> would obviously solve the validation problem, but it also would bring up the regular alpha keyboard, which is not acceptable for my current project (a financial calculator).
I'm on the verge of doing something crazy, like using JavaScript to quickly switch the type from number to text after the input receives focus. I'm grasping at straws here. Any ideas?
For now, JavaScript is the only solution. Here's the simplest way to do it (using jQuery):
HTML
<input type="text">
JavaScript
$('input[type="text"]').on('touchstart', function() {
$(this).attr('type', 'number');
});
$('input[type="text"]').on('keydown blur', function() {
$(this).attr('type', 'text');
});
The idea is simple. The input starts off and ends up with type="text", but it briefly becomes type="number" on the touchstart event. This causes the correct iOS keyboard to appear. As soon as the user begins to enter any input or leave the field, the input becomes type="text" once again, thus circumventing the validation.
There's one downside to this method. When the user returns to an input that has already been filled out, the input will be lost (if it doesn't validate). This means the user won't be able to go back and edit previous fields. In my case, this isn't all that bad because the user may want to use the calculator over and over again with different values, so automatically deleting the input will save them a few steps. However, this may not be ideal in all cases.
You can use the attribute pattern for your input field as text. This instructs mobile safari to bring up the numeric keyboard. Try something along the lines of:
<input type="text" pattern="\d*" />
Just change your pattern regex to what you want.
Here is more information on the pattern attribute
UPDATE
After reading Apple's Documentation on managing Text in Webviews it seems like you are out of luck. You will have to do some javascript magic to do what you want.
The mobiscroll documentation states
This preset enhances a regular HTML select to select the values with a scroller. The original select is hidden, and a dummy input is visible instead. The value of the select is maintained by the preset.
The sample HTML code they provide uses inline styling to hide the original select element
<select name="City" id="select" style="display:none">
However, when I do this and setup the mobiscroll replacement to appear inline
$('#select').scroller({preset:'select',theme:'default',display:'inline',mode:'scroller',inputClass: 'i-
txt'});
I find that although the scroller appears I still end up with what looks like an input element above it. This does not happen in their demo code but there I note that what they do is something like this
<div id="select_cont" style="display: none;">
<select name="City" id="select">
but that simply hides everything including the mobiscroll replacement. Looking under the covers I found that calling
$('#select').scroller({preset:'select',theme:'default',display:'inline',mode:'scroller',inputClass: 'i-
txt'});
introduces a dummy input element into the DOM.
<input id='cities_dummy'...
I can get the dummy to hide itself by issuing a
$('#cities_dummy').css('display','none')
immediately after creating the scroller. However, I cannot understand why things are working differently in the demo code. I have noted that they are using jQuery Mobile v 1.1.1 whilst I am using the very latest version.
Perhaps this issue is related to versions? Or is there something else at play here? I'd much appreciate any help.
I figured it out. It is all down to the
inputClass:i-txt
bit in the scroller options settings. In the demo code they are probably playing with this class via script depending on the value of the display property in the options object. The point is this - in order to get the original select to disappear when the scroller display is set to "inline" you must define i-txt (or whatever input class you use) as
.i-txt{display:none}