Closed hoppfrosch closed 10 years ago
I tried here and it works. If you look at the corresponding code, it looks to be an issue of the LISTVIEW functions. I see two places which can be at fault.
rSel
is supposed to contain the channel and clip to delete. Maybe it has nothing. Link LV_Delete(last_Row)
loop % LV_GetCount()
{
LV_GetText(out_ch, A_index, 1)
if ( out_ch == ch )
{
LV_GetText(out_cl, A_index, 2)
if (out_cl>cl)
LV_Modify(A_index, "", out_ch, out_cl-1)
}
}
Which version of AHK are u using ? Can you try with the default distributed version.
Currently I'm using latest AHK_L version 1.1.15.00 Unicode 32bit - I'll try to use the distributed version
@hoppfrosch Please update this issue (bug report).
Wasn't able to reproduce this behaviour recently ... (Tested wit Clipjump 11.4 compiled and Clipjump 11.4 AHK-Sources runnong AutoHotkey 1.1.15.0)
Closed issue
Following situation:
A few clips (>100) are within a channel. Now I tried to delete some clips from the channel via Channel Organizer.
I same cases it works - but in most cases it fails. The clips are removed within the clip organizer (at least the ChannelOrganizer interface does not show the clips anymore) but after closing and reopening the Organizer the seemingly removed clips are back again.
In my examle I had 161 clips in my clipboard and tried to delete clips no. 153-159. You see the result in attached screenshot![2014-05-28 08_53_31-clipjump channel organizer](https://cloud.githubusercontent.com/assets/419075/3101503/b3e7ff4a-e635-11e3-94d1-7438be0268b3.png)
What you see: after removing the desired clips, there is a "gap" in the numbering of the clips (153-159) are missing. This is the error case. In the working case there is NO Gap - each deletion decreases the numbers of the subsequent clips. (161 becomes 160, 159, 158 ...)
In error case: After removing and reopening the C.Organizer there are back 161 clips ....
Edit: Deleting the clip before the last clip everything works fine (Deleting clip 160 makes 161 become 160, deleting 159 ...