PageLoaded override in derived classes, enforce it by wrapping the page specific
code in a new virtual method, which the derived classes can override and PageLoaded
can call after its own logic.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
on the VM Snapshots page; update VM's status on the Snapshots page when the
VM's membership in a policy changes.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
it's not needed as it does not make server calls. Some more refactoring and corrections
here and there.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
prevent them from being serialised alongside the API properties. This will also
be useful for moving the API bindings out of XenModel.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
- removed unused methods and properties from the NewPolicyWizard class
- made the wizard pages private in the NewPolicyWizard class
- removed unused constructor from the NewPolicySnapshotTypePage class
- removed unused property from the PolicyHistory class
- removed the public properties TreeView and DataGridView from the SnapshotsPage
- removed the PolicyType from the PolicyAlert class and the constructor that is no longer used
- removed unused property from the VMSS class
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
According to the Microsoft style guide XC to use 'username' for UI fields and use 'user name' when it's being referred to.
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
quiesce after installing vss tools
Enabling snapshot policy type to be changed to quiesce from
other snapshot policy types if the selected VMs are
quiesce snapshot capable.
Signed-off-by: Sharath Babu <sharath.babu@citrix.com>
- The license restriction for vss snapshots already exists in trunk. This commit just amends the message displayed when the feature is not available.
Cherry picked from cream-indigo:
CA-190395: Replace the usage of FEATURE_NOT_AVAILABLE_NEED_ENTERPRISE_OR_PLATINUM_PLURAL
Signed-off-by: Cheng Zhang <cheng.zhang@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.