keymapper no longer runs properly via Windows task scheduler

[alchzh]

Thank you for developing this excellent application. It allows me to use my favorite keyboard which has no remapping features in firmware. To use it, I run it with at system startup trigger through Windows Task Scheduler. However, since update to 1.8.0 this no longer works, it seems no window update is ever sent to application. I compiled many different versions of the application for each commit between 1.7.0 and 1.8.0 and it seems the culprit is commit 6f0fc39 . Before this commit executables run as expected through task, but when built with this commit the task is displayed as "Running..." but no updates are processed. I am not familiar with Windows programming or this application's codebase so I was unable to debug the exact reason.

Version 1.8.0 and 1.8.1 run fine when manually called, regression is only in task scheduler I think.

[alchzh]

Here is the XML file of my task

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.4" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2021-12-27T09:46:40.3517961</Date>
    <Author>DESKTOP-REDACTED\alchzh</Author>
    <URI>\My Tasks\Keymapper</URI>
  </RegistrationInfo>
  <Triggers>
    <BootTrigger>
      <Enabled>true</Enabled>
    </BootTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>REDACTED</UserId>
      <LogonType>Password</LogonType>
      <RunLevel>LeastPrivilege</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>StopExisting</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
    <UseUnifiedSchedulingEngine>true</UseUnifiedSchedulingEngine>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>C:\Users\alchzh\Documents\keymapper\build\Debug\keymapper.exe</Command>
      <Arguments>-v -i -c "C:\Users\alchzh\config\.config\keymapper.conf"</Arguments>
    </Exec>
  </Actions>
</Task>

[houmain]

Thank you for reporting this issue. I can't image, how this changes could have this effect, but I will test it with the Windows Task Scheduler (I always simply put a link to keymapper in the autostart folder). What do you mean by "no updates are processed"? That your keystrokes are simply forwarded unmapped? Is it reproducible with a minimal keymapper configuration, like A >> B?

[houmain]

Maybe, when you are starting it directly, you are not passing the -i parameter? The problem might be related to the interception mode (which I am intending to deprecate and replace with a better solution).

[alchzh]

I am starting it with -i manually without problems.

Even minimal mapping displays same thing as above. Keys are not processed at all. Verbose output (I redirect to a file for log) shows keyboard hook starting but no window changes, like it does normally.

[houmain]

I found the problem. When keymapper is started by the Windows Task Scheduler and this is selected: it is not able to determine the focused window. Since 6f0fc397ceaf48b855f3cbc75844843da9aedbbe no context is active until a window gets focused, not even the default context, so nothing is mapped. With the commit 9d4e5be75e6ade278ab56fb44e0b5396d730edf6 the default context is immediately active again.

[alchzh]

Closing for now though I can't test because my computer is not booting at all for completely unrelated reasons