bug.n
bug.n copied to clipboard
fuhsjr00
Tiling invisible windows
not sure if this is related to #27, but possibly. I'm using the latest dev exe from from eb4395fbea4b9a3f35a51fe5ec1f1928eced4635
some applications, most notable Outlook 2010 and primarily Lync have an issue there after some indeterminate time an invisible window is tiled.
win+i while focused on the empty space gives me this information in an about box with a lot of blank space:
ID: 0x3006c
class: Progman
title: Program Manager
process: explorer.exe
style: 0x96000000
metrics: x: 0, y: 0, width: 4890, height: 2160
tags:
Config_rule=Progman;Program Manager ;;0;;;;;0;
as you can see in this screenshot:
The blank space should be related to 365c6b060f466a32748f2083da842cb76d7fa2b2, and thereby be fixed.
some indeterminate time an invisible window is tiled
Please try the latest development version with updated .exe (7d74dd4fe55ee5449e2d54c08f61d49c74533ddc) to see, if the problem still occurs.
Please try to reproduce the issue and post the window list (WinShiftI), if possible.
The layout from the screenshot looks odd, since at the bottom seem to be two window side by side and one above in the stack. The currently active window is the desktop, which is not managed, but shows through the tiling gap.
Maybe I have the same issue (running latest develop version). win i and win shift-i info included
ID: 0x1011c [hidden] class: Shell_TrayWnd title: process: [] style: metrics: x: , y: , width: , height: tags: --
Config_rule=Shell_TrayWnd;;;0;;;;;0;
Active Window 0x2070c: Tiling invisible windows · Issue #32 · fuhsjr00/bug.n - Brave
Window List 0x2070c: Tiling invisible windows · Issue #32 · fuhsjr00/bug.n - Brave 0xa081a: Config.ini - Kladblok 0x20504:
I assume that 0x20504: is the id of the invisible window.
I agree; the question is, if it is a still existing window for which bug.n cannot get class name and title, or if it is a window which has been destroyed but not removed from bug.n's lists. In the latter case opening an Explorer window and closing it again would have an effect.
Debugging this issue is a bit complex and hard to reproduce :-(
I have the problem since about a month; maybe due to en update of WIndows10. There is ALWAYS such an invisible window, also after I quit bugn. remove C:\Users\username\AppData\Roaming\bug.n\data_WindowState.ini and start bugn again. Also a reboot does not solve anything. So I can reproduce this situation easily. Could I help you with some debug/log info?
Can you find any hint (class name or title) in WindowState.ini on which window e.g. 0x20504 is? You may get different results, if you are running bug.n as Administrator.
I am running bugn as admin. On desktop1 I have an invisible window. WIndow info:
: Active Window 0x9020e: bas - Bestanden - STACK - Brave
Window List 0x9020e: bas - Bestanden - STACK - Brave 0x106bc:
WindowState.ini gives: ...Window 0x106bc;Flow.exe;1;1;0;0;0;1; flow.exe comes from: C:\Program Files\CONEXANT\Flow and is part of a driver.
Killing the process flow.exe 'solves' the problem. I assume I can easily prevent bugn from managing this invisible window?
Regrettably, it is not that easy and bug.n is a bit inconsistent in its output:
- WindowState.ini only gives the process name and id.
- The window list only gives the title and id.
- bug.n should filter all windows, which neither have a class name nor title, therefor I assume the window in question has a class name, but we will never know, which one, since it cannot be focused.
You would have to add some code and a Config_rule to solve the problem:
isConexantFlow(wndId) {
detectHidden := A_DetectHiddenWindows
DetectHiddenWindows, On
WinGet, wndPName, ProcessName, ahk_id %wndId%
DetectHiddenWindows, %detectHidden%
Return, (wndPName == "Flow.exe")
}
Config_rule=.*;.*;isConexantFlow;0;0;0;1;1;1;
Disclaimer: I could not test the code.
Currently, I would not dare to change the code in Manager_saveWindowState regarding WindowState.ini, since Manager_restoreWindowState depends on it.
Thanks,! Maybe stupid question, but where should I insert the code? ALso in config.ini?
Insert the code in Config.ahk above the ;; Key definitions and the Config_rule in Config.ini; Config.ini is only parsed for variables and hotkeys.
I just tested it; I stopped bugn before editiing config.ahk. THe behaviour is changed. When I see the invisible window, the window list gives: Active Window 0x2e1660: C:\Program Files\CONEXANT\Flow
Window List 0x2e1660: C:\Program Files\CONEXANT\Flow 0x9020e: Tiling invisible windows · Issue #32 · fuhsjr00/bug.n - Brave 0x140fee: Uren boeken per week InSite MXI - InSite ERP - Brave
So the inivisible window has a name now, but is still visible. I did also insert the config rule.
maybe I was a bit stupid; I had generated earlier an bugn.exe file. Should I regenerate this exe?
That's odd. The rule should make bug.n ignore Flow.exe-windows. Is the window really visible or leaves a blank tile in the layout? -- What did you do to activate the window? Can you retrieve the full window information via WinI, if it is active?
If you are running bug.n via Main.ahk and AutoHotkey, there is no need for recompiling bugn.exe.
I have justed tested it again, and you are terrific, it is working like a charm!! I don't know what I did wrong previous time. Thanks, I have been using bugn now for 3 years, and I like it very much (despite the steap learning curve)!
@schkr : Can you pinpoint a window with possible compatibility issues as well?
@joten Yes I can, "ORPLAT," and working on getting "TTOTAL_CMD" to duplicate the problem. So far my observations: the blank window on the active tiled monitor seems to be a bug.n hidden window reference - to an adjacent blank monitor that has not been populated with any windows/applications. The problem seems to be more consistent when I try to configure rules to have an application open on a specific monitor and tag.
I haven't yet tried the fix you posted yet, but will be able to early this week. Wanted to check/purge the Win10 Reg Display settings to see if that helps.
The "blank window" is a window, which is in bug.n's list of tiled windows for this view, but which cannot be rezided or is not visible at all. That shines through is, is the Windows desktop.
I did a quick test with total commander, but could not find any problem.
Can you post the windows list (retrieved by pressing WinShiftI)? There should be a window id listed, which does not seem to correspond to a visible window. You would then search for this id in C:\Users\<username>\AppData\Roaming\bug.n\data_WindowState.ini to identify the culprit.
Active Window 0:
Window List 0x410dc:
ID: 0x20138 class: Progman title: Program Manager [hidden] process: explorer.exe [7144] style: 0x96000000 metrics: x: -3840, y: -2168, width: 11520, height: 4328 tags: --
Config_rule=Progman;Program Manager;;0;;;;;1;
I was not able to duplicate the exact problem with TotalCommander, but did notice an issue.
I specified TC to a specific monitor and tag. After loading the initial instance of TC (which bug.n set sent it to the correct monitor and tag), immediately loading a second instance caused bug.n to send the second instance to the same monitor and tag, but it forget about the first instance of TC loaded - as if the initial instance was set to floating status without a window ID in the active windows list.
Are you able to duplicate this?
It seems, there is something wrong with the window list handling. In your _WindowState.ini are two View_#?_#?_wndIds entries with ; as the value, but which should be empty. The window in question seems to be Window 0x410dca;;;;;;37924;0;, but the window list only shows 0x410dc as the window id, as if the list item was cut off. Well, it's definitely a bug.
I did some more tests with Total Commander, but only have one monitor to test with and get the registraton pop-up of Total Commander, since I use an unregistered version. I tested the following Config.ini lines: Config_rule=TTOTAL_CMD;.*;;1;1;2;0;0;0; and Config_rule=TTOTAL_CMD;.*Total Commander.*;;1;1;2;0;0;0; and could not detect any problems; the window information and lists seem to be ok. But I did notice, that Total Commander prepends additional windows with a number in square brackets.
@joten How do we donate to the project? In all honesty, I've used the closest commercial product for $25, and bug.n despite this still runs circles around that.
I've been trying to get @joten to accept donations for years, but he says that he feels like it obligates him to some level of service. I see it as encouraging you to work on projects that you like. If I knew how to get money to him, I'd setup the donate button myself.
On Mon, Oct 21, 2019 at 11:51 PM schkr [email protected] wrote:
@joten https://github.com/joten How do we donate to the project? In all honesty, I've used the closest commercial product for $25, and bug.n despite this still runs circles around that.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/fuhsjr00/bug.n/issues/32?email_source=notifications&email_token=AAMRJSWSOWXEFSJ5JUG5BVLQPZ2DLA5CNFSM4A5K4F5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB4OTTI#issuecomment-544795085, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMRJSUG4BZRDUWRQXAFQR3QPZ2DLANCNFSM4A5K4F5A .
I also have this issue frequently under Windows 10, and settled with a work-around that is to send the empty windows to an unused space (e.g. Win Shift 9 to send to workspace 9) for now
@fuhsjr00 @joten Would love to make a donation as well! I've been an i3wm user for a while but really miss bug.n's "mirror" function and the master-stack philosophy. Indispensable when working on a big wide screen monitor
I had the same, or similar issue for long time; After having done something (no idea what), a seemingly invisible window appeared. Focusing on the window with mouse and pressing Win+I would show Progman as being the app that owns the window. Hence I copied the rule for Progman into my configuration file, but it never seemed to have any effect.
Tried tinkering with _WindowState.ini and _Layout.ini, to no avail.
Two days figured out (semi-accidentally) that if I focus on the window using keyboard (Win + Up/Down) instead, and then invoke the window information dialog, I get completely different data; The window was actually Narrator, and not Progman. Copied the rule (for Narrator) into config and tweaked the rule accordingly ("not managed") and eventually got rid of the invisible window.
(I also nuked Narrator from the system to make sure it never appears.)
Narrator having the same hotkey as layout axis mirroring (Ctrl + Win + Enter) explains what made the invisible window to appear in the first place.
