Windows 10 Mail app converts some numbers to links/contacts automatically in html emails.
Usually numbers or part of numbers with 000-s:
How can i stop this?
I've tried with "text-decoration:none; text-transform:none;" but it didn't worked.
Thanks!
This is very common, and occurs also in many mobile apps. What they are trying to do is be 'helpful' and convert them to phone numbers (typically).
To get rid of this, you can add an odd character that will break their find & replace: (zero-width non-joiner)
So in full:
Test number: 7 000 000 000 USD
You'll need to do this to break any combination of 6 or more numbers.
Related
I am building a text editor app. I want to implement numbers & bullets like apple's notes app. For numbers I am using "1." (number + full stop). Now the problem is when I try to remove "1." using backspace, I will have to press backspace twice because "1." treated as two characters. This problem becomes worse when my list reaches "10." or "100.".
I have been looking into unicode characters. There are unicodes for "1." (\u{2488}), "2." (\u{2489}), but these are upto "20." (\u{249B}) only. I could not find more than that anywhere.
Can you give me a solution or a different approach to solve my problem ?
Thank You !
Users who are used to working with another software package would like to type just the numbers of dates, without slashes: 0 9 1 8 2 0 1 7. They have developed "muscle-memory" for dates and are pretty grumpy about having to enter the slashes.
This is a "heads down" data-entry scenario where they have to enter hundreds of dates, and speed is a concern. They say that they often have to enter dates from previous years, and it takes too long to navigate to the past years using the dropdown calendar.
Is there a mode setting for the DevExpress DateEdit for Winforms which allows that mode of entry?
Try to specify a mask, I think it should work.
Set mask property, as you need.. but you must be clear what type of date format user will enter
This
is the link I learned to send multi-part SMS in PDU, a very good tutorial.But how if I want to send Unicode SMS? From one of the comment from the developer:
Yes, the DCS should be 0×08 and the UDL should be in octets (which ends up being 1 + UDHL + 2 * number of characters). Also you don’t have to insert padding as in the GSM-7 case. I know you’ve already managed to send UCS-2 (not concatenated) messages, so it must be something small you’re missing. If you wish you can post your PDUs so I can check…
Jeroen
it seems I do not need to add 1 bit padding for the message. But if I using the same UDH format as normal SMS it will just show me unknown characters.
Can anyone give me some hints?
This is the sample PDU with chinese character but should be with errors..
0041000B910661345542F60000A00500030302010008044F60597D
Thanks.
Your DCS is wrong.
0041000B910661345542F6000*0*A00500030302010008044F60597D
should be
0041000B910661345542F6000*8*A00500030302010008044F60597D
for a DCS of 0x08 = UCS-2 encoding.
Is there a way to convert a unicode character to a Mac virtual keycode? (without building my own table?) It looks like on Windows there is VkKeyScanEx, but I'm not aware of a similar function for Cocoa on OS X.
I'm actually trying to do this for the iPad. I want to convert character taken from the keyboard and convert them into key codes, since the iPad keyboard won't supply keycodes.
The ShortcutRecorder project on GoogleCode has an NSValueTransformer subclass for converting strings to keycodes and vice versa, but I'm not sure if it'll work on iOS. It's a great place to start looking, though.
I'm interested in the reason why it needs to be tagged iPhone/iPad — surely you can do all the conversion in OS X? Also, the iPhone/iPad "keyboard" is fundamentally a text input method (see UITextInput) —it's not that it "won't supply keycodes"; there simply aren't any (and what keycode/modifiers should it supply when you tap "A", hold for a bit, and pick a random accented version?).
If you're going to do this, test it on a variety of (odd) input methods on both the iPad and OS X. If there's an API to insert a string, do so (but this might not work so well for games which read scan codes...). You could even write a custom input method extension which accepted Unicode strings.
It's debatable what should happen when a Dvorak VNC client types to a QWERTY VNC server...
I'll end with a tangential story:
A little over a year ago (before I got an iPhone), I got a N810. If anything, it makes a half-decent SSH/VNC client and has a decent keyboard.
Except it's not a standard keyboard. 1 is Fn-Q and ! is Fn-A, but when I type Fn-A to get "!", the VNC server ends up typing "1". Typing Shift-Fn-A gives me the "!" I was looking for (I think Shift-Fn-Q also works).
Something, somewhere, parses the character "!", decides that it has the same scan code as "1", and types the scan code for 1 with no modifier. It could automatically hold down Shift. It might even be able to insert a string. Instead, it just fails.
Are there any modules that can help me compare phone numbers for equality?
For example, the following three numbers are equivalent (when dialling from the UK)
+44 (0)181 1234123
00441811234123
0181 1234123
Is there a perl module that can tell me this?
The closest I can see on CPAN is Number::Phone which is an active project, and supports UK Phone numbers. It should work for the specific example you give. A few countries are supported.
If you've got phone numbers for other countries things could get more difficult due to local formatting idiosyncrasies.
Supposing that the code you need doesn't exist, and you have to write it yourself, there are two basic operations that you need to do:
Apply context. This is where you take the location of the dialing phone into account. If the call isn't international, you supply the country code; if the call isn't long-distance, you provide an area code, etc. This requires some rules per-locale, of course.
Normalize. Remove meaningless spaces and punctuation, convert the international dialing prefix ("011" in NANPA, "00" in most of the rest of the world, but occasionally many weirder things) to the standard "+".
After completing those two steps properly, all inputs that are actually equivalent numbers should give identical output strings.