Author |
Topic |
|
paninaro95
Germany
3 Posts |
Posted - 04/09/2018 : 14:02:26
|
Hello!
I have actually a very simple question: why does StrokesPlus set the value of "ForegroundLockTimeout" to 0?
You can read about this Windows setting here:
https://technet.microsoft.com/en-us/library/cc957208.aspx
If I set it back to its default value, StrokesPlus works as fine as before.
Am I missing something?
Markus |
|
Rob
USA
2615 Posts |
Posted - 04/09/2018 : 14:24:38
|
This is to help ensure that S+ can make other programs the active window, instead of having the taskbar button for the application flash orange.
I do other things to also help prevent this issue, but this is another of those tactics. Windows makes it very difficult (on purpose) for applications to switch or steal focus. This was introduced many years ago when "bad" programs would force themselves to the foreground and in full screen mode, blocking you from being able to get out of them. |
|
|
paninaro95
Germany
3 Posts |
Posted - 04/12/2018 : 04:17:57
|
Well, could you make this an option please?
My primary use of S+ is to maximize a window vertically, to minimize or close it.
So in my case, there is no need for S+ to make another window the active one.
I found it pretty annoying that other windows suddenly are in the foreground while I was working in another application. |
|
|
Rob
USA
2615 Posts |
Posted - 04/12/2018 : 05:53:44
|
Unfortunately, I'm no longer doing active development on S+, focusing my free time instead on StrokesPlus.net. However, I will add it as an option in the new version.
In the meantime, the only workaround I can suggest is to edit your StrokesPlus.xml file (either alongside StrokesPlus.exe, or in C:\Users\{USERNAME}\AppData\Roaming\StrokesPlus. Search for "CheckForegroundTimeout" and replace the value with 1, so it looks like this:
<CheckForegroundTimeout>1</CheckForegroundTimeout>
This is a hidden option, which wasn't really intuitively named, but essentially if the foreground timeout is not 0 (what S+ wants to set it to), it will prompt you to ask whether or not you want S+ to update the setting. This prompt would show each time S+ is started, so perhaps annoying in a different way, but it will allow you to click "No" and it should leave the foreground timeout setting alone. |
|
|
paninaro95
Germany
3 Posts |
Posted - 04/13/2018 : 05:35:42
|
Thanks for the explanation. But clicking that message box away will be also very annoying.
I will then go for a scheduled task that will restore the original/default value of ForegroundLockTimeout, either after start-up of S+ or periodically ;-)
But great that you consider making it an option eventually. Thank you! |
|
|
e.montefusco
2 Posts |
Posted - 03/31/2019 : 02:57:45
|
Hello, I have come across the same problem. First of all I would like to tell you why I would like keep the value of "ForegroundLockTimeout" to its default (200000). If set to 0, when I close a program window (say Excel, but this happens to other applications as well, but not all) by right clicking on its icon in the taskbar and selecting "close", regardless if the window is active or not, the "Do you want to save" dialog appears behind the program. This sort of locks everything since until I get it to show and select my action of choice everything else is stalled. I have tried the following without success: 1 - changing the StrokesPlus.xml file, as suggested, but regardless of my choice in the popup window the registry is changed. 2 - setting the value back once StrokesPlus is started but the effects of this only shows up after rebooting. 3 - using S+.net but I found no option to disable the registry change and I have the same problems.
Note: If I reboot with the ForegroundLockTimeout set to 200000 and do not launch S+ closing windows works as expected. If I change the value manually to 0, this has no effect until I reboot. Starting S+ has effect immediately (without rebooting). Is there any command I need to give to make my manual change effective? This would allow me the solve the problem using solution 2 above.
Thanks for your work and any advice you will provide. Enrico |
Edited by - e.montefusco on 03/31/2019 04:18:09 |
|
|
Rob
USA
2615 Posts |
Posted - 03/31/2019 : 05:30:33
|
All,
1) Enrico, you are correct. There's some faulty logic in that part of the code, it doesn't matter whether you click Yes or No, it will end up applying the value. I can't build S+ right now as I'm missing various dependencies/SDKs/etc on this machine (only 7492 error messages that need to be addressed!), as I've only been working with S+.net since I got this new system, otherwise I could make an update since it's not behaving as intended. 2) You have to make the API call to update the setting and broadcast the change, for it to take effect without rebooting. It's a fairly simple call, see below for C# code that will do this. You can easily move that to a C# app if you wanted, just know that Windows is pretty particular about the conditions under which an app can make certain calls like this. 3) I've disabled the behavior by default in S+.net 0.2.9.4 and added it as an option under advanced if someone wants it enabled as it functioned previously. Since I added the loading splash screen, during which I call AllowSetForegroundWindow, it shouldn't be needed in S+.net.
//Manually set ForegroundLockTimeout to default and broadcast change
void Main()
{
var procid = System.Diagnostics.Process.GetCurrentProcess().Id;
var asfw = AllowSetForegroundWindow(procid);
if (!SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT,
0, new IntPtr(200000),
SPIF.SPIF_SENDWININICHANGE | SPIF.SPIF_UPDATEINIFILE))
{
var err = GetLastError();
}
}
[DllImport("user32.dll")]
public static extern bool AllowSetForegroundWindow(int dwProcessId);
[DllImport("kernel32.dll")]
static extern uint GetLastError();
[DllImport("user32.dll", SetLastError = true)]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool SystemParametersInfo(uint uiAction,
uint uiParam,
IntPtr pvParam,
SPIF fWinIni);
public const uint SPI_SETFOREGROUNDLOCKTIMEOUT = 0x2001;
public enum SPIF : uint
{
None = 0x00,
//Writes the new system-wide parameter setting to the user profile.
SPIF_UPDATEINIFILE = 0x01,
//Broadcasts the WM_SETTINGCHANGE message after updating the user profile.
SPIF_SENDCHANGE = 0x02,
//Same as SPIF_SENDCHANGE.
SPIF_SENDWININICHANGE = 0x02
}
|
|
|
e.montefusco
2 Posts |
Posted - 03/31/2019 : 14:46:12
|
Rob, thank you very much for the super exhaustive explanation.
For the moment I'll stick to the .net version which does all I need.
Please enjoy a beer at my expense. Enrico |
|
|
|
Topic |
|
|
|