Language Code stacks in Windows Metro Apps Topic is solved

[kirby]

[Moderator's note: Topic moved from Bug Reports.]

Hi there,

I got an issue in Windows Store apps (or Metro applications) like OneNote, etc.
The issue relates to getting locale ID. At first time it gets correct ID. But it doesn't return ID of current locale after changed locale, it just return first locale ID.

I have following AHK code:

Code: Select all

LangLocaleId()
{
    return DllCall("GetKeyboardLayout", "UInt", DllCall("GetWindowThreadProcessId", "UInt", WinActive("A"), "UInt", 0), "UInt")
}

LangLocale(code)
{
    If (0x4090409 == code) {
		return "en_US"
	} else if (0x8090809 == code) {
        return "en_GB"
    } else if (0x4190419 == code) {
        return "ru_RU"
    } else if (0xF0A80422 == code) {
        return "ua_UA"
    }
    Return 0
}

#f::
{
	SetFormat, Integer, Hex
	
	localeId   := LangLocaleId()
	localeName := LangLocale(localeId)
	
	ToolTip, %localeId% - %localeName%
	Sleep, 3000
	ToolTip
	
	Return
}

Steps to reproduce:
1. Open Windows Store App
2. Check your locale ID (WIN + F).
3. Switch your keyboard language within the same window.
4. Check your locale ID (WIN + F).

Expected:
Current/changed locale ID.

Actual:
It shows locale ID from step #2.

In works well in any app, excepting Windows Store app.
Perhaps, there is an issue with WinID

Is there any advice? Or it's just a bug?

[joefiesta]

1. What is "windows store app"?

2. What is Win + F? Microsoft defines Windows logo key + F: Search for computers (if you're on a network).

[lexikos]

If this was a bug, it would be a bug in Windows. AutoHotkey doesn't have any function to return the locale ID of another window. You are clearly calling an external function, for which AutoHotkey is in no way responsible. That function doesn't return the local ID of a window either.

The problem with your script is that you are passing the wrong thread ID. Windows Store apps have a top-level container window which belongs to a different thread than the actual app.