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>
override in derived classes, enforce it by wrapping the page specific code in
a new virtual method, which the derived classes can override and PageLeave can
call before its own logic.
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>
on a background thread and show a spinner while this is going on. Also: run this
check only the first time the page is loaded; some refactoring, namely simplified
the code scanning for SRs by reducing the number of things each method does;
fixed column widths; removed unused property.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
* CA-77990: Report required actions for all VMs at once in the hotfix wizard / RPUW
* CA-77990: Resolve precheck problems in parallel in the Patching wizard
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
* CA-77990: Resolve precheck problems in parallel in the Patching wizard
Changes following code review: Made the ParallelAction work across connections and removed CrossConnectionParallelAction
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
* CA-77990: Modified ParallelAction to create queue on RunSubActions only, with the correct queue size
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.
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>
Make Resolve All button visible (the button and the "resolve all" logic existed already; the button's visibility was set to False).
Signed-off-by: Adrian Jachacy <Adrian.Jachacy@citrix.com>
Clear All button disabled when no rows selected; Select All button
disabled when all rows selected.
Signed-off-by: Adrian Jachacy <Adrian.Jachacy@citrix.com>
1. Resized columns on the LOcate Mirrored SRs page in the DR Wizard.
2. Changed wording of DR_WIZARD_STORAGEPAGE_DESCRIPTION_FAILBACK and
DR_WIZARD_STORAGEPAGE_DESCRIPTION_FAILOVER messages.
