bug.n does not work with windows 10 "store apps"

[watermelonpizza]

Any windows 10 store style apps are not being detected and cannot be manupulated.

Using version master (version as of the time reported on this issue).

Details for the mail app for example:

ID: 0x56072c
class:	ApplicationFrameWindow
title:	Inbox ‎- Mail [hidden]
process:	ApplicationFrameHost.exe [7984]
style:	0x94CF0000
metrics:	x: 210, y: 87, width: 2743, height: 1665
tags:	--

Config_rule=ApplicationFrameWindow;Inbox ‎- Mail;;0;;;;;1;

Regular application like explorer.exe looks like this for me:

ID: 0x230396
class:	CabinetWClass
title:	master
process:	explorer.exe [5744]
style:	0x14CF0000
metrics:	x: -9, y: 26, width: 1518, height: 1982
tags:	1

Config_rule=CabinetWClass;master;;1;1;1;0;1;0;

[yatli]

@watermelonpizza I also observe this when working on VirtualDimension (a virtual desktop manager). These store app hosts do not receive conventional win32 events. They refuse to move, refuse to be probed for icons, etc etc.. and what I did eventually is to hide all these things that I cannot parse or process.
See: v-yadli/VirtualDimension#3

[daphen]

Is this solvable? It's super annoying.

[joten]

bug.n can partly handle Windows Store apps, e.g. move them, but cannot fully hide them; the ApplicationFrameWindow seems to be left behind. With the configuration rule 9 (Config_rule_#9=CalcFrame;.*;;1;0;0;1;1;0;) the Windows 10 calculator should be set to be managed by bug.n.

You may add Config_hotkey=#^o::Manager_override(1;0;0;0;1;0;) to your Config.ini and use the hotkey WinCtrlO to manually set the 'manage' flag to the active window.

The unpretty sight of the problem is, that the Taskbar icon will still be visible and an empty entry resides in the Alt-Tab-menu, even if the window is moved to a different than the active view.

Can you confirm the described behaviour, or is there an additional bug?

[watermelonpizza]

I'm not using bug.n anymore, but maybe someone else can help.

[dylanpjx]

It's not just Windows Store app, Epic Store gets left behind as well. On the other hand, I have musicbee installed via the windows store and it works.

I also can confirm the described behaviour, besides that it seems to be working as per normal when using the manual override

[yatli]

See: https://github.com/cairoshell/cairoshell/blob/master/Cairo%20Desktop/CairoDesktop.UWPInterop/StoreAppHelper.cs

An interesting solution!