I have a <input type="number"></input> field and when I try to put in a decimal as the first character, it comes up as invalid (I have an ng-change firing).
.5 won't work, but 0.5 is valid. Is there something I can do about this?
Per the HTML spec, .5 is valid for <input type="number">.
So, you’re right, and the tool (browser? Angular?) that validation error’s originating from is wrong.
As far as how to deal with it—how to work around it—I don’t know what to suggest, but as someone who actually works on the specs for this stuff, I would like to ask you to please at least file a bug against whatever tool is (mis)performing the actual validation that’s causing you to see that message. If nobody takes time to report spec-conformance bugs like this (but instead everybody works around it by just putting, e.g., 0.5 to get past it), then the bugs never get fixed.
Anyway as far as evidence for my assertion that .5 is in fact valid: The HTML spec is pretty clear on this; see the section defining what a valid floating-point number is:
A string is a valid floating-point number if it consists of:
Optionally, a U+002D HYPHEN-MINUS character (-).
One or both of the following, in the given order:
A series of one or more ASCII digits.
Both of the following, in the given order:
A single U+002E FULL STOP character (.).
A series of one or more ASCII digits.
Optionally:
Either a U+0065 LATIN SMALL LETTER E character (e) or a U+0045 LATIN CAPITAL LETTER E character (E).
Optionally, a U+002D HYPHEN-MINUS character (-) or U+002B PLUS SIGN character (+).
A series of one or more ASCII digits.
Along with that evidence from the spec itself, here’s a record of other supporting evidence: There was in fact a time when the HTML spec didn’t allow .5 but instead required it to be written as 0.5; however, after a “Floating point numbers beginning with a dot should be valid and parsed correctly” bug was raised against the spec, the spec was subsequently changed (in 2011) to state what it currently states (that is, too allow, e.g., .5).
So, any tool that’s flagging .5 as an error likely has not been updated in this regard since 2011, and so it regardless is in need of its maintainer(s) to go back into their code & evaluate their code against the current spec requirements, to make sure they are conforming to the current spec.
I hope the above provides enough ammunition to use in raising a bug against the responsible tool.
If you want all the input numbers to be valid then you can set in your input field step to "any". It works all integers and decimals numbers. Like -
<input type="number" step="any" />
Related
<XamCurrencyEditor FormatProvider="{Binding Path=CurrencyFormat.CurrencyFormatInfo}"
Mask="{Binding Path=CalculatedMask}" />
CurrencyFormat.CurrencyFormatInfo is a NumberFormatInfo calculated from our currency format business object. CalculatedMask is set to "{currency:-22.2:c}", which allows positive or negative currencies with up to 22 digits before the decimal and 2 after.
I would like the editor to allow either parenthesis or a minus sign for negative values:
$ -123.45
($ 123.45)
CurrencyNegativePattern is already set to 0. I tried changing the Mask to "{currency:(22.2):c}", but that is just inserted as a literal string. Will I have to generate a custom format string to get the desired behavior?
As a partial solution, adding Format="C" causes the editor to fully respect the FormatProvider when formatting its value.
<XamCurrencyEditor FormatProvider="{Binding Path=CurrencyFormat.CurrencyFormatInfo}"
Mask="{Binding Path=CalculatedMask}"
Format="C" />
The editor still refuses to accept parentheses. If anyone from Infragistics is reading, please consider this a feature request.
I recently started learning and using microsoft access. However, I am afraid that there is something really bothering me. It's connected with the validation rules. So here is my problem:
I had to validate a field so that only letters could be written. Of course I googled it and found the proper syntax. (Is Null or Not Like "*[!a-z]*")
At first I tried with (Is Null or Like "*[a-z]*"), which I think should be the same as the above one. It's checking every symbol from the string whether it is between 'a'and 'z' and that is why it is used with the obelisk * symbols from the both sides. Am I right?
My question is: Why is the second one not working, although it is a double negative equivalent to the first one. Will be happy for any explanation. Thanks in advance!
P.S Sorry if the question seems useless for you but I really do want to figure out where I am mistaking.
Consider the string 'a1b'.
Like "*[!a-z]*" will search the string for any character that is not in the range 'a'..'z'. It finds the '1' in the second position and returns True. Therefore, Not Like "*[!a-z]*" returns False.
On the other hand, Like "*[a-z]*" searches the string for any character that is in the range 'a'..'z'. It finds the 'a' in the first position and returns True.
can any one explain why(how) the xtype: numberfield value is going to auto correct(change) if am providing more than a 16 digits value.
For Example:
22222222222222222 is changed to 22222222222222224
222222222222222222 is changed to 222222222222222200
2222222222222222222 is changed to 2222222222222222300
22222222222222222222 is changed to 22222222222222220000
222222222222222222222 is changed to 222222222222222230000
2222222222222222222222 is changed to 2.2222222222222222e+21
22222222222222222222222 is changed to 2.2222222222222223e+22
Which results in my page after rendering as shown below when get the value through in my component jsp page
NumberFieldTestValue:<%= properties.get("numberfieldname","") %>
Resulting as below
NumberFieldTestValue: 2.2222222222222223e+22
The problem
This behavior is caused by the fact that the dialog behavior is implemented in JavaScript. The numbers you're having problems with cannot be represented in it.
The language conforms to the ECMASCRIPT 5.1 specification.
To quote the Number type description
all the positive and negative integers whose magnitude is no greater
than 2^53 are representable in the Number type
The base 2 logarithm of 2222222222222222222222 is about 70, which means the number exceeds the maximum value. Hence your problems.
All in all, if you check your examples in a plain JS console in a browser, the same behavior will be displayed so this is not really a CQ problem.
Solution 1 - use a different type
To avoid this, you could potentially use xtype="textfield" and validate it against a regular expression to see if it consists of numbers only. Then you'd have to make sure to use a type capable of holding such numbers at the backend (like BigInteger).
The field could look like this:
<numberOfSandGrains
jcr:primaryType="cq:Widget"
fieldLabel="Number of grains of sand at the beach"
name="./grainsCount"
regex="/\d+/"
regexText="Please enter a numeric value."
xtype="textfield"/>
Solution 2 - change scale
Another option is to change the logic behind the configuration and use some different units if applicable. For instance, if the value 2222222222222222222222 is a number of grams (weight of an object/substance), it makes perfect sense to read it in metric tons instead (at least in many cases). The author could probably do without entering such humongous numbers.
You'll need to be extra-careful if you go this way.
I'm brand new to VXML (and coding in general) and apparently what I'm trying to do is... not normal, but hopefully it can be done.
I understand the principle concept of DTMF input with VXML where I use:
<grammar mode="dtmf"><![CDATA[ (*|0|1|2|3|4|5|6|7|8|9)<2-31> ]]></grammar>
<prompt>something here</prompt>
<noinput-nomatch-filled>conditions</noinput-nomatch-filled>
What I'm trying to do is take multiple actions to allow DTMF entry of letters based on their placement on the dialpad. You'd achieve this by first dialing the number that the letter is on (2-9), and the placement of that letter (1-4).
For example: "E" would be 3 and 2 on the dialpad.
I'm at a complete loss as to how this would work in VXML. What I'd like to do is this:
1) PROMPT: Please input your THREE letter code. Please enter your first letter.
2) Expect two DTMF inputs the first number between 2 and 9, the second number between 1 and 4. Based on this logic (33 = F, 94 = Z) the letter is set.
3) PROMPT: The letter you have entered is (INPUT). Is this correct? Press 1 for yes, 2 to retry.
4) Retry or go onto the next letter. So on and so forth.
If anyone has resources so I can stumble upon the answer to this myself, that'd be great! If anyone would like a bounty... that's an option, too! Thank you for reading!
The typical approach to this problem is just accept twice the number of tones as you expect or use a pound terminated input. Then use ECMAscript or server side code to translate the tone strings into the desired letters.
There are a couple of a ways to approach this problem:
1) You could just accept all 2 digit numbers in the grammar and do all validation/calculation on the server side.
and/or
2) Do some validation in the <filled> section and letter-decoding-from-number on the server-side (and then come back with the result and check with the user if that was the intended letter).
For the two-digit grammar, you could parameterize the built-in digits grammar as follows (please note that the URI scheme is platform-specific, so you may need to refer to the user manual of your voice browser to be sure of the exact scheme to be used)
<field type="digits?length=2">
<prompt>Please enter the code of the first letter</prompt>
</field>
There are other ways as well, like you could also do letter-decoding on the client-side using a script on the same page, but hopefully the above gives some ideas on what to choose based on your requirement.
(Actually, the OP would probably not be looking for an answer to this question after so long but hopefully it helps others who landed on this page searching for a solution to a similar question)
The best way could be to define a grammar that link each value to the result letter :
<grammar mode="dtmf" root="letter">
<rule id="letter">
<one-of>
<item>32<tag>E</tag></item>
...
</one-of>
</rule>
</grammar>
Another way is to let the user enter the 2 letters and process it with a EcmaScript function, or use the tag .
I am going to plan to add such feature in the Voximal the VoiceXML interpreter for Asterisk.
But are you sure that the users can be able to understand and use this method to enter letters ?
I've got a FlowDocument generating a document for a client, and it's getting a line break that they don't like. Is there any way to mark a section of text that it should avoid line breaks? Something like this:
<Paragraph>Here is a paragraph where there should be <span NoLineBreak=True>no line break</span> in a certain part.</Paragraph>
Obviously, a Span doesn't have a NoLineBreak property, but I'm wondering if there's some equivilant functionality available, or if someone can get me started on a way of implementing a SpanWithNoLineBreak class or RunWithNoLineBreak class?
UPDATE
Actually, one issue I'm having is with a percent sign, where there isn't even a space:
<Paragraph>When I print and ½% I want the one-half and '%' symbols to not line break between them.</Paragraph>
The & #x00BD; is the unicode for a ½ symbol. I'm getting a line wrap between the 1/2 and the % even though there's no space between them.
The Unicode character "Word Joiner" (U+2060) is intended for just this purpose. It "does not normally produce any space but prohibits a line break on either side of it" (Wikipedia). You place it between U+00BD and '%' to prevent a line break between them.
Unfortunately, WPF (or perhaps the typical fonts supplied with Windows) don't support it properly, and instead render it as a square box. As an alternative, you could use U+FEFF; the use of this character as a zero-width non-breaking space is now deprecated (it's reserved for use as a byte-order mark), but it worked as a line-break-preventer for me.
Finally, there are some other characters that can also be used for this purpose: U+202F (narrow no-break space) also prevents breaking, but also renders as a very thin space. U+00A0 (no-break space) prevents breaking and displays as a normal space.
Try replacing the spaces with non-breaking spaces.
EDIT: Well there's always the backup plan of just putting in TextBlocks in your FlowDocument with TextWrapping=NoWrap, but I'd try to find a better way...