- Simplified SudoElevationResult.
- Renamed SudoDialogDelegate to ElevatedSessionDelegate so that it makes more sense
for projects not referencing WinForms.
- Call directly the RoleElevationDialog within XenAdmin without using the ElevatedSessionDelegate.
- Minor modernisation in AsyncAction.
- Launch GraphDetailsDialog in a using block.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
- Removed DebugHelp. The user settings are normally not meant for debugging code.
- Moved HelpId logic from the main window to the tab pages.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
- no need to register the XenObjects events with the ArchiveMaintainer since
what the handler does is not specific to this class; this can be done on the
Performance page where the events are also registered.
- set directly the ArchiveMaintainer's XenObject to the new value without
setting it intermediately to null as this causes a full data download event
if the object has not changed.
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>
Implemented a generic mechanism to allow tab pages to unregister their event handlers when they are hidden (when a tab page gets deselected)
Also changed VMStoragePage to derive from BaseTabPage, so it could use the same mechanism.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
Now using the EscapeAmpersands string extension method. Also resolved the custom fields display issue in the same way.
Signed-off-by: Callum McIntyre <callumiandavid.mcintyre@citrix.com>
The ticket said the character after the & became a hotkey (like labels etc do with UseMnemonic enabled) but I couldn't reproduce that - & symbols were simply removed from the string. The fix is to replace them with &&, so the string.format prints a single & as it should.
Signed-off-by: Callum McIntyre <callumiandavid.mcintyre@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.
NewAction to use the Action<ActionBase> delegate instead of EventHandler. Thus
there is no need to fire them with Empty or null EventArgs and on several occasions
we avoid casting objects in the event handlers.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
