So you could just insert a batch file into the Startup menu or HKLM.Run, that would first kill the old instance using taskkill, and then start a new one, which would automatically bind to the current desktop. Once you kill the old one, another one starts up just fine for your logged-in desktop. This can be verified by killing the pre-existing instance of OSK.EXE via the task manager. Guess what: it doesn't work! :-) This time the trouble is, that there is a pre-existing instance of OSK.EXE running "in the background" on the WinLogon desktop (now hidden), and a new instance for your particular desktop refuses to start up.
So, if you want to have OSK also available for the user who's already logged in, your obvious guess would be to run OSK.EXE using a shortcut from the "Startup" folder in the start menu, or from HKLM/Software/Microsoft/Windows/CurrentVersion/Run. The instance of OSK.EXE that was launched via the system startup script runs under the "SYSTEM" user (a requirement for desktop-interactive services) and has attached to the "WinLogon desktop", which is a different desktop than the one instantiated for the newly logged in user. The one problem may be, that as soon as some user logs in, the window of OSK.EXE becomes hidden (unavailable). It works to the extent that indeed the OnScreen Keyboard does become available within 5-10 seconds after the WinLogon dialog appears. Thanks a lot for that hint, it got me started. Give credit where credit is due - here's a particular reference. And then you also have to enable "synchronous" script startup in "Computer Configuration" -> "Administrative Templates" -> "System" -> "Scripts". And the usual suggested way of doing it is through "gpedit.msc" (Group Policies) -> "Computer Configuration" -> "Windows Settings" -> "Scripts", double-click "Startup", "Show Files", create a batch file (say osk.bat) containing just "C:\Windows\System32\osk.exe", back to the "Start Properties" dialog, and finally "Add" the batch file. Surfing the web, you can find a handful of references that point you all vaguely in the same way: you need to run OSK as a service, and it has to be a service that's allowed to "interact with desktop". If you need to use OSK to log in as a particular user in the first place, this is a dead end.
That however doesn't work quite right - it runs OSK only after a particular user logs in. on a particular user's desktop.Ĭredits / past references / first effortsĮverybody's obvious first guess would be to run OSK.EXE using a shortcut from the "Startup" folder in the start menu, or from HKLM/Software/Microsoft/Windows/CurrentVersion/Run.
OSK EXE ALTERNATIVE PC
In embedded / industrial PC hardware, on machines with touch screen only (no keyboard), you often face a requirement to have the Windows standard "On Screen Keyboard" available all the time, both "at winlogon" (when no particular user is logged in) and after logon, i.e. OSK at winlogon (before logon) *and* on user desktop (after logon) OSK at winlogon (before logon) *and* on user desktop (after logon)īy: Frank Rysanek of FCC prumyslove systemy s.r.o.
0 kommentar(er)
