There is only one instance of CGUIDialogBusy and CGUIDialogProgress, so you
can't get two of 'em up.  As the second entry is the app loop, it'll be
pretty much similar to first entry except that the dialog is already on
screen, so the StartModal() call (or the Show method on busy) will
basically be a noop, then the Progress() calls will run the rest of the app
loop.

Perhaps the problem is continual re-entry, causing stack overflow?


On Wed, Apr 10, 2013 at 6:56 PM, t4-ravenbird <notifications@github.com>wrote:

> In xbmc/Application.cpp:
>
> > @@ -5058,17 +5058,23 @@ void CApplication::Process()
> >    // dispatch the messages generated by python or other threads to the current window
> >    g_windowManager.DispatchThreadMessages();
> >
> > -  // process messages which have to be send to the gui
> > -  // (this can only be done after g_windowManager.Render())
> > -  CApplicationMessenger::Get().ProcessWindowMessages();
> > +  // only do full processing when m_slowTimer running
>
> Yes, that pretty much describes it - and it is also how it actually is
> made. There is the while-loop like CDirectory::GetDirectory() , only
> difference is there are multiple steps.
> But I suspect CDirectory::GetDirectory() would also get into trouble if
> (for some reason) it got called re-entrantly when doing ProcessRenderLoop()
> with a request to open same directory again. As I read the code it would
> bring up yet a new Dialog as opposed to render the first that was shown?
> That is the situation wakeOnAccess ran into.
> (I will update PR with changes based on review so far)
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/xbmc/xbmc/pull/1892/files#r3728399>
> .
>