GNOME Bugzilla – Bug 561083
[PATCH] Auto track number/count button doesn't set the count for the current track
Last modified: 2008-12-29 20:01:04 UTC
Please describe the problem: Currently the automatic numbering/count of tracks doesn't set the count of the current song. This is due to some funky interaction between the way the current code sets it and the writeClosure invocation, which ends up resetting it. The attached patch fixes that. Apply with patch -p1, because it has an extra path level, because I use git. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Created attachment 122805 [details] [review] Fix
I wasn't able to reproduce this problem. Could you give the steps that make it happen ? Or maybe it's a race condition that doesn't end up the same on my system ?
(In reply to comment #2) > I wasn't able to reproduce this problem. Could you give the steps that make it > happen ? I should have been more descriptive in my initial bug report. It should be 100% reproducible and the steps are: 1) Select a group of track that have no Track Number nor Track Count set 2) Open the Track Editor 3) Click on the "Automatically set track number and count" button next to the track count/number range control top left. 4) Notice that only the Track Number is set for the current track. 5) Click Next track 6) Notice that both Track Number and Count are set for all other tracks. > Or maybe it's a race condition that doesn't end up the same on my system ? > The bug itself is a race condition, but it's 100% reproducible (in theory), because: for (int i = 0, n = Dialog.TrackCount; i < n; i++) { EditorTrackInfo track = Dialog.LoadTrack (i); (0) track.TrackNumber = i + 1; track.TrackCount = n; if (Dialog.CurrentTrackIndex == i) { (1) entry.From.Value = track.TrackNumber; (2) entry.To.Value = track.TrackCount; } } At (1) setting the .Value will raise the WriteClosure for the field, which will then read both From and To controls' text (both are part of the Range control) and set track.TrackNumber and TrackCount. So after line (1) is executed track.TrackCount will be reset back to the value before (0). My patch avoids that by using temporary variables instead of the TrackInfo properties. I said 100% reproducible *in theory*, because I assume that the WriteClosure is executed synchronously.
I can reproduce this. Thanks for catching it and producing the patch, Ivan. One small note, we name private/local variables like_this not likeThis. Anyway, I committed the patch (w/ a few style changes) - thanks!