This allows any directory request to be aborted while the busy dialog is up.
The busy dialog will be be modal in a sense to it will swallow events as if it was a true blocking modal. But it will not block whoever made it modal. It will only respond to back or previous menu actions.
I think you'll want a check for dialog closing/already shown in Show_Internal given that you're calling it all the time.
I wonder what happens when a modal dialog pops up though - wouldn't that occur only while you're sitting in ProcessRenderLoop(false) at the bottom there (as modal dialogs can only run the process loop from the app thread via app messenger), and thus you won't be hiding the busy dialog at all in that case?
If you want the busy dialog to hide when another dialog pops up it will have to be done in the busy dialog itself (or at some other point in the ProcessRenderLoop()).
Given this, I wonder if a method similar to the progress dialog should be used instead, i.e. where you essentially just grab the busy dialog, throw it up on the screen and repeatedly tell it to process on some interval. The only difference between the methods currently is that the progress dialog allows the window open anim to complete before returning control to the caller (reason is that it's generally used in cases where it can be quite a long time between updates being called).
Once sorted, it would be good to generalize this so that we can execute any (cancellable) CJob in a modal way (i.e. throw up progress/busy while the job is in progress, returning once done or cancelled).
It works when processbar shows up for python. But true that is threaded separate, hadn't realized.
I think it only calls Show() once. Once it has routed the busy dialog which i think happens on first process, the topmostdialog is the busy dialog so show won't be called again.
Moving the hiding/showing into busy dialog would make more sense. Ie it should not unload, it should just hide controls if modal dialog shows up ontop of it.
Yeah - it kinda makes sense to combine progress and busy in some respects - you never need them both up at the same time, the busy is just a more discrete version of it really.
How about this. Only call Show() once. It handles it's hide/show internally based on if it's the topmostmodal dialog.
We should however add something like the threading in CDirectory to the CMediaWindow's instead, so we could do the additional processing on the CFileItemList in the job instead of app thread. But that is for another time.
Better I think, yes. I presume dvdplayer doesn't complain (it uses busy dialog as well on startup?) with this, as it doesn't really matter whether ProcessRenderLoop(true) or ProcessRenderLoop(false) is called.
Agreed about moving this to the mediawindows (and file browser) - generalizing it so it can run an arbitrary job might be the way to go?
Yea I was thinking of that. Some sort of wrapper around the the job manager where app thread can wait for a job in main thread to complete while still rendering.
changed: allow any threaded directory requests to be canceled by aban…
…doning the directory request job
changed: make sure we shutdown remote control on shutdown as well