Could it be that one of the processes called from this code is specifically setting the cursor back to normal? That would defeat the whole Cursor wait showWhile: process.
Progress bars or other non-shared state do seem safer to utilize for core activities like this. -cbc On Thu, Apr 3, 2014 at 12:18 PM, Sebastian Sastre < sebast...@flowingconcept.com> wrote: > > On Apr 2, 2014, at 12:10 PM, Goubier Thierry <thierry.goub...@cea.fr> > wrote: > > MCWorkingCopyBrowser>>basicSaveVersionIn: > basicSaveVersionIn: aRepository > | newVersion waitForVersion | > waitForVersion := Semaphore new. > > UIManager default defer: [ > newVersion := workingCopy newVersionIn: aRepository. > waitForVersion signal ]. > > Processor activeProcess == UIManager default uiProcess > ifFalse: [ waitForVersion wait ]. > newVersion ifNil: [ ^ self ]. > > Cursor wait showWhile: [[ > self > storeVersion: newVersion in: aRepository; > storeDependencies: newVersion in: aRepository.] > ensure: [ (MCVersionInspector new version: newVersion) show ]] > > It seems asynchronous, but I'm unsure of what it is doing. Progress bar is > only displayed when doing newVersionIn:, but this is sent to the UIManager. > And this is done in a fork (see saveVersion), so it's probably allways > possible to interrupt the thing half-way (or save). > > Anybody to explain what is the objective when writing code like that? > > > Good question Thierry. > > I'm sure the cursor was normal during this episode. Suggesting that either > it wasn't storing the version or it was but not displaying the wait cursor > as the code suggests. > > Functionally, what sounds to me it should be doing, is overwriting the > files which is reasonable to take a little. It takes reasonable time, > that's not the problem. Lack of feedback is the problem. > > So one solution would be to provide a progress bar for that file writing > process or whatever is doing. > > Having one progress bar for the whole process would be the best solution. > Plan B would be having 2 progress bars, ending when it really finishes. > BTW, note that *not* giving control to the user while is saving would > also prevent this kind of accidents. > > > > > > >
