PersistExpandNodes should not take for granted that the treeview always has nodes.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
once for all the items to be removed, passing in their list as argument. This method,
and the method Clear calling it, are used for alerts, updates, events and connections,
hence changed the handling of the CollectionChanged event in these cases to expect
either a single item or a collection. In the case of alerts, updates and events
this means that we can rebuild the whole list instead of removing single rows which
causes the application to hang for big numbers of items.
Changed the tree builder so that the tree nodes rely on the TreeView's font. If the nodes have their NodeFont != null, then a tree update causes new fonts to be generated for each node and when fonts are being created faster than they could be cleaned up, we reach the GLI handles limit of 10000 (which causes the Out of Memory exception).
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.
In some cases calling Control.Invoke() from a background thread causes that thread to go in a "sleep, wait, or join" mode, while waiting for Invoke to happen, although the UI thread is running normally.
If the Control is the MainWindow, it works as expected, but we've seen it happening while connecting or disconnecting from a large pool, on calling Invoke on controls like NavigationView, AlertSummaryPage, HistoryPage, etc.
To fix this, we call the Invoke on the MainWindow in all the places where we've seen the issue.
With this changes, the previous fix for CA-148245 (call RequestRefreshTreeView on CacheClearing event) is not needed anymore, so I removed that call.
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
icon. Moved class OrganizationalView from XenModel back to XenAdmin as it is more
relevant to the latter. Updated relevant tests. Some code tidy.
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
