Restoring GUI when switching between 1 and 2 monitor view; dual screen display improvements

[mgCatskills]

I'm currently using Sharpcap on a "headless" microPC running Windows 11, Sharpcap Pro 4.0, and Windows Remote Desktop. It can generate dual 4K displays.

During the course of an evening, I actually control SharpCap from 3 different systems:

1. A windows 1080p laptop that has physical buttons highlighted with tape that I use for initial alignment when I'm outdoors with the telescope
2. An M1 MacBook Pro, which has a gorgeous retina display that I use for focusing (again typically outdoors). The MacBook is a little hard to use outdoors because it's so reliant on the trackpad but the better screen is worth the bother for focusing.
3. An M1 Apple Mini with dual 27" displays that I use to control the system from inside the house, once things are all set.

WRD is perfectly happy switching between the different systems, logging one out and the new one in.

I'm having a couple of problems with using SharpCap in this context:

First, SharpCap doesn't switch cleanly back and forth between 1-screen and 2-screen views. It seems fine at first, but it definitely has trouble restoring the "classic" single screen display when you switch back from 2-screens. And even the next time you fire up SharpCap, even after powering down and rebooting the control computer, there can be glitches in the GUI on a 1-screen system.

Is there a way to tell SharpCap to "return the GUI to 1-screen view with all of the windows reset to default orientation and size"? There are times I want to do this even on my 2-screen system.

Second, in 2-screen mode on a 2-screen system, the controls windows, which are tabbed in the "classic view" , expand so you can see several at once. In theory it's nice, but in practice the different windows don't scale all that accurately and you need to scroll up and down to see things. The scrolling, at least using WRD is sometimes awkward.

The "perfect" two display system from my point of view would be to A) have the option to keep the different control windows tabbed (i.e. Histogram, FWHM filtering and history, etc), and B) use the freed up screen real estate to display the last capture (essentially "live view"), with the second screen displaying the Live Stack. Seeing the latest capture would assist in focusing in the middle of a capture, and diagnosis about what causing problems if you're dropping frames.

[admin]

Hi,

working through your examples, one thing that I can see happening is that if you close down SharpCap while in 2 monitor view, the extended height of the live stacking area is stored and then used the next time you open live stacking in single monitor mode. I can fix that particular glitch fairly easily. Note that the number of 'blocks' of tabs visible in live stacking is determined entirely by the height of the live stacking area, so that in single monitor mode you can if you want make it taller to get two blocks, or in two monitor mode you can shrink it back down to get all the tabs in one block.

When in two monitor mode, SharpCap displays the same image on both screens (in modern versions - older ones just put the image on the second monitor). Putting different images on the two is an interesting idea, but sadly not an easy one to implement at the moment.

Unfortunately, if you have been dragging the controls and/or work area panel out of the main frame, getting those to go back to their default positions is a real pain (code wise) - nothing I have tried so far in the way of a 'reset display layout' function has worked correctly. I have some more ideas, but they would also be a lot of work, so I am keeping that feature as 'pending' for now. Fortunately they go back to default when you restart SharpCap (once I have a reliable way to reset them to default, I can think about remembering if they have been moved away from default positions).

cheers,

Robin

[mgCatskills]

Thanks, Robin. I'm struggling to figure out what to do with my current release. Here's my best shot at summarizing what to do... Please let me know if I drew the right conclusion.

First, if I'm working in 2-screen mode, I should switch back to 1-screen mode before switching to a 1 screen device, or closing down. Otherwise I will start up with an extended height for the live stacking area when I switch to a one-screen device. [You're hoping to fix this for a future release].

Second, once I've gotten the frames in the wrong size/location by moving between 1 & 2 screen mode improperly, I'll need to resize frames and move them manually as best I can to restore them to normal functioning, state (e.g. tabbed on expanded), and location. There's no "restore GUI" button, and not likely to be one for the forseeable future.

I'm a little confused about whether there is an advantage to shutting down SharpCap if it's in a non-standard state. I think your comment about "fortunately they go back to default when you restart SharpCap" means that they go back to the default POSITION when you restart, but may inherit incorrect sizes from a prior session. But, I think you're suggesting resizing the various windows, not worrying about location, making sure I'm in 1-screen mode, then exiting. If I do that, when I restart SharpCap, everything should be back to normal. Correct?

[admin]

Hi,

I think you are mostly corret - the height/width of the two panels *are* remembered when you close and re-open SharpCap, but moving them to a different position within the main window or detaching them is not remembered.

If you switch back to 1 monitor view (CTRL+F12) before closing or before changing the display to a single monitor then the incorrect height should not get remembered. Even if it does, you can use the splitter bar to drag the height back down once SharpCap has restarted.

I will also see if there is a way to detect when the number of monitors changes, so if you are in two monitor view and one of the monitors is removed, SharpCap could perhaps go back to normal view automatically.

cheers,

Robin

[mgCatskills]

Hi, Robin.

I'm wondering if any improvements to two-screen mode found their way to 4.1? I stopped using 2-screen mode mostly because I start the night with my MacBook Pro with one screen and it was too complicated two switch between 1- and 2-screen mode.

I'm getting ready to upgrade to 4.1 and wondering (hoping?) if 2 screens now work any better than they did... I looked at the new features list and didn't see anything about it.

[admin]

Hi,

I have not made any big changes, but have tweaked issues along the way. For instance the code should now detect if the second monitor is removed and automatically exit two monitor view at that point (it may not be smart enough to detect 3 monitors dropping to 2 though). Also I did some work in general on remembering window layout in a few more places.

In short, probably worth giving it a try to see if it helps in your specific scenario, but I wouldn't claim that it definitely will.

cheers,

Robin

[mgCatskills]

Hi, Robin

I've now been using 4.1 and have been able to take advantage of 2 screen view using Windows Remote Desktop to send screen data alternately to my 14" MacBook Pro or to my Mac Mini which has two 27" monitors, one 1440p the other 2160p.

I use the MacBook when I'm at the telescope, always for PA, sometimes when skewing the telescope, and sometimes just because it's a pleasant evening to be outside. I'll use the Mac Mini most of the other times, often in two screen modes, but sometimes just on the 4K monitor as the image is large enough.

The biggest issue I have is when moving back and forth between them... The window sizes expand automatically when i move from the 14" screen to the 27" 4k, but don't necessarily scale back down in the other direction. The screen on my MacBook will come up with some controls partially off the screen. I can fix it easily enough by hitting the windows square to enlarge the window to screen size, but it's a bit awkward.

Anyway, thank you for the improvements. They represent real progress.

Michael

[admin]

Hi Michael,

good to hear that we are improving on the multi-monitor front.

The problems that you are seeing when remote desktop connections switch between coming from a normal resolution machine and a high DPI machine aren't things I would have thought of testing. I thought that the whole application was supposed to respond to DPI changed notifications from Windows, so I wonder if the failure is due to not receiving that notification or due to some problem processing it. I will see if we are already logging the DPI change message (or if we can log it), which might help understand what is going on.

cheers,

Robin