Forum Discussion
Sharing part of the screen
- Apr 28, 2021Seem to be not possible at the moment, but heavily requested by user voices: https://microsoftteams.uservoice.com/forums/555103-public/suggestions/38834104-share-custom-area-of-screen
ProMaceThanks for your extensive tests! I have released a small fix for 1.
1 and 2. Thanks, I fixed this in v1.1.1. The window should continue rendering now, even if it is completely covered by other windows.
3. Unfortunately, this is a Teams limitation. A capture in OBS has no problems with it. As a workaround, I made sure the Main Window always stays within the screen.
4. Yes, it seems that Teams stops recording when the window is minimized. I am not sure if it is possible to render while minimized.
5. What do you mean with 'hidden'? Is there another way to cover a window?
If 1 is not a solution for you, you can actually use virtual desktops. A bit complicated to start, but you can move the Main window to another virtual desktop after selecting it for screen sharing!
PyKen You, my friend, are an asset to humanity... Your fix works just fine for me! So no need for virtual desktops. ![]()
After some further testing, I found a few small remaining issues:
1. When using DPI settings > 100% (I use 125%), the effective screen pixel coordinates of the 2 windows will be off by DPI / 100. So for instance, if DPI = 125 then (2560, 0) effectively becomes (3200, 0). I can compensate for this through the coordinates passed to the app, in the example I can multiply by 100/125 which yields (2048, 0). It would be cool if you could implement a parameter --dpi and then perform the correction (100 * coordinate) / --dpi internally within the app!
2. It appears that the Main Window has a positive offset on the passed (x, y) coordinate. It looks like it's being positioned at (x + N, y + N). In my use case this causes a slight overlap with the capturing rectangle as I'm positioning the Main Window at (0, 0) and the Capture Window at (2560, 0). Moving the Main Window to the left and top, outside of the desktop area, causes it to snap (as per your fix) into the (0, 0) position which is where I expect it to be.
Regarding your question about hiding a window: AutoHotkey has a function WinHide that makes the window invisible. I assume Windows simply stops rendering the window, which is why it can't be used in our screen sharing scenario. I think AutoHotkey is calling a low-level Windows API to make a window invisible. See https://www.autohotkey.com/boards/viewtopic.php?style=17&t=63297
If you could look into these small issues, that would be great! I've already had my X-mas present for sure!
Best regards,
ProMace
- PyKenNov 30, 2021Copper Contributor
ProMace Glad to hear it works well on your end as well:D And thanks for pointing out further issues:)
1. I made v1.2.0 to ignore scaling by default as it causes recorded images to blur (i.e. you do not need to calculate beforehand). The old behavior can be enabled with --consider-scale
2. Hmm I cannot confirm this, in my case, the rendering window spawns at exactly (0,0). Could it be the case that you are running some other applications related to window placement?
Interesting feature by AutoHotkey there... might look into it if the current workaround does not work one day^^
- ProMaceDec 01, 2021Copper Contributor
Hi PyKen, I did a few tests sharing from home --> work and these are the results:
Not running as administrator
- Positioning of the Main Window works fine. This helps confirm that Windows policies are interfering one way or another on my company laptop.
- Sharing works fine.
Running as administrator
- Positioning of the Main Window works fine.
- Sharing exhibits the same gray 'ghost window' effect. So this issue appears to be of a more general nature. Can you reproduce this?
Very curious to find out why 'run as admin' is causing an issue!
Best regards,
ProMace
- PyKenDec 02, 2021Copper Contributor
ProMaceVery interesting. In my case, I do not have those limitations, so I can run it as non-admin without any problems. I can, however, confirm the gray 'ghost window' effect when I run it as admin and share the main window over Teams. Capturing the main window in OBS shows no 'ghost window' effect, so I assume this is, again, a Teams specific capturing logic and there is probably no way around it 😐
I wonder which policy on your work environment is hindering the main window to be positioned when running as non-admin... But as long as it is the main window, I guess it is not a critical thing:)
> is there a reason to have width and height parameters for the Main Window?
You are right, no, there is no reason
For now, you can safely ignore those parameters. Maybe in future, it could be used to define some scaling between the captured and rendering content.
- ProMaceNov 30, 2021Copper Contributor
PyKen Okay, so I tested further and this is getting really interesting... I figured out the following:
1. The new default behavior (ignore scaling) actually gives me the pixel-perfect result I was looking for! Much better than the previous version where the mirrored image was a little blurred.
2. The app wasn't responding to my command line parameters for the Main Window coordinates at all. No matter what I entered, it would show up at the same location.
3. I then found that running the program as an administrator made it behave as expected with regard to the Main Window coordinates. However...
4. ... running the program as an administrator introduces a new issue, which is that any window dragged over the Main Window will show up as a gray rectangle on the rendered image on the receiver side, at the respective location!

So it has to be a (company) policy-related issue that's forcing me to run as admin, but the 'ghost window' effect when doing so doesn't make sense to me... I've been testing work --> home sharing so far, I'll also look into home --> work as my private laptop will naturally have fewer restrictive policies enabled. In the meantime, could you check what happens on your side when explicitly running the app as admin? Furthermore, any idea why positioning the capture window works fine while positioning the render window does not, when not running as admin?
As always, thanks in advance!

- ProMaceNov 30, 2021Copper Contributor
PyKen Thanks again mate!
I'll be testing this after work. I'll pay special attention to the Main Window positioning and whether it's something on my side that's interfering.Regardless, what I can say upfront is that countless people have been stalking Microsoft for region-based sharing in Teams, and you've managed to come up with a straightforward solution!

Edit: Before I forget: is there a reason to have width and height parameters for the Main Window? Is this not equal to the capture region size, in other words can they be omitted?