Bug: ModernFlyouts gets hidden behind other topmost windows and not shown in Lockscreen about modernflyouts HOT 18 CLOSED

Oh, I forgot to notify you all.

This bug is fixed and being worked on in the dev branch of this repository.

The flyout now even shows on top of the lock screen.

Smash the Like button, hit Share and Subscribe to my channel for more updates on this!!!

from modernflyouts.

Yes

from modernflyouts.

WE ARE WORKING ON IT! This is our top priority for now. Most of the work has been done.

I even added the ability to detect full-screen apps.

I will add the option to hide the flyout later in v0.10 or so.

from modernflyouts.

@Cyberdroid1,

Shhhh, KEEP QUIET!

Every one forgot this bug exists. Don't remind them!

from modernflyouts.

I have stopped further progress on this because of these hurdles

• In order to make the flyout window top most, we have to use an undocumented API (found out, elaborated and demonstrated by @ADeltaX!) which only allows two zones/bands (normal and ultimate [req. UI Access]) for normal apps. Other zones/bands are prohibited to be only used by Microsoft signed applications.

• As mentioned above, we need a MS signed executable to create the window in a specific band/zone. For that we need to inject our assembly into a MS signed exe (@ADeltaX suggested to use an immersive broker called RuntimeBroker).

• Injecting our assembly into RuntimeBroker (native process) was not a problem. But loading and executing .NET code inside a native process requires the .NET runtime to be loaded into the same process. This is were the problem begins.

• .NET Core/.NET 5 doesn't support hosting self-contained runtime onto a native process (but it does that internally somehow). If anyone knows how to host a self-contained .NET runtime onto a native (C++) process, then please help me out.

• Even though we can host a pre-installed .NET runtime (on the target machine) [i.e. we have to deploy our app as framework-dependent and force users to manually install .NET 5 runtime on their system] onto a native process, self-contained .NET runtime is impossible to be hosted in a native process AFAIK.

@ADeltaX, Could you tell me how to use the UI Access workaround for now?
How could we sign the application with a self signed certificate in order to use UI Access?

As you said in the installation guide of AudioFlyout

AudioFlyoutUA.zip --> doesn't make use of admin privilege but it makes use of UI Access. This will give access to create a top top most window, displayable even in lock screen.
Cons: this requires to be extracted in a protected folder (ex: Program Files), and it should be signed.
Cons: this is test signed, as a code signing certificate is expensive for me to obtain, which means you need to trust the certificate to run it.

@Samuel12321, told me that the application will automatically be signed with a proper certificate while passing through the Store Certification and that the signed certificate will be automatically be installed when the package is being installed.
Since we are using MSIX as the deployment method, we can be 100% sure that the package will be installed on C:\Program Files\WindowsApps\ (a protected folder).

Thus we have fulfilled the two requirements for UI Access.

Would it work?

We could use that until we figure out a better native hosting strategy.

from modernflyouts.

@ShankarBUS, could we we make the app framework dependant and bundle it with the framework using the .appinstaller dependancies?

from modernflyouts.

What about Desktop6?

from modernflyouts.

or this? https://www.advancedinstaller.com/forums/viewtopic.php?f=7&t=41018#p110135

from modernflyouts.

This is a known limitation. It will be fixed in version 1.0 release

from modernflyouts.

That's Awesome. Thanks 😊👍

from modernflyouts.

I'm sorry you're experiencing this issue. This project originally (i.e. cloned from AudioFlyout by @ADeltaX) had the ability to show itself over every window but was removed temporarily due to some difficulties.

@ADeltaX, could you take care of this issue?

from modernflyouts.

Well thanks a lot then

from modernflyouts.

Any updates to this? Figured any workaround?

from modernflyouts.

@ShankarBUS, could we we make the app framework dependant and bundle it with the framework using the .appinstaller dependancies?

You can try this for the beta version. We can add a prompt to install .NET 5 from add a feature setting in control panel.

from modernflyouts.

@Samuel12321,

That's the problem!
.NET 5 runtime is not published as a Framework Package and I read somewhere that they won't in the near future. So, it cant be added as dependency in the APPX package manifest or the appinstaller.

I also heard that MSIX doesn't provide custom actions (like pre-install functions to ensure dependencies).

So, that's that. Only self-contained 😢.

@Samuel12321, did I mention your statements correctly? Did I assume anything wrong?

from modernflyouts.

@Cyberdroid1,

You can try this for the beta version. We can add a prompt to install .NET 5 from add a feature setting in control panel.

I don't understand this properly. But let me assume that you meant to provide an option to download the .NET 5 runtime inside the settings window.

Our app wouldn't even start without the runtime!!! How could we show the settings if the wouldn't even start!!

If you meant something different, let me know.

from modernflyouts.

@Samuel12321,

That's the problem!
.NET 5 runtime is not published as a Framework Package and I read somewhere that they won't in the near future. So, it cant be added as dependency in the APPX package manifest or the appinstaller.

Of course, how silly of me to assume Microsoft would have done something logical.🤣

from modernflyouts.

#99 (comment)

Would it be possible to implement this for the time being when full screen in a UWP app? Essentially automatically disable modernflyouts it when full screen and re-enable it when exit full screen. That way we are at least able to see volume changes even if is the ugly default UI.

from modernflyouts.