[Dromeus]

Hi

I have a multi-monitor setup, and one of the extended monitors is dedicated to MSP. Of course, I want MSP to use the whole screen, and to launch always at the same monitor.

Unfortunately, when starting MSP in full-screen mode it keeps coming up at the main monitor, not at the dedicated monitor. I did some tests and found out, that MSP does remember its screen location from the previous session, but only if MSP's window state is not maximized or MSP is not in fullscreen mode.

Is there any chance to change MSP's behaviour in that respect. It would be great if MSP will start exactly at the same screen location and windows state as in the previous session. After all I think this should be the expected behaviour of any Windows App.

Thanks for your attention and best regards
Michael

[Zubersoft]

This and similar issues have come up on the forum before:

https://zubersoft.com/mobilesheets/forum...p?tid=4447
https://zubersoft.com/mobilesheets/forum...p?tid=6760
https://zubersoft.com/mobilesheets/forum...p?tid=5511

Basically, due to the fact that MobileSheets is implemented as a UWP application, I am unable to programmatically move the window myself or choose on which monitor it starts. Microsoft is moving away from UWP going forward (after trying to convince developers for years it was the future) so at some point I will have to convert MobileSheets back to a desktop application using WinUI 3, which is Microsoft's newest answer for modern UI themes and support for some of the things that UWP did right. Once I switch the app to WinUI 3, I will then be able to force MobileSheets to resume it's last known position at startup. There is nothing I can do in the meantime unfortunately.

Mike

[Dromeus]

Thanks, Mike, for your quick and very helpful answer. I now use those keyboard shortcuts as pointed out in the linked forum posts. That's a very convenient workaround.

BTW, I never liked this UWP look&feel. Maybe Microsoft didn't like it either, after all these years Windows Settings never implemented all features of the good ole Control Panel... .

[Zubersoft]

I've struggled with various restrictions and problems with UWP from day one, so in many ways, I will be glad when it's a standard desktop application. UWP did make a number of things simple though:

1) It integrated well with the Microsoft Store back when they didn't allow standard desktop apps, which gave me a convenient way to sell the app and handle licensing.
2) It had great support for touch gestures and events, as well as a fairly good API for handling stylus and mouse input as well.
3) Obfuscation is enforced with production builds to prevent reverse engineering and piracy.
4) It had built in support for things like using the camera on the device, printing, MIDI (including bluetooth and virtual MIDI ports)
5) It compiles for multiple processor types in a very simple manner so that I can support ARM devices like the Surface Pro X.
6) It works well on tablet devices (which is really only the Surface Pro at this point). 
7) Whether you love or hate it, the UI themes do look more modern than older frameworks.

There are a number of things I wish were better though:

1) The app sandbox model used by UWP protects users from malicious apps (which can be a good or bad thing), but this is why file management is such a pain with MobileSheets as it's very restricted in terms of what it can directly access.
2) The MIDI library is hit or miss with some devices like some KORG keyboards, and it reports incorrect port names which Microsoft will apparently never fix
3) It limits certain things like the topic discussed in this thread
4) If MobileSheets is minimized, Windows can decide to just close it to recover resources if it feels the need to which is ridiculous. This was done to save battery life on phones back when Windows phones were a thing, but it makes very little sense to do this on a tablet, laptop or PC.
5) There is limited third party support, and many open source libraries either decided to never support UWP or are ending support with Microsoft's announcements. 
6) The UWP framework has weird issues with memory leaks that I've had to work extremely hard to get around and prevent. This has been a constant source of frustration.
7) MobileSheets sometimes takes a long time to load due to the UWP framework

I'm hoping the switch to WinUI3 will allow me to keep most of the positive things and fix all the shortcomings. I just wanted to share that in case it would be interesting at all to anyone.

Mike

[Dromeus]

Your insight into UWP woes is much appreciated. As a (retired) corporate developer I was using WinForms and WPF extensively, UWP never seamed attractiv for inhouse projects. Let's hope that WinUI3 will actually deliver what is promised, and you will find a good solution for protecting and selling your app.

Michael

[InstrEd]

Will it be a new window
app or replace the current one?

[Zubersoft]

The goal is to just replace the existing app so that it's seamless for users. I'm hoping Microsoft makes it possible to replace a UWP app with a WinUI3 app in that fashion, but I guess I'll find out when I finally move forward with the conversion.

Mike

[InstrEd]

Thanks Mike.

I'm still deciding on going with the Android/Chromebook 2n1 or Windows 2n1 in the future. Now I have a Lenovo Flex 14" 2n1 that has been fine except the display isn't very bright.  Is there any advantage to the Android version compared to the Windows version? 

Sorry to hijack this thread.

[Zubersoft]

I would say there are fewer potential issues with the Android version, which is partially just due to the differences in the operating systems. There is also better compatibility with bluetooth pedals and MIDI devices with the Android version. I also think Android devices handle battery life a little better. 

Mike

[InstrEd]

Thanks  
Now I just have to decide on which way to go.