Also ensuring that if the UpdateSessionDisplaySettings function (which we use for resize) is not supported, then we display the console centered in the parent window and with scrollbars if needed
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
In addition to ticket requirements, the console size is updated when the console is:
- resized in undocked mode
- resized manually by dragging window edges
- resized by dragging the panel splitter
Signed-off-by: Letsibogo Ramadi <letsibogo.ramadi@citrix.com>
- correction to the previous commit: only collect the IP addreses if the PIF is connected or is null
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
- include networks without PIFs in the list of networks to test for RDP (at the end of the list)
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
other than strings. Moved settings of the FullScreenForm from the VNCTabView to
the former class. The FullScreenFormof the VNCTabView is only initialised as
FullSCreenFrom so no casts are necessary. The FullScreenForm is responsible for
updating the connection bar text with the value obtained from the vncScreen everytime
the name of the connection changes. Also reduced visibility of certain members.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
to be shown. It is complicated to have the one control call a method in the other
which checks the state on the first control.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
Auto switch to RDP should be taken after VNC connection got the correct screen resolution.
Also not enable “enable RDP button” before VNC connection get the correct screen resolution.
Signed-off-by: Cheng Zhang <cheng.zhang@citrix.com>
- store the empty vnc password after a successful login, to avoid displaying the login dialog box on a subsequent reconnection attempt
- abort the vnc connection attempt if we notice that vncIP is null and switch back to the default console
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
We observed that some threads can reach deadlock-ish state after they have Invoked into a control's UI thread. When it happens they are all in a waiting for join or in sleep state for very long time, although there should not be any deadlock situations.
It seems this has something to do with multiple parent controls and with which control we invoked on. This should not make a difference, because we have got one UI thread (for MainWindow) they should wait for, but we have seen it does.
The solution that fixed this issue was to invoke on the MainWindow instead of various controls (see a4fe507adf ).
This changeset is changing all our Invokes to invoke into MainWindow
instead of a control itself. (MainWindow's UI thread is the only UI thread
all Control is using in XenCenter)
This changeset should be in place until we have found the root cause or the exact reason for the above.
