Some Unicodes do not work as menu items! Topic is solved

[Rohwedder]

Neither:

Code: Select all

#Requires AutoHotkey v1.1.33
#Persistent
For all, Arrow in StrSplit("⮙⮝⮛⮟🡱🡳")
	Menu, Tray, Add,% Arrow, MenuHandler
Return
MenuHandler:
ToolTip,% A_ThisMenuItemPos ": " A_ThisMenuItem
Return

nor:

Code: Select all

#Requires AutoHotkey v2.0
Persistent
For all, Arrow in StrSplit("⮙⮝⮛⮟🡱🡳")
	A_TrayMenu.Add(Arrow, MenuHandler)
MenuHandler(ItemName, ItemPos, MyMenu) {
	ToolTip ItemPos ": " ItemName
}

[just me]

Maybe they are not contained in the menu font?
https://apps.timwhitlock.info/unicode/inspect?s=%E2%AE%99%E2%AE%9D%E2%AE%9B%E2%AE%9F%F0%9F%A1%B1%F0%9F%A1%B3

[lexikos]

AutoHotkey is not responsible for the display of text in menus.

[iPhilip]

This might be a workaround:

Code: Select all

#Requires AutoHotkey v2.0
Persistent
For Arrow in [Chr(0x2B99), Chr(0x2B9D), Chr(0x2B9B), Chr(0x2B9F), Chr(0x1F871), Chr(0x1F873)]  ; ⮙⮝⮛⮟🡱🡳
   A_TrayMenu.Insert( , Arrow, MenuHandler)
MenuHandler(ItemName, ItemPos, MyMenu) {
	ToolTip ItemPos ": " ItemName
}

[Rohwedder]

Good idea! This also works here:

Code: Select all

#Requires AutoHotkey v2.0
Persistent
For all, Arrow in StrSplit("⮙ ⮝ ⮛ ⮟ 🡱 🡳"," ")
   A_TrayMenu.Insert( , Arrow, MenuHandler)
MenuHandler(ItemName, ItemPos, MyMenu) {
	ToolTip ItemPos ": " ItemName
}

AutoHotkey may not be responsible for the display of text in menus, but for the fact that StrSplit("⮙⮝⮛⮟🡱🡳") does not work!

[Descolada]

@lexikos,
It appears that lstrcmpi in UserMenu::FindItem considers some Unicode graphemes equivalent, causing menu items not to be added. The following adds only one item, not two, and the grapheme is properly displayed:

Code: Select all

#Requires AutoHotkey v2.0
Persistent
For all, Arrow in ["⮙ item", "⮛ item"]
    A_TrayMenu.Add(Arrow, MenuHandler)
MenuHandler(ItemName, ItemPos, MyMenu) {
    ToolTip ItemPos ": " ItemName
}

Here cmp1 and cmp2 are 0:

Code: Select all

LPCTSTR str1 = L"⮙";
LPCTSTR str2 = L"⮛";
LPCTSTR str3 = L"";
auto cmp1 = lstrcmpi(str1, str2);
auto cmp1 = lstrcmpi(str1, str3);

Using wcsicmp instead of lstrcmpi seemed to fix that, but I'm not sure what other side effects it might have.

This concerns only Add, not Insert.

@Rohwedder, the trouble with Unicode is that graphemes sometimes consist of multiple code points. For example, "🡱" isn't actually a single character, but it's actually a combination of Chr(0xD83E) and Chr(0xDC71). This has the "interesting" effect that StrLen("🡱") == 2, and StrSplit("🡱") returns ["�", "�"]. You can avoid that by using ["⮙", "⮝", "⮛", "⮟", "🡱", "🡳"] instead of StrSplit.

[lexikos]

@Descolada I see, thanks.

lstrcmpi respects locale, whereas wcsicmp is only case-insensitive for plain ASCII letters.

lcstrcmpi is just an alias of lstrcmpiW, which gets its behaviour from CompareStringEx. As far as I can tell, these arrow characters are not compared to anything; they are ignored altogether. This likely affects every part of the program which performs case-insensitive comparisons respecting locale. For instance,

Code: Select all

#Requires AutoHotkey v2
MsgBox StrCompare("ab", "a⮙b", "Locale") ; 0

Code: Select all

#Requires AutoHotkey v1
StringCaseSense Locale
MsgBox % ("a⮙b" = "ab") ; 1

🡱 isn't a grapheme consisting of multiple code points. It is a single code point (and what they call a "supplementary character") which is represented by two UTF-16 code units.

None of AutoHotkey's functions are expected to treat this as a single character, except where explicitly documented (i.e. Ord).

Unicode: Each character is two bytes (16 bits). Character codes are as defined by the UTF-16 format.

Semantic note: Technically, some Unicode characters are represented by two 16-bit code units, collectively known as a "surrogate pair." Similarly, some ANSI code pages (commonly known as Double Byte Character Sets) contain some double-byte characters. However, for practical reasons these are almost always treated as two individual units (referred to as "characters" for simplicity).
Source: Binary Compatibility | AutoHotkey v2

[lexikos]

The locale-based insensitivity of menu names appears to be documented only in the archived changelog of 1.0.43.03:

Changed the following to use locale case insensitivity vs. "A-Z only" insensitivity: hotkey names, hotstring abbreviations, menu names, Input's MatchList, and Gui Tab.

It seems that prior to Vista, the comparison functions which respect locale were the only obvious way to treat non-ASCII characters such as à and À as equivalent, and that was the main reason for this change.

However, Vista and later have CompareStringOrdinal, which supports non-ASCII characters but uses the "operating system uppercase table information" and is not locale-dependent. This type of comparison is used for NTFS file names and some system objects, such as mutexes and named pipes. Had I known about this before v2.0.0, it might have made sense to make it the default method of case-insensitive string comparison.

Given the purpose of specifying an existing menu item name, the general behaviour of "case insensitive" comparisons and lack of specificity in the actual documentation, I have decided to change Menu Add to ignore locale (consistent with variable names, GUI control names, etc.) in v2.1.

Sort Strings Ordinally lists cases where CompareStringOrdinal differs from lstrcmpi, which is used by the "locale" method. Using this, I was able to confirm some cases where #Include's "include only once" default behaviour fails, which will be fixed by switching to CompareStringOrdinal in v2.0.11.

[lexikos]

v2.1-alpha.8 fixes ⮙⮝⮛⮟ being ignored.

I do not plan to change the method of comparison used in v2.0 or v1.1, which implies that these characters will continue to be ignored, by design.