Stefan Küng wrote:
> Molle Bestefich wrote:
> > > This is a 'bug' in the shell (explorer) itself. TSVN always tells the
> > > shell the correct overlay (and it *never* draws an overlay for the .svn
> > > folder). The problem here is a race condition:
> > > * shell asks for overlay
> > > * TSVN returns the overlay index
> >
> > For the uninitiated, what is an "overlay index" ?
>
> The shell has 16 overlay slots, of which the shell itself uses 4 for
> itself, so 12 are open for other apps to use.
> These 16 overlays are loaded on shell startup and put into the icon
> cache, with the first overlay getting index 0, the second getting index
> 1 and so on. An overlay handler has to first tell the shell that it
> wants to have one of those slots, give the shell the icon data. Then the
> shell returns the index it gave the overlay handler (or an error if
> there are no more slots available). After this, the overlay handler only
> has to return that index whenever it wants to have the overlay drawn.
Thanks for the explanation!
In light of the above explanation, the race condition you explained
doesn't hold water:
> * the overlays are drawn in the 'old' order, even if the reload changed
> the file order shown.
Arne said that he did not add or remove files, so there is no way that
files could be ordered differently in the folder.
This also corresponds to my own observations - I've seen the overlay
applied to the .svn folder a lot of times when there were no change in
folder item order.
(The shell might add items out-of-alphabetical-order when refreshing,
but they seem to always be introduced at the right position in the
list so the list comes out in correct sorted order at the end of the
refresh.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Dec 27 13:45:30 2005