I am trying to put in a range using a Number Formatter component added to a text file. The problem occurs when I input a consistent sequence of number '9'. The field will keep on adding to what is in there ( i .e. 99999999999) up to a 10th number, and then the field will be changed to a random 6 digit number?
Is that a bug with the Number Formatter? Any workarounds?
Also, can I create my own number formatter? That would be the best if a bug does exist I think.
Thanks!
I have tried the same thing on another version of Xcode and it seems to works fine.. Maybe a problem with that version's number formatter..
Thanks for your help.
Related
I would like to determine the Thousand Separator used while running a VBA Code on a target machine without resolving to calling system built-in functions such as (Separator = Application.ThousandsSeparator).
I am using the following simple code using 'Format':
ThousandSeparator = Mid(Format(1000, "#,#"), 2, 1)
The above seems to work fine, and would like to confirm if this is a safe method of doing it without resorting to system calls.
I would expect the result to be a single char string in the form of , or . or ' or a Space as applicable to the locale on the machine.
Please note that I want to only use a language statement such as Format or similar (no sys calls). Also this relates to Thousands Separator not Decimal Separator. This article Using VBA to detect which decimal sign the computer is using does not help or answer my question. Thanks
Thanks in advance.
The strict answer to whether it is safe to use Format to get the thousands separator is No.
E.g. on Windows, it is possible to enter up to three characters into the Thousands Separator field in the regional settings in the control panel.
Suppose you enter asd and click OK.
If you now call Format(1000, "#,#") it will give you 1a000. That is only the first letter of your thousands separator. You have failed to retrieve it correctly.
Reading the registry:
? CreateObject("WScript.Shell").RegRead("HKCU\Control Panel\International\sThousand")
you get back asd in full.
To be fair, the Excel international properties do not seem to be of much help either. Application.International(xlThousandsSeparator) in this situation will return the separator originally defined in your computer's locale, not the value you've overridden it to.
Having that said, the practical answer is Yes, because it would appear (and if you happen to know for sure, please post an answer here) that there is no culture with multi-char thousand separator (even in China where scary things like 1ε2345δΈ6789 or 1ε2345θ¬6789 exist, they happen to be represented with just one UTF-16 character), and you probably are happy to ignore the people who decided to play with their locale settings in that fashion.
I am trying to convert a user input to a percentage using aurelia converter and Numeral.js.
Here is the gist: https://gist.run/?id=5bbfa902b1d14bff6f506dfcf2045370
The conversion is buggy. Basically, when I am entering the number, it does not behave as expected. Sometimes, I am not able to enter the value, and sometimes it just enters wrong value. The behavior is random.
I am not sure if the error is caused by value converter trying to convert the number at the same time I am typing. Is there a workaround?
It's trying to update on every key stroke. You want it to update after leaving the input. Try using value.bind="score | numberFormat & updateTrigger:'blur'" instead.
You can learn more about binding behaviors in the Aurelia docs.
NSDataDetector is very handy to find different types of dates within a string. (e.g. 2015-03-10 or 10. March 15). This is great but how can I tell NSDataDetector to ignore time patterns only (e.g. "Whatever my text is 2:33 and so on"). NSDataDetector recognises this as - TODAY 2:33
In other words: Can I force NSDataDetector to find full dates only ?
Thanks,
Sascha
You would need to run some post processing. Once you have extracted the list of date found. Loop through each result. Locate the original text used to identify the text and check if the text match your format for instance always a year etc. You can then ignore any of the non full date format.
I am actually looking for the same but could not find anything useful directly built by Apple. Then I come up with this idea. Not idea, but should do the job.
I have the following line of code to set the text of a Dynamic textfield:
boxCopy.text = 'Coming soon: 30th January 2014';
but when I compile the file, it shows as: 'Coming soon: 0th January 201'
I have no idea why this is. The font character set contains all the numeric characters, so it should display it.
Anyone got any ideas?
Thanks,
Stefan
So I figured out that embedding the font's Lowercase, Uppercase, Numeric and Punctauation charcters fixed the problem. Very strange behaviour through because if I typed it into the dynamic textfield in the scene view it worked fine.
Thought I'd keep this question here in case someone has the same issue.
I have this insert command where iam trying to insert a number to be taken from loop
i=0
for line in column:
myStmt.executeQuery("INSERT INTO REVERSE_COL
( TABLE_NAME,COL_NAME,POS) values
(,'test','"+column[i]+"','"+i+"'")
i=i+1
POS IS NUMBER DATATYPE
but it works if i hard code as 1
i=0
for line in column:
myStmt.executeQuery("INSERT INTO REVERSE_COL
( TABLE_NAME,COL_NAME,POS) values
(,'test','"+column[i]+"',1")
I have tried only i , +i+ and other method but its not working any suggestion how to solve this .
Thanks everyone .
I have no jython experience, but I will still try to offer my personal approach and advice. Take from it what you will.
The first thing that I would look into, and perhaps this is something someone else knows offhand, is the way that a number is concatenated to the string. I'm speaking from a C++ background here, but a number i may well be converted to the ASCII character representing that value, and not necessarily the character that you intend.
For example, if i is 9, it may be placing a TAB into the string and not the number 9, which would be an ASCII value 57.
Again, I'm not telling you this IS the answer...but it's the first thing that pops into my mind. Good luck!