[GH-ISSUE #571] Fit to Windows doesn't work on RDP login

kerem commented

2026-02-26 11:58:23 +03:00

Owner

Originally created by @pustohler on GitHub (Nov 22, 2023).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/571

Originally assigned to: @VShawn on GitHub.

Describe the bug
In RDP properties is selected "fit to window". If such a connection is started, the app Window starts normally with a grey background but the RDP (client) content shows up only as a little square in the middle of the app. If the app window is resized the content will fit to window, but all the open windows in the client area remain small in the size of the former square an need to be resized manually.

This behaviour was not recognized within PremoteM.

To Reproduce
Steps to reproduce the behavior:

Configure a RDP Connection with "fit to window" in "Display"
Start this connection
1Remote window opens in normal size but the client content doesn't scale to that size. Instead it remains in a little square area in the middle of the 1Remote windows until this window is resized. After that the client area fits to host window but all open windows in RDP client remain in that little shape an need to be resized manually (see screenshot below)
Behaviour is reproduced at different workstations with different RDP clients

Expected behavior
RDP client area should fit to host window seemless with all the possibly opened windows within in a normal size.

Screenshots

Desktop (please complete the following information):

OS Workstation: Win11 Ent N (22631.2715)
OS RDP connected: WinSrv 2019 Std german 1809 (17763.5122), and other too...
PRemoteM Version: 1.0.0-beta.07

Additional context

Originally created by @pustohler on GitHub (Nov 22, 2023). Original GitHub issue: https://github.com/1Remote/1Remote/issues/571 Originally assigned to: @VShawn on GitHub. **Describe the bug** In RDP properties is selected "fit to window". If such a connection is started, the app Window starts normally with a grey background but the RDP (client) content shows up only as a little square in the middle of the app. If the app window is resized the content will fit to window, but all the open windows in the client area remain small in the size of the former square an need to be resized manually. This behaviour was not recognized within PremoteM. **To Reproduce** Steps to reproduce the behavior: 1. Configure a RDP Connection with "fit to window" in "Display" 2. Start this connection 3. 1Remote window opens in normal size but the client content doesn't scale to that size. Instead it remains in a little square area in the middle of the 1Remote windows until this window is resized. After that the client area fits to host window but all open windows in RDP client remain in that little shape an need to be resized manually (see screenshot below) 4. Behaviour is reproduced at different workstations with different RDP clients **Expected behavior** RDP client area should fit to host window seemless with all the possibly opened windows within in a normal size. **Screenshots** <img width="1338" alt="image" src="https://github.com/1Remote/1Remote/assets/151724759/128d1faa-19f4-49de-b25e-52bc8179c7dc"> **Desktop (please complete the following information):** - OS Workstation: Win11 Ent N (22631.2715) - OS RDP connected: WinSrv 2019 Std german 1809 (17763.5122), and other too... - PRemoteM Version: 1.0.0-beta.07 **Additional context** -

kerem

2026-02-26 11:58:23 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-26 11:58:24 +03:00

Author

Owner

@VShawn commented on GitHub (Nov 23, 2023):

Let me explain why it is not work. The resolution setting API provided by Microsoft RDP client is only effective after the RDP desktop is displayed(after the user logs in). calling the API has no effect and does not return any error codes before this moment.

ANND the RDP client lacks a callback for desktop is shown, This means that the APP cannot determine the appropriate timing to call the resolution setting API. Currently, we are using a fixed delay as a workaround (I knew it's stupid). If the RDP desktop hasn't appeared before this delay expires, our resolution will be incorrect.

I am actively searching for a solution to address this issue by now

@VShawn commented on GitHub (Nov 23, 2023): Let me explain why it is not work. The resolution setting API provided by Microsoft RDP client is only effective after the RDP desktop is displayed(after the user logs in). calling the API has no effect and does not return any error codes before this moment. ANND the RDP client lacks a callback for desktop is shown, This means that the APP cannot determine the appropriate timing to call the resolution setting API. Currently, we are using a fixed delay as a workaround (I knew it's stupid). If the RDP desktop hasn't appeared before this delay expires, our resolution will be incorrect. I am actively searching for a solution to address this issue by now

kerem commented

2026-02-26 11:58:24 +03:00

Author

Owner

@pustohler commented on GitHub (Nov 24, 2023):

But in PRemoteM, which I was using before being forced to switch to 1Remote that wasn't an issue... there the client always seemless fit to the host window without any (visible) resizing or stuck in wrong client area size.
Is that not the same or similar code basis? Maybe, you can do it in 1Remote the same way like there?

@pustohler commented on GitHub (Nov 24, 2023): But in PRemoteM, which I was using before being forced to switch to 1Remote that wasn't an issue... there the client always seemless fit to the host window without any (visible) resizing or stuck in wrong client area size. Is that not the same or similar code basis? Maybe, you can do it in 1Remote the same way like there?

kerem commented

2026-02-26 11:58:24 +03:00

Author

Owner

@stetze commented on GitHub (Nov 24, 2023):

Maybe this is a issue with your configuration? My 1Remote works without problem. The connection automatic fits the windows size and if i resize the window 1remote automatic with the size of the window.

@stetze commented on GitHub (Nov 24, 2023): Maybe this is a issue with your configuration? My 1Remote works without problem. The connection automatic fits the windows size and if i resize the window 1remote automatic with the size of the window.

kerem commented

2026-02-26 11:58:24 +03:00

Author

Owner

@VShawn commented on GitHub (Nov 25, 2023):

Is that not the same or similar code basis? Maybe, you can do it in 1Remote the same way like there?

@pustohler They are basically the same code. I compared the two branches, and the resolution setting part is exactly the same code. The 1Remote program has made code style fixes and added new features based on the PRM code.

By the way, is your desktop resolution set at 100% scaling or a different scaling rate?

Maybe this is a issue with your configuration?

Hard to say, there's no evidence to support whether this is related to system settings or not.

@VShawn commented on GitHub (Nov 25, 2023): > Is that not the same or similar code basis? Maybe, you can do it in 1Remote the same way like there? @pustohler They are basically the same code. I compared the two branches, and the resolution setting part is exactly the same code. The 1Remote program has made code style fixes and added new features based on the PRM code. By the way, is your desktop resolution set at 100% scaling or a different scaling rate? > Maybe this is a issue with your configuration? Hard to say, there's no evidence to support whether this is related to system settings or not.

kerem commented

2026-02-26 11:58:24 +03:00

Author

Owner

@VShawn commented on GitHub (Nov 26, 2023):

hey guys, I try to fix this issue on latest nightly build.

Plz let me know if any improve or it not works since I can not reproduce this issue :)

@VShawn commented on GitHub (Nov 26, 2023): hey guys, I try to fix this issue on latest nightly build. Plz let me know if any improve or it not works since I can not reproduce this issue :)

kerem commented

2026-02-26 11:58:24 +03:00

Author

Owner

@pustohler commented on GitHub (Nov 28, 2023):

Seems to work now. Actually I'm not really sure, what the reason was. I started the nightly build and the effect was still there. Then I deinstalled the old or currently running instance an tried again - no success. Then I removed all the registry entries and files I ever could find relating to PRemoteM or 1Remote respectively and voila! Now the nightly build does the job smoothly.
Thanks a lot VShawn!

@pustohler commented on GitHub (Nov 28, 2023): Seems to work now. Actually I'm not really sure, what the reason was. I started the nightly build and the effect was still there. Then I deinstalled the old or currently running instance an tried again - no success. Then I removed all the registry entries and files I ever could find relating to PRemoteM or 1Remote respectively and voila! Now the nightly build does the job smoothly. Thanks a lot VShawn!

kerem referenced this issue

2026-02-28 12:03:51 +03:00

[GH-ISSUE #461] Crash when running under Windows Server 2008 R2 #1337

kerem referenced this issue

2026-03-01 17:19:30 +03:00

[GH-ISSUE #461] Crash when running under Windows Server 2008 R2 #2297

kerem referenced this issue

2026-03-13 08:28:04 +03:00

[GH-ISSUE #461] Crash when running under Windows Server 2008 R2 #3280

kerem referenced this issue

2026-03-13 08:44:37 +03:00

[GH-ISSUE #461] Crash when running under Windows Server 2008 R2 #3282