|
|
Yes, the mentioned methods are performed in the window context so they really are executed for the current window. As for the __window = app.dialogs.getMainWindow()._window I think this is quite dangerous workaround as then also methods that are meant to be performed in the dialog window context are performed in the Main window. (e.g. window.uitools.unselectAllText) Nevertheless you are true that methods like window.uitools.refreshView are probably always meant to be executed within the main window -- so tweaking them makes sense. Something like: if (!window.isMainWindow) { var mainWnd = app.dialogs.getMainWindow(); mainWnd.getValue('uitools').refreshView(); } |
|
|
Fixed in 5.0.4.2658 i.e. uitools.refrehView, whole navUtils and nodeUtils are now always executed in the main window context (because of the following code change): image.png (26,576 bytes) |
|
|
Maybe not only uitools.refrehView() from uitools, but others as well, like uitools.getSelectedTracklist(). |
|
|
Re-opened as this caused a regression in 2658: Accessing Properties > Classification throws exception now (because of the changes to nodeUtils for the related Playlists tree there). The reason is that Properties dialog uses TrackPlaylistsTree component that defines some own nodeHandlers in the Properties window context, but nodeUtils accesses nodeHandlers of the main window instead. So I reverted the "fix" in 2658 for nodeUtils (to keep the window context again). => Fixed in 2659 |
|
|
Verified 2661 No new regressions found |
- Anonymous
