In NSEvent in key down event it has characters property and it has a character like 'a' as the first character when you hit a key 'a'.
When I hit down-arrow key I get 63233 as a decimal expression of the first character.
I wonder what is the number and I found that 63233 = 0xF701 is in a private area in Unicode according to http://en.wikipedia.org/wiki/Private_Use_(Unicode) .
What I want to know is how and where they are defined. Is there any document which lists up all the character mappings used in Cocoa??
The NSText class reference contains the character mappings of common command and modifier keys. The Down Arrow key is specifically defined as NSDownTextMovement = 0x16. A more complete list can be found in HIToolbox, a sub-framework of Carbon in Events.h
Related
I'm working with an API that returns an array of objects. I can get all the keys, but two of those have numbers as keys, and I cannot get it. Give me an error.
I really dont know why I can not get it those keys.
Is there something different due to are numbers?
BTW Im using axios.
If you're using dot notation, you should change to bracket notation to access properties start by a number.
The code below uses dot notation, it throws an error
const test = {"1h" : "test value"};
console.log(test.1h); // error
Why :
In the object.property syntax, the property must be a valid JavaScript
identifier.
An identifier is a sequence of characters in the code that identifies a variable, function, or property.
In JavaScript, identifiers are case-sensitive and can contain Unicode letters, $, _, and digits (0-9), but may not start with a digit.
The code below uses bracket notation, works fine
const test = {"1h" : "test value"};
console.log(test["1h"]); // works
Why :
In the object[property_name] syntax, the property_name is just a
string or Symbol. So, it can be any string, including '1foo', '!bar!',
or even ' ' (a space).
Check out the document here
The ANTLR4 lexer pattern [\p{Emoji}]+ is matching numbers. See screenshot. Note that it correctly rejects alpha chars. Is there an issue with the pattern?
\p{Emoji} matches everything that has the Unicode Emoji property. Numbers do have that property, so \p{Emoji} is correct in matching them. Why though?
The Unicode standard defines any codepoint to have the Emoji property if it can appear as part of an Emoji. Numbers can appear as parts of emojis (for example I think shapes with numbers on them, which for them reason count as emojis, consist of a shape, followed by a join, followed by the number), so they have that property.
If you only want to match codepoints that are emojis by themselves, you can just use the Emoji_Presentation property instead. This will fail to match combined emojis though.
If you want to match any sequence that creates an emoji, I think you'll want to match something like "Emoji_Presentation, followed by zero or more of '(Join_Control or Variation_Selector) followed by Emoji'" (here you want Emoji instead of Emoji_Presentation because that's where numbers are allowed).
However, for the purpose of allowing emojis in identifiers (as opposed to a lexer rule to match emojis and nothing else), you don't actually have to worry about whether a number is part of an emoji or not, just that it doesn't appear as the first character of the identifier. So you could simply define your fragment for the starting character to only include Emoji_Presentation and then the fragment for continuing characters to include Emoji as well as Join_Control and Variation_Selector.
So something like this would work:
fragment IdStart
: [_\p{Alpha}\p{General_Category=Other_Letter}\p{Emoji_Presentation}]
;
fragment IdContinue
: IdStart
// The `\p{Number}` might be redundant, I'm not sure. I don't know
// whether there are any (non-ascii) numeric codepoints that don't
// also have the `Emoji` property.
| [\p{Number}\p{Emoji}\p{Join_Control}\p{Variation_Selector}]
;
Identifier: IdStart IdContinue*;
Of course that's assuming you actually want to allow characters besides emojis. The definition in your question only included emojis (or was meant to anyway), but since it was called Identifier, I'm assuming you just removed the other allowed categories to simplify it.
Looking at the code that seems to define emoji code points:
UnicodeSet emojiRKUnicodeSet = new UnicodeSet("[\\p{GCB=Regional_Indicator}\\*#0-9\\u00a9\\u00ae\\u2122\\u3030\\u303d]");
it looks to be including digits (why, I don't know, checkout sepp2k's excellent explanation). You can always raise an issue if you think something is wrong.
You could also just use a character class like this instead:
Identifier
: [\u00a9\u00ae\u2000-\u3300\ud83c\ud000-\udfff\ud83d\ud000-\udfff\ud83e\ud000-\udfff]+
;
I'm trying to automate keyboard typing with UI Automation.
target.frontMostApp().keyboard().typeString("INTERCOM")
But i will get this error after first 'I' is typed
target.frontMostApp().keyboard() failed to locate key 'N'
Script threw an uncaught JavaScript error: target.frontMostApp().keyboard() failed to locate key 'N'
I have a localized swedish keyboard.
Anyone know if this a bug or something I've missed?
This might help:
var vKeyboard = target.frontMostApp().keyboard();
vKeyboard.setInterKeyDelay(0.1);
vKeyboard.typeString("INTERCOM");
By default this delay is set with 0.03 seconds. This is not enough for your application to update the keys on your keyboard. Increasing this timeout between determining keys for typeString keyboard method will help you. There is no description for setInterKeyDelay on UIAKeyboard reference page but this method is available for UIAKeyboard.
Also I'm not sure about other languages. I do not know if typeString allows to type on other languages but this 100% works for English keyboard for iOS 5.x.
try{
target.delay(1);
target.frontMostApp().mainWindow().textFields()[0].tap();
target.delay(1);
target.frontMostApp().mainWindow().textFields()[0].setValue("INTERCOM");
}
catch(err){
target.delay(1);
target.frontMostApp().mainWindow().scrollViews()[0].textFields()[0].tap();
target.delay(1);
target.frontMostApp().mainWindow().scrollViews()[0].textFields()[0].setValue("INTERCOM");
}
I've had this problem as well and I believe it's a case of the string being typed too quickly.
It seems that the names of the key,change depending on the status of the shift button.If shift is enabled then the key is called 'N',if shift is not enabled then it's 'n'.You'll notice as a string is being typed,that the shift button is tapped before an uppercase letter is typed.Your test is attempting to press the 'N' key before the 'Shift' button has been pressed.It doesn't affect the first letter of your sentence because the keyboard has shift enabled for the first letter.
This also affects typing a lowercase character after an uppercase character:the lowercase character may be typed whilst the shift button is in the process of being unpressed.
I use a workaround of typing each letter of the string with separate typeString() methods.
for (i = 0; i < title.length; i++)
{
var strChar = title.charAt(i);
target.frontMostApp().keyboard().typeString(strChar);
}
The downside to this is that it takes a lot longer to type the full string.
You may also want to look at the following link which provides a similar solution but uses the app.keyboard().keys().tap() method for each character of the string instead of the typeString() method.
http://jojitsoriano.wordpress.com/2011/06/27/ios-ui-automation-typing-a-string-in-a-uiatextfield/
I'm working on a translator that will take English language text (as user input into a UITextView) and (with a button press) replace specific words with alternatives. I have both the English words in scope plus their alternatives in separate Arrays (englishArray and alternativeArray), indexed correspondingly.
My challenge is finding an algorithm that will allow me to identify a word in the input text (a UITextView) ignoring characters like <",.()>, lookup the word in englishArray (case insensitive), locate the corresponding word in alternativeArray and then use that word in place of the original - writing it back to the UITextView.
Any help greatly appreciated.
NB. I have created a Category extending the NSArray functionality with a indexOfCaseInsensitiveString method that ignores case when doing an indexOfObject type lookup if that helps.
Tony.
I think that using an NSScanner would be best to parse the string into separate words which you could then pass to your indexOfCaseInsensitiveString method. scanCharactersFromSet:intoString: using a set of all the characters you want to ignore, including whitespace and newline characters should get you to the start of a word, and then you could use scanUpToCharactersFromSet:intoString: using the same set to scan to the end of the word. Using scanLocation at the beginning and end of each scan should allow you to get the range of that word, so if you find a match in your array, you will know where in your string to make the replacement.
Thanks for your suggestion. It's working with one exception.
I want to capture all punctuation so I can recreate the original input but with the substituted words. Even though I have a 'space' in my Character Set, the scanner is not putting the spaces into the 'intoString'. Other characters I specify in the Character Set such as '(' and ';' are represented in the 'intoString'.
Net is that when I recreate the input, it's perfect except that I get individual words running into each other.
UPDATE: I fixed that issue by including:
[theScanner setCharactersToBeSkipped:nil];
Thanks again.
In my application, I need to map a shortcut to the key to the left of the "1" key on the keyboard. On a standard US keyboard, this would be the backtick character (" ` "), which is key code number 50. Unfortunately, international keyboards (the French keyboard, for example) has a different key to the left of the 1 key (the forward slash key "/"), so hard coding that key code would result in unexpected results for users who are not using a US keyboard.
Is there any way to convert a US key code into a key code for international keyboards at runtime, or a way to programatically determine the key code based on the position of the key on the keyboard?
The character on the key to the left of "1" is different on different keyboard layouts, but the virtual key code should be the same. If you look at HIToolbox/Events.h, you can see the constant kVK_ANSI_Grave, which represents the key you're talking about; above the list of constants, there's a comment that suggests that at the virtual key code level, equality means that the physical key is the same, though the scan code might be different and the emitted letter might be different.
In other words: the keyboard driver maps from scan codes to virtual key codes, and the keyboard layout (which you can change in System Preferences) maps from virtual key codes to characters.
This is all potentially wrong; I don't have a non-US keyboard with which to verify these assertions.