libspotify API索引參數。基於0還是基於1？

我一直在玩libspotify，遇到了一些奇怪的事情。是基於sp_playlistcontainer_move_playlist 0還是基於1的索引參數？他們似乎是既，也許既不:)特別是如果我有三個播放列表，我注意到了以下結果：libspotify API索引參數。基於0還是基於1？

sp_playlistcontainer_move_playlist（手柄，0，3，FALSE）

成功，並在索引0（移動播放列表播放列表列表中的第一個）到播放列表列表的末尾。

sp_playlistcontainer_move_playlist（手柄，0，1，FALSE）

失敗，返回SP_ERROR_INVALID_INDATA，根據API規範，這似乎表明我 '嘗試將文件夾移動到自己'。從這我猜想，輸入（原始）索引是基於0，目標索引是1基於。這很奇怪，但是這

sp_playlistcontainer_move_playlist（手柄，0，2，FALSE）

確實出現了移動第一播放列表（從索引0）到第二插槽播放列表（在什麼我會調用索引1，但根據libspotify顯然是2）。

當然這也適用

sp_playlistcontainer_move_playlist（手柄，2,0，FALSE）

所以也許目標指數不基於1 ...也許0僅僅是特殊的套管。思考？

來源

2012-03-05 Ryan Molden

它是基於0的。

移動操作，總是會以列表的狀態索引之前，任何事情做，所以...

移動0到1將被拒絕，因爲它實際上是一個無操作。
要第一個（索引0）播放列表移動到第二位置（索引1），你因爲你希望它是這是目前指數1播放列表後，實際上搬到指數2，。一旦你撥打電話，libSpotify將通過移動索引0是指數1後「提交」的事務，那麼移動都記錄下來一個縫隙，以填補在指數留下的空缺差距0.1

來源

2012-03-06 09:25:56 iKenndac

所以我猜想目標索引是你希望它在之前的列表中的項目，因此移動0-> 1是沒有意義的，因爲0已經在1之前，但移動0-> 2是有意義的，因爲它意味着插槽1中的項目移動到時隙0，先前在插槽0中的項目移動到插槽1（在2之前）。我猜想還有一件奇怪的事情是，如果我移動到3號插槽（即列表末尾，因爲索引2是最後一個'有效'索引），那麼我會得到移動的回調，說newPosition是3，即使在現實是2。 – 2012-03-06 17:25:51

libspotify API索引參數。基於0還是基於1？

回答

相關問題