On 07.02.2013 20:01, Terry Fisher wrote:
> m_bBusy is false.
> The call stack looks pretty clean:
> mfc100ud.dll!CWnd::OnWndMsg() mfc100ud.dll!CWnd::WindowProc()
> mfc100ud.dll!AfxCallWndProc() mfc100ud.dll!AfxWndProc()
> mfc100ud.dll!AfxWndProcBase() user32.dll!UserCallWinProcCheckWow()
> user32.dll!DispatchClientMessage() user32.dll!__fnEMPTY()
> I don't believe that SolidWorks is doing anything to cause the
> problem, but that something with the SolidWorks icon generator is
> triggering a race condition between
> CChangedDialog::ChangedStatusThread() and the main GUI thread. I
> tried 2 things:
> 1) I replace the call to OnBnClickedRefresh() in
> CChangedDialog::OnInitDialog(), with ChangedStatusThread(), avoiding
> the separate thread. In this case, the dialog initialized properly
> without hanging.
of course: in that case the whole message loop is blocked until
everything is done.
> 2) I reverted the change above, and added a Sleep(5000) as the first
> line of CChangedDialog::ChangedStatusThread(). In this case, the
> dialog initialized correctly at first, but after 5 seconds, when the
> thread continued, the dialog went to its "busy" state, and hung
Yes, the thread triggers a refresh on the UI thread.
Seems there's a problem when invalidating windows from a non-UI thread.
This shouldn't be a problem though: invalidating does not draw anything
(yet) and can be done from different threads (could even be done from
different processes). Only drawing must not be done on non-UI threads.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-02-07 20:28:48 CET