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>
- Was only able to move and not migrate vdi if selected from the objects view.
- The text on the ToolStripMenuItems on the SrStoragePage was different from the
corresponding buttons.
- Added item move/migrate to the multiple VDI context menu. The Properties item
should not be shown in this case.
- fixed issue where the context menu with add/attach items was not available
for empty list or when empty space was clicked; in the latter case I also clear
the selections
- added ability to launch the context menu by using the windows properties button
- moved context menu to the designer; changed code to show/hide the relevant menu
items instead of adding new ones each time the context menu opens
- added icon to the context menu item Properties
- fixed button layout (part of CA-100083), then removed separators between buttons
because when they wrap it looks a bit strange
- fixed some weird cross-threading exception (could not reproduce reliably)
- renamed one or two class members and tidied up the button event handlers
Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
VMstorage page uses the default colours of the controls, hence we only need to set
them on the VNCTabView and the linklabel does not need to be public.
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.
