* L10n: Inverness
build_chm # 24
* Revert "L10n: Inverness"
This reverts commit 8b41bb8c79cd4d73ed6021a5533cf7624a5421c4.
* L10n: Inverness
CHMs from build_chm master-l10n #24
Second attempt at checkin with a merge conflict resolve. (I hope)
We always add the VM wizard button to the migrate dropdown, but it's
currently not added until the end of the enable loop - after we've
calculated whether we can boot on each host. There's no reason to wait
until we've done all that before showing the wizard, so add it straight
away to the end of the list before the loop.
Signed-off-by: Callum McIntyre <callum.mcintyre@citrix.com>
When we right click migrate a VM we load all the hosts in the pool into
a dropdown, and then one-by-one assert whether the selected VM can boot
on that host, enabling each option where this is positive. If the
dropdown is exited then nothing stops these assert calls from
continuing, and looking at the logs we can see that they do.
With a large pool this is problematic because the UI basically locks up
until it's completed all these asserts, even if we've already selected a
host to migrate to. If we try to migrate another host then we see in the logs that both the old thread and new
thread are making `assert_can_boot_here` calls, and the UI for the new
thread doesn't function until the old one has finished.
This commit adds a new property `_isDropDownClosed`, which is set by the
new `OnDropDownClosed` event handler. In the loop enabling dropdown
items, each iteration we check this property - and if it is true then
the dropdown is no longer showing so we stop the loop and thus don't
call any more `assert_can_boot_here` commands. This stops the UI locking
up after the dropdown is closed.
Signed-off-by: Callum McIntyre <callum.mcintyre@citrix.com>
Increased the wait between host_enable attempts, allowing to wait more for the host to reboot.
This will affect Automated Updates and other normal Patching Wizard
operations as well.
Signed-off-by: Gabor Apati-Nagy <gabor.apati-nagy@citrix.com>
CA-267330: [Update Wizard Improvements] The Update wizard: block the installation of an update on slaves if a reboot or a toolstack restart is pending on master
* CP-25081: UI improvements for USB passthrough
* CP-25081: Show text when AttachUsbDialog list is empty.
* Fix comments.
* Improve the presentation of warnings in USBEditPage.
* Update warning text of attach usb dialog.
* Simplify the layout of Attach USB Dialog.
* Check if USB devices plugged before showing UI.
* Fix comments.
* Fix comments.
* Improve code.
when the max tolerance is being calculated, the text and icon on top of HA
wizard is no longer visible after this fix.
Signed-off-by: Ji Jiang <ji.jiang@citrix.com>
* CP-24412: Apply a filter before adding USBs to candidate list in Attach Dialog.
* CP-24333: Apply HA restraint.
* CP-24412: Fix a merge error.
* CP-24412: implement actions to attach/detach/passthrough.
* CP-24412: Add license check before making UI components visible.
* CP-24412: Change layout of new components to Dpi.
* Fixed all comments.
* Fix comments.
* fixed comments
This is caused by the `waitingNtolUpdate.waitOne()` call being at the end of the loop, not the beginning. The reason is that the `waitingNtolUpdate` is set during the first iteration (before the thread even gets loaded) - because the setter for Settings in this file sets it (and that's set by the setter for AssignPriorites.Connection, which is set in the HAWizard constructor). So when the thread first spawns we do the calculations, then get to the `waitOne` lock, which is set so we go back around the loop and calculate everything again before returning to the lock and waiting to be triggered. The correct behaviour is to trigger only once on the page load, and then only when re-triggered. To achieve that I've moved the `waitOne` call to the beginning of the loop, so that (assuming the `waitingNtolUpdate` lock is set before the thread is first started) we immediately run the calculations and then stop at the beginning of the loop waiting to be triggered again. This means that on page load (and after each re-trigger) we only calculate once.
The assumption that the lock is set before the thread is triggered is currently valid, because as mentioned above it's currently set by the setter for Settings which is indirectly called by the wizard constructor. I don't want to rely on that behaviour though because it's very indirect, so just to be safe I've added an explicit set just before the thread is triggered so that it's guaranteed to run the calculations the first time. This isn't strictly necessary but seems better than relying on the existing implicit setting. Since we use the same mechanism just in a different place, all the existing code that sets `waitingNtolUpdate` continues to trigger this thread as expected.
Following pattern would be caught when using "XenCenter" "XenServer" and
"Citrix":
1) not "[" or "/" or """ on left of the brand string
2) brand string followed by space followed by not "p", and optional letter
3) optional letter followed by space followed by the brand string
4) brand string followed by "," and optional letter
5) begin with the brand string
6) end with the brand string
tested with all .resx files
Signed-off-by: Ji Jiang <ji.jiang@citrix.com>
