I tried right-clicking on the ModerFlyouts app icon (MS-Store version) and choosing Settings. I get the workingin background cursor but nothing opens. Opening settings through tray icon works. Please fix this.
Thanks for reporting, I'll look into this
Are you sure the app is already running?
The settings will only be shown when the app is already running and you select the option from the JumpList
Yes, the app is already running. I can assure on that.
Then this must be a bug and should be fixed. Thanks for submitting this issue ๐
Hey @Cyberdroid1, I can't reproduce this bug. Are you sure it doesn't work?
Yes, I am sure it doesn't work. I just tried.
Also, when the app updated, I havent restarted the app. Maybe this might be an issue?
Ok, try restarting it. While the app is running in the background try the jumplist option again.
I tried restarting. It is still not opening the settings from jumplist.
A Tip :
You don't need to click on the jumplist to open settings. You can just start the app again (from start menu) to open settings.
Its strange - that also is not working now.
Oh my god! ๐๐คฆโโ๏ธ
It is perfectly working for me! Does the tray icon work atleast?
I kinda implemented the fix locally. Will ship it in v0.5.0
Yup, tray icon is working normally.
Do I try reinstalling the app?
Do I try reinstalling the app?
No need for that. Just wait until v0.5.0
Ok sure. I will wait. Thanks.
None of the options in jumplist are working. Not even exit.
Yep I just noticed it ๐ . Fixed it locally, will push once done
Done! 44e2781f3ea36915690c583d712cdc2b26fe9985
It will come in v0.5 then?
Yes!
Ok! Hoping to see it soon.
But let this issue be open. Once you receive the update and have the desired behaviour, we can close this.
Yes, I was thinking the same.
Just packaged current code, and was going to push minor update 0.4.3 to fix this bug, but discovered that the jump list options only work if the app is closed.
Just packaged current code, and was going to push minor update 0.4.3 to fix this bug, but discovered that the jump list options only work if the app is closed.
No they will also work while the app is running
I didnt understand the fixes in 0.4.3.
"Audio flyouts can now be repositioned."
Couldnt we do them earlier?
Yo Sam! That was planned for v0.5.0. These changes are not "minor". Why you didn't ask me?
Now there's nothing left for v0.5.0. Why?
Sorry, half a sleep. Wont push to store till V0.5 is ready
We are gonna release v0.5.0 in 2 days. So I had to delete v0.4.3. Sorry though, there are too many UI updates left to be made.
Hey @Samuel12321, are you sure it doesn't work even after 44e2781f3ea36915690c583d712cdc2b26fe9985?
I'm 100% sure it works on my PC. Can you try it again?
Hi @ShankarBUS, still doesn't work for me. Could just be my computer. Can someone else test this to verify.
Hey @Samuel12321, I will do some changes on new test branch. Run it and tell me if a message box appears with the correct message.
Hey @Samuel12321, I just pushed the test branch called 'jumplist'
If you get some mismatched or incorrect or no outcomes, please make a comment with the a list of what inputs causes what outcome on your system. Make a list the one above.
i don't get any of the message boxes, but the jump list works.
@Samuel12321,
That's impossible! ๐ต. Are you sure you used the 'jumplist' branch? Does every commands work properly?
whops, must have been on the other branch. On jump lists branch everything works as listed above
So the JumpList has been fixed, right?
And FYI the JumpList items also show up in Windows search result. So there are no needs to pin the app tile to start. It even shows up in settings window's taskbar contextmenu
I Made some improvements to it in a468d95cf8d2931423bfb8107228620b7d6dbf87
I'm closing this issue as it seems to be fixed ๐ . Feel free to reopen it or notify me if anyone experience this bug.
So the JumpList has been fixed, right?
seems so :)
Thanks for the verification @Samuel12321!
Hey @Samuel12321, the issue only happens with the deployed version.
It works fine during development but after deploying it to a package (i.e. to Store or as MSIX) and installing it, results in this issue.
The bug seems to root from named pipes not working on a packaged environment. I'll reopen this as it is not fixed.
Hey @Samuel12321,
Found out what's causing this - https://docs.microsoft.com/en-us/windows/uwp/communication/interprocess-communication#pipes
- Named pipes in packaged applications must use the syntax "\\.\pipe\LOCAL\" for the pipe name.
Named pipes in .NET by default uses the '\\.\pipe\\" syntax. This what caused the inter process communication not work on a packaged app (i.e. only after deployment, works fine during development) and thus rendering the jumplist tasks useless
Sorry for taking too long to find this ๐ .
all good, didn't notice it either
No it doesn't work on the store version. Just checked v0.6.0
After this works in v 0.7, can you please add an option to hide the tray icon?
@Cyberdroid1 ability to hide tray icon is planned for V0.8.0 ๐
@ShankarBUS this is fixed now isn't it.
just tried it, it opened the settings menu, but got the black screen crash. #116 #12
Ooooooff
Ok, I checked also. Settings open up from there. But, now there are some problems.
1) The settings window is never in focus. Always hidden behind any other window/maximised window.
2) Each and every option just opens up the settings! Clicking exit in context menu also opens the Settings menu. Same case with restore defaults!
@ShankarBUS this is fixed now isn't it.
just tried it, it opened the settings menu, but got the black screen crash. #116 #12
OMFG! It works?
Well I didn't do anything recently TBH. The .NET 5 migration could've fixed it ๐คทโโ๏ธ. I'm surprised that it even works with the store version (0.7.1).
Ok, I checked also. Settings open up from there. But now there are some problems.
1) The settings window is never in focus. Always hidden behind any other window/maximised window.
2) Each and every option just opens up the settings! Clicking exit in context menu also opens the Settings menu. Same case with restore defaults!
I'm aware of "1" (aware of it since v0.2, just lazy to fix it ๐ . Could you open a new issue so that I don't forget it?). I just noticed "2" is a thing ๐ . Will try to fix it ASAP.
But "2" doesn't occur if the app is not running on the background. It only happens when they are clicked while the app is running. Thanks for noticing and reporting it ๐.
Maybe you can try adding support for command line arguments the .exe file of app. Have a look at TaskBarX for this.
@Cyberdroid1,
That's how the jumplist tasks already work!
Look at this one for example
https://github.com/ShankarBUS/ModernFlyouts/blob/9f161c858539cf7557fa04e6f650ba58dc8ba293/ModernFlyouts/JumpListHelper.cs#L25
There are some problems parsing the arguments passed through the named pipes.
I guess I messed up the parsing method during the .NET 5 migration.
As I now know that the method work fine. I'll invest my time and work in this ๐.
I didn't explicitly state that this app supports command line args since it is hard to find the exe location in a packaged app (the path will contain some random bullshit).
But we do support some arguments. (3 to be precise)
You can see what args are supported on here - https://github.com/ShankarBUS/ModernFlyouts/blob/9f161c858539cf7557fa04e6f650ba58dc8ba293/ModernFlyouts/JumpListHelper.cs#L10
it is hard to find the exe location in a packaged app (the path will contain some random bullshit).
It is hard, but it ain't impossible. The package name remains static all throughout. I believe you know where to find the exe file.
Made a silly mistake again.
The Main method is not async
https://github.com/ShankarBUS/ModernFlyouts/blob/531aa6770cce142ad09b08bb82b5de99eae2e83f/ModernFlyouts/Program.cs#L18
I awaited the connection https://github.com/ShankarBUS/ModernFlyouts/blob/531aa6770cce142ad09b08bb82b5de99eae2e83f/ModernFlyouts/Program.cs#L89
But forgot to await SignalFirstInstance https://github.com/ShankarBUS/ModernFlyouts/blob/531aa6770cce142ad09b08bb82b5de99eae2e83f/ModernFlyouts/Program.cs#L35
Thus, the second instance quits without passing the arguments which lead to an empty response (i.e. will open settings window on the first instance).
I made the SignalFirstInstance synchronous instead of making Main async and blah blah. It now works properly.
Still not sure if this will work properly on user's machine.
Hey @Samuel12321,
What about a minor or beta release which includes 41e2dccfa562fd27182babb76ea1449b4f398c9b & 531aa6770cce142ad09b08bb82b5de99eae2e83f?
Could/Should we do it?
@Cyberdroid1,
It is hard, but it ain't impossible. The package name remains static all throughout. I believe you know where to find the exe file.

Here you go bud!
this is fixed now isn't it?
Just tried it and it works.
Yup! I just forgot to close this issue.
After a long time, this issue is finally fixed now ๐
Most helpful comment
Yup! I just forgot to close this issue.
After a long time, this issue is finally fixed now ๐