- CA-359068¨Match the whole datasource name (previously the wrong one was picked
for disk read/write latency).
- New/edit Graph dialog: differentiate between enabled/disabled datasources and
visible/hidden (known/unknown units; the latter may mean no data).
- Some refactoring.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
Also tidy up code
Also remove method in `SnapshotTreeView.cs` that wasn't used, which necessitated a null check
Signed-off-by: Danilo Del Busso <Danilo.Del.Busso@citrix.com>
- Replaced remaining instances of SystemIcons. SystemIcons.Information of size
32x32 were excepted as we don't have the right size icon yet.
- The question mark icon is used for help, not for asking questions.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
The bad message was in the dialog created in the BugToolWizard after selecting servers. Since this method is the only one using the ActionProgressDialog(String) constructor, I've modified that ctor to hide the subaction label - which makes sense because there is no action in that ctor (to set a subaction) and no other appropriate label.
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>
