The result was that numbers were changing suddenly; in cases of slow connections,
a user could make a selection before the scan was over.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
- Fixed button enablement on the IntraPoolCopy page.
- Regression on the NewDiskDialog were selection was considered valid
even if the SR was disabled.The SrSelectionChanged and SelectedIndexChanged
were fired in the wrong order. To fix this the event SrSelectionChanged
is removed (in reality after the refactoring in 5b79b1dc94
it became obsolete).
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
- Made storage selector blurb for XVA import a bit more informative.
- A simple checkbox for starting the new VMS on the finish page is adequate.
- Typos. Property modernisation.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
hidden and in all other cases it was set by the implementing control, i.e.
the label was not reusable, hence no reason to have it in the control and risk
layout issues. This means that the SrPicker does not need to be a control
encapsulating a CustomTreeVIew, but simply derive from the latter.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
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>
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>
