I have a Win32 gui app and create a console to debug my program
when i switch to console, i want to change my input mode to Alphanumeric input mode automatic
i create my console use AllocConsole in other thread and handle ctrl message
//key code == ctrl + tab
HIMC h_imc = ImmGetContext()
if(!h_imc){
DWORD err_code = GetLastError() // err_code = 0
}
// do set immstatus but h_imc is NULL
...
i try it with ImmGetContext to get my imm and check is already in alphanumeric input mode,but when i call ImmGetContext,it return null
i confuse why it is,and how can i do to make it work?
Related
In console application, I want to write the output at a specific location and there should be no cursor at the console (Windows CMD). To do so, I got following way:
HANDLE hdl = GetStdHandle(STD_OUTPUT_HANDLE);
if (hdl == INVALID_HANDLE_VALUE)
{
printf("Error : Unable to get console handle.\n");
return 0;
}
PCONSOLE_CURSOR_INFO lpConsoleCursorInfo = { NULL };
if (!GetConsoleCursorInfo(hdl, &lpConsoleCursorInfo))
{
printf("Error : Unable to get console cursor information.\n");
return 0;
}
lpConsoleCursorInfo->dwSize = 1; //App exit at this point with error code 0xC0000005h
I got runtime error 0xC0000005h. By searching, I have reach at the conclusion that it is a security level issue, and to setup access level SECURITY_DESCRIPTOR is used.
I am unable to find the way how to set the access level to STD_OUTPUT_HANDLE that already created and associated with my console application by visual studio console application.
Can someone point me in the right direction?
There is no security issue, you simply don't understand how Windows pointer types work. PCONSOLE_CURSOR_INFO is just a pointer, remove the P.
CONSOLE_CURSOR_INFO ConsoleCursorInfo = { NULL };
if (!GetConsoleCursorInfo(hdl, &ConsoleCursorInfo)) ...
else ConsoleCursorInfo.dwSize = ...
I used to have an application which launched an application using CreateProcess() and then piped data back and forth. The child process used printf() and getch().
The code had:
PeekNamedPipe(pCmdIF->m_asynch_hReadPipeOut,NULL,NULL,NULL, &dwBytesInOutPipe, &dwBytesLeftInOutPipe))
Which checked how much data was in the incoming pipe and then I used ReadFile to read that data.
Now, in Windows 7 that same code does not work.
To create the pipe I used the code ...
// Set the bInheritHandle flag so pipe handles are inherited.
ZeroMemory( &m_asynch_sa, sizeof(SECURITY_ATTRIBUTES));
m_asynch_sa.bInheritHandle = TRUE;
m_asynch_sa.lpSecurityDescriptor = NULL;
m_asynch_sa.nLength = sizeof(SECURITY_ATTRIBUTES);
// Create a pipe for the child process's STDOUT (will also be used for STDERR)
if( ! CreatePipe( &m_hChildStd_OUT_Rd, &m_hChildStd_OUT_Wr, &m_asynch_sa, 0 ) )
{
return 2;
}
Is it a case that m_asynch_sa.lpSecurityDescriptor should not be set to NULL. If that is the case, I cannot find any example of how to set it to a proper value.
Thank you in advance.
The code below for file with no-extension brings up a dialog shown below listing applications that can be used to open the file. This behavior is seen only from Windows-8. And the applications listed in the dialog are taken from HKEY_LOCAL_MACHINE\SOFTWARE\Classes*\OpenWithList. Is there anyway to suppress this dialog and get a behavior similar to old platforms?
-Karthik
SHELLEXECUTEINFO shinfo;
unsigned long mask = SEE_MASK_FLAG_NO_UI;
memset(&shinfo,0,sizeof(shinfo));
shinfo.cbSize = sizeof(shinfo);
shinfo.fMask = SEE_MASK_FLAG_DDEWAIT | mask;
shinfo.hwnd = NULL;
shinfo.lpVerb = "open";
shinfo.lpFile = prog;
shinfo.lpParameters = NULL;
shinfo.lpDirectory = 0;
shinfo.fMask = SEE_MASK_FLAG_NO_UI;
shinfo.nShow = SW_SHOWDEFAULT;
rc = ShellExecuteEx(&shinfo);
I'd suspect there is no default action associated with open on Windows 8 for files without an extension. I confirmed this using your code (a Delphi version of it, anyway) on Windows 7.
Running the code with shinfo.lpverb set to 'open' caused ShellExecuteEx to return FALSE, and GetLastError did indeed return ERROR_NO_ASSOCIATION. However, changing lpVerb to NULL (nil in Delphi) instead displayed the standard Win7 Open With dialog, just like your code does on Windows 8.
Here's a modified version of your code for testing:
SHELLEXECUTEINFO shinfo;
memset(&shinfo, 0, sizeof(shinfo));
shinfo.cbSize = sizeof(shinfo);
shinfo.fMask = SEE_MASK_FLAG_DDEWAIT | SEE_MASK_FLAG_NO_UI;
shinfo.lpVerb = NULL;
shinfo.lpFile = prog;
shinfo.hwnd = NULL;
shinfo.lpParameters = NULL;
shinfo.lpDirectory = 0;
shinfo.nShow = SW_SHOWDEFAULT;
rc = ShellExecuteEx(&shinfo);
Here's my test Delphi code for comparison (a quite literal translation of your C++ code):
var
shInfo: TShellExecuteInfo;
FillChar(shInfo, SizeOf(shInfo), 0); // Same result as memset()
shInfo.cbSize := SizeOf(shInfo);
shInfo.fMask := SEE_MASK_FLAG_NO_UI or SEE_MASK_FLAG_DDEWAIT;
shInfo.Wnd := 0;
shInfo.lpVerb := nil; // Also tested with 'open'
shInfo.lpDirectory := 'D:\TempFiles'; // Path to my no-extension file
shInfo.lpFile := 'datafile'; // My test file with no ext
shInfo.nShow := SW_SHOWDEFAULT;
if not ShellExecuteEx(#shInfo) then
ShowMessage(SysErrorMessage(GetLastError)); // Readable error message
A quick change to your code to replace "open" with NULL as the lpVerb should confirm.
You can also confirm my suspicion fairly easily by right-clicking a file with no extension in Win8's Explorer, and checking the bold default action at the top of the context menu. If there is no bold option, or if it's anything but open, my suspicions are correct.
The Win32 function GetKeyNameText will provide the name of keyboard keys in the current input locale.
From MSDN:
The key name is translated according to the layout of the currently
installed keyboard, thus the function may give different results for
different input locales.
Is it possible to force the input locale for a short amount of time? Or is there another alternative to GetKeyNameText that will always return the name in English?
Update: This answer does not work. It actually modifies the keyboard settings of the user. This appear to be a behavior change between Windows versions.
CString csLangId;
csLangId.Format( L"%08X", MAKELANGID( LANG_INVARIANT, SUBLANG_NEUTRAL ) );
HKL hLocale = LoadKeyboardLayout( (LPCTSTR)csLangId, KLF_ACTIVATE );
HKL hPrevious = ActivateKeyboardLayout( hLocale, KLF_SETFORPROCESS );
// Call GetKeyNameText
ActivateKeyboardLayout( hPrevious, KLF_SETFORPROCESS );
UnloadKeyboardLayout( hLocale );
WARNING: GetKeyNameText is broken (it returns wrong A-Z key names for non-english keyboard layouts since it uses MapVirtualKey with MAPVK_VK_TO_CHAR that is broken), keyboard layout dlls pKeyNames and pKeyNamesExt text is bugged and outdated. I cannot recommend dealing with this stuff at all. :)
If you're really-really want to get this info - then you can load and parse it manually from keyboard layout dll file (kbdus.dll, kbdger.dll etc).
There is a bunch of undocumented stuff involved:
In order to get proper keyboard layout dll file name first you need to convert HKL to KLID string. You can do this via such code:
// Returns KLID string of size KL_NAMELENGTH
// Same as GetKeyboardLayoutName but for any HKL
// https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-language-pack-default-values
BOOL GetKLIDFromHKL(HKL hkl, _Out_writes_(KL_NAMELENGTH) LPWSTR pwszKLID)
{
bool succeded = false;
if ((HIWORD(hkl) & 0xf000) == 0xf000) // deviceId contains layoutId
{
WORD layoutId = HIWORD(hkl) & 0x0fff;
HKEY key;
CHECK_EQ(::RegOpenKeyW(HKEY_LOCAL_MACHINE, L"SYSTEM\\CurrentControlSet\\Control\\Keyboard Layouts", &key), ERROR_SUCCESS);
DWORD index = 0;
while (::RegEnumKeyW(key, index, pwszKLID, KL_NAMELENGTH) == ERROR_SUCCESS)
{
WCHAR layoutIdBuffer[MAX_PATH] = {};
DWORD layoutIdBufferSize = sizeof(layoutIdBuffer);
if (::RegGetValueW(key, pwszKLID, L"Layout Id", RRF_RT_REG_SZ, nullptr, layoutIdBuffer, &layoutIdBufferSize) == ERROR_SUCCESS)
{
if (layoutId == std::stoul(layoutIdBuffer, nullptr, 16))
{
succeded = true;
DBGPRINT("Found KLID 0x%ls by layoutId=0x%04x", pwszKLID, layoutId);
break;
}
}
++index;
}
CHECK_EQ(::RegCloseKey(key), ERROR_SUCCESS);
}
else
{
WORD langId = LOWORD(hkl);
// deviceId overrides langId if set
if (HIWORD(hkl) != 0)
langId = HIWORD(hkl);
std::swprintf(pwszKLID, KL_NAMELENGTH, L"%08X", langId);
succeded = true;
DBGPRINT("Found KLID 0x%ls by langId=0x%04x", pwszKLID, langId);
}
return succeded;
}
Then with KLID string you need to go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\%KLID% registry path and read Layout File string from it.
Load this dll file from SHGetKnownFolderPath(FOLDERID_System, ...) (usually C:\Windows\System32) with LoadLibrary() call.
Next you need to do GetProcAddress(KbdDllHandle, "KbdLayerDescriptor") - you're receive pointer that can be casted to PKBDTABLES.
There is kbd.h header in Windows SDK that have KBDTABLES struct definition (there is some stuff involved to use proper KBD_LONG_POINTER size for x32 code running on x64 Windows. See my link to Gtk source at the end).
You have to look at pKeyNames and pKeyNamesExt in it to get scan code -> key name mapping.
Long story short: The GTK toolkit have the code that doing all this(see here and here). Actually they are building scan code -> printed chars tables from Windows keyboard layout dlls.
I have a system with two HID keyboards (actually, one's a barcode scanner.)
I registered for raw input with RIDEV_NOLEGACY to block the system from creating WM_KEY* messages for the barcode scanner, which tediously also blocks the messages from the other keyboard.
My goal is to keep the WM_* messages for any keybaord device that isn't the barcode scanner.
Basically, I need to either:
Create the WM_* messages myself, and post them to my hwnd from the wndproc that received the wm_input
or
Predict the WM_* messgaes the system will generate, and ignore them if they came from the barcode scanner.
I created a working implementation of 2, which works great on XP but fails to block anything on Windows 7. (In fact, on win7 it seems like i'm only reciving WM_INPUTs even without the RIDEV_NOLEGACY flag)
I'm now trying method 1, which is arguably 'more correct', but I can't seems to find a way to do this completely correctly.
My environment is Python 2.6 using PyQt. I'm sending messages directly to a window created by PyQt, and i've hooked into it's wndproc with a win32 event filter.
class wm_lparam(Structure):
_fields_ = [("repeat_count", c_short),
("scancode", c_byte),
("extended_key", c_int, 1),
("reserved", c_int, 4),
("context_code", c_int, 1),
("prev_state", c_int, 1),
("transition_state", c_int, 1),
]
assert sizeof(wm_lparam) == 8, sizeof(wm_lparam)
WM_KEYDOWN = 0x0100
WM_KEYUP = 0x0101
WM_SYSKEYDOWN = 0x0104
WM_SYSKEYUP = 0x0105
ALL_WM_KEYDOWN = (WM_KEYDOWN, WM_SYSKEYDOWN)
ALL_WM_KEYUP = (WM_KEYUP, WM_SYSKEYUP)
VK_SHIFT = 0x10
VK_LSHIFT = 0xA0
VK_RSHIFT = 0xA1
#These values are filled in by my WM_INPUT handler and the RAWINPUT struct
#staticmethod
def _synthesize_wm_legacy(hwnd, wm, vk, scancode, modifider_keys=None):
kbState_old = (c_byte*255)()
kbState = (c_byte*255)()
def keydown(vk):
return bool(user32.GetAsyncKeyState(vk) & 0x8000)
kbState[VK_SHIFT] = 0x80 if keydown(VK_SHIFT) else 0
kbState[VK_LSHIFT] = 0x80 if keydown(VK_SHIFT) else 0
user32.GetKeyboardState(kbState_old)
user32.SetKeyboardState(kbState)
lParam = wm_lparam()
lp = c_uint.from_address(ctypes.addressof(lParam))
lParam.repeat_count = 0
lParam.scancode = scancode
lParam.extended_key = 0
if wm in ALL_WM_KEYDOWN:
lParam.context_code = 0
lParam.prev_state = 0
lParam.transition_state = 0
if wm in ALL_WM_KEYUP:
lParam.repeat_count = 0
lParam.context_code = 0
lParam.prev_state = 1
lParam.transition_state = 1
lp = lp.value
if wm in ALL_WM_KEYUP: #Seems ctypes doesn't like my struct definition.
lp |= 1 << 30
lp |= 1 << 31
log.debug("Posting %s %s %s %08x\n%s"%(hwnd, wm_str(wm), vk, lp, lParam.dump_s()))
user32.SendMessageA(hwnd, wm, vk, lp)
user32.SetKeyboardState(kbState_old)
This code works, but certain things (like holding the shift key, etc) fail. Also very strange is that when using SendMessage, the letters I type are in uppercase, but switchign to PostMessage makes them lowercase. I can probably solve this via Get/SetKeyState, but I was hoping somebody could give me some answers.
In addition, I'm posting these messages back onto PyQt's queue, but the application fails to process them until a real event is sytem generated. That is, If I type a sentence into a text box, nothing shows up until I then move my mouse over the window. The messages seem queued until a real event happens. Any suggestions?
Clarification:
This is a window in my own process, created by PyQt. I have gotten it's hwnd, and hooked the raw input notification up to it. In the window procedure for WM_INPUT on this hwnd, I want to sendmessage to my own hwnd to duplicate the 'legacy' WM_KEY* messages that I previously disabled to filter them. Again, this all happens in my own process, in my own thread.
Update:
Shift state detection simply doesn't work. No matter what, I am getting all capital keys. Any advice?
I was unable to solve this in pure Win32, and I've gotten only a half solution since i'm using PyQt. In case anyone is interested though, here's the code i'm using for that portion:
class BarcodeQtEventFiler(QtCore.QObject):
def __init__(self, parent, *args):
self.log = logging.getLogger(__name__ + '.keyevent')
self.app = parent
self.input_to_surpress = list()
super(BarcodeQtEventFiler, self).__init__(parent, *args)
def ignoreKey(self, which):
"""On WM_INPUT from the device, call this with the reported VKey"""
self.input_to_surpress.append(which)
def eventFilter(self, object, event):
if event.type() == QtCore.QEvent.KeyPress:
if self.input_to_surpress:
if event.nativeVirtualKey() in self.input_to_surpress:
z = None
#This loop eats the suppression buffer until the VK pressed is found. Fixes Dupes for WM key up/down, etc.
while z != event.nativeVirtualKey():
z = self.input_to_surpress.pop(0)
self.log.debug("Ate key press %s (%s)", event.key(), event.text())
return True
else:
self.log.debug("Future surpressed input: %s", self.input_to_surpress)
self.log.debug("Allowing key press %s (%s)", event.key(), event.text())
return False
This is not fixable as-is, you cannot control the keyboard state. The receiving app will use GetKeyState() to check if the Shift, Ctrl or Alt key is down. SetKeyState() doesn't work, it only changes the keyboard state of your process, not the process that gets the messages.
Use SendInput() instead. A window in the target process must have the focus.