Question

I'm using dualview setup in my OS (1 view extended across 2 screens). In my winforms application I can move particular window to secondary screen, e.g.:

foreach (Screen s in Screen.AllScreens)
{
    if (!s.Primary) {
        myform.Bounds = s.Bounds;
        break;
    }
}

Everything is fine, when I can see this secondary screen. If I see it, I'm able to use any functionality such window form provides, e.g. I can close it by clicking the appropriate button.

But what if I cannot see this secondary screen, e.g. this is a projected image displayed on a wall in another room ? I cannot use my forsaken form then. How to cope with such uncomfortable situation (moving to the same room is not an option) ?

What I want is to make an exact duplicate of such form to be shown both on my primary screen and the secondary one. I'd really like to have multiple instances of the same window, exact copy, where one instance reflects changes at the other one and and vice versa. I could control the secondary screen (react on some popup information, etc) using the main one placed in remote location. I have no idea how to implement something like this in .Net with the usage of winforms. How to do it ?

BTW: If this is hard to achieve, what can be done from the conceptual point of view ? I know I can define some keyboard shortcuts but this is not what I'd like to have. Any ideas?

Was it helpful?

Solution

Conceptually, you could use a second window (call it a "Mirror form") to duplicate the primary form. Capture the screen for the primary form and display the captured portion on the mirror form.

That part is the easy part. If you want to be able to actually interact with the Mirror form, you'll need to capture all user input such as mouse move, hover, click events, and keyboard events and replay them onto the main form.

You might be able to do that with the event handlers on the Mirror form by capturing all of them and replaying them them on the primary form. However, I'd look into capturing the messages on the mirror form. That is probably more comprehensive and probably a cleaner way code wise to "monitor" the events and send them over to the primary form. You can also "eat" messages going to the mirror form that would cause focus to change (e.g. there may be an issue if input focus suddenly shifts from the primary form to the mirror form while the user thinks they're interacting with the primary form).

For more info on Messages look into overriding then WndProc of the Form (which is really Control.WndProc) and here. A nice overview article is Deliver The Power Of Spy++ To Windows Forms With Our New Tool. It also deals with cross-process communication which isn't relevant but explains a lot of the detail on messages and intercepting them.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top