lrisora

找到一个bug，从列表中删除或从磁盘删除后 看起来已经没有选中项了，但实际上选中状态仍然维持原样（选中状态以序号记录）没有清空 此时的del等操作仍然有效 不过还需要把”正在播放“的高亮看成”选中“才能解释这个bug 另外补充一个bug， 从列表下方空白区域开始拖动，用那个蓝框框选条目后松手， 此时会处于看起来有些项目选中，实际上却没有选中任何项目的状态 此时用右键菜单是正常的，因为点击时实际选中项会从显示选中那边同步， 但工具栏命令和快捷键都是不正常的 这部分关于维护列表选中状态的代码太复杂了（历史原因） 折腾起来很费劲，因为还有 搜索状态 x 自绘/停靠/浮动/迷你 四个列表间的同步 总结：一定要用右键菜单，目前我只确定这个途径确保安全（其他的代码没读过）

已经加上了，播放器存储的是每首歌曲播放的秒数，所以目前是按”累计时长“排序 不过还在犹豫要不要改成 ÷歌曲时长之后按”累计次数“排序

因为windows的资源管理器只支持到V2.3， 最初默认就是V2.4，在发现这个问题后才加入的设置项，并将默认值设置为V2.3

这个功能还是挺奇怪的，是媒体库更新完成之后再重启一下程序才行 记录路径的map才会更新

[MusicPlayer2.x64.右键菜单图标测试.zip](https://github.com/user-attachments/files/15902555/MusicPlayer2.x64.zip) 试试这个

不太行，MFC的菜单是交给系统绘制的（目前没写自绘，很复杂） Wine对此模拟的有问题，和Windows原生不一致 这个问题还出现在媒体库的文件夹浏览标签页左边的树控件里  还没搞懂Wine的用法，不知道为什么，从github的Action下载的程序总是不能启动 但我自己在Windows电脑上编译的就可以，是因为我从自己的电脑上复制的mfc140u.dll吗？ 在[这里](https://github.com/lrisora/MusicPlayer2/tree/for-wine)稍稍改了一点，绕开一些我看见的Wine的bug

这次更新有以下变化， 重命名时只使用第一个艺术家作为%(Artist) 当单选项目重命名时自动填入当前名称 因为对于某些特殊的曲目（比如有超过10人的艺术家）原来的行为文件路径会超过windows的260个字符的限制 我观察其他软件改用第一个艺术家比较正常，所以是 “/”正常工作 “\”无法识别 如果在列表多选项目再右键批量重命名，那么默认是上一个使用的重命名模板 这里认为“只重命名一项”多半是要手动修改，因为模板一般都是用来批量修改

我正在修那几个Recent类的线程问题， 打算先调整各自的接口再集中到一个类里面， 没想好是维持现有的多个CArchive还是集中到一处（目前倾向于维持原样，某些可能需要提升版本号） 之后或许会对UI线程提供一层缓存，现有对接UiElement的接口有问题， 不能保证多次获取信息之间原始数据没有修改， 比如刚刚获取其有6个项目，这边正在逐个获取，原始数据就删了一个 这给UI那边带来了不必要的特殊情况处理负担，插入一层缓存能解决这个问题（或上读锁之后实时生成，可能有性能问题） 我不想写UiElement那边的代码（因为还没读过），如果觉得这层缓存放在那边比较合适之后可以简单的重构挪过去 文件夹浏览需要解析cue， 这个pr改变了cue解析结构同时解析效能退步到之前的水准，按我的构思，之后需要加一个针对cue的缓存， 形式大概是 ```c++ std::unordered_map // 还没确定下来，大概差不多这样 ``` 这能够将cue解析速度提升到与目前的普通音频同等（几乎不耗时） 也是重新加入内嵌cue支持的前提条件，不用再总读内嵌cue 这样文件夹浏览对cue解析效率就没有担忧 因为目前这样也能用，这个会最后处理 刚刚加了图标，我想是不是把另外两个方向也加上，直接替换掉现有的那四个三角形 歌词偏移调整/排序 都是那个新图标更好 @zhongyang219

为避免最近播放过的列表记录损坏，运行前 **一定要备份** （多半是没问题的） 目前还是刚刚通过编译的状态，有bug 通过某些方式播放时不能正确指定曲目这个bug暂时不会修正，在接下来CPlayer拆分并加入状态机时这部分会完全重写 CPlayer新增的SetList随便写的，为了编译暂时占位用的，有问题 自绘界面的线程应当总是绘制其自己的数据副本，不应直接访问属于主线程的数据 主线程可能在一帧绘制一半的时候修改数据，此时UI线程属于脏读，有可能crash 简单的用锁也解决不了，因为只有在UI绘制一帧的整个过程持续持有锁解决数据一致性问题 而阻塞主线程这样长的时间就失去了独立UI线程的意义 这个问题由来已久，不过直到依赖大量易变数据的ListElement加入才变得明显（实际上发生crash概率还是很低） 我的想法是设计像是CListCache这样的类为UI的绘制缓存所有需要的数据（类似派生CListCache） 例如现在MediaLibPlaylist有静态成员CListCache对象，为其提供数据 只要简单的在Draw之前调用reload即可（按照注释的说明使用CListCache对象） 这需要UI元素的方法结构重新设计，明确区分所有虚方法是UI线程的还是主线程的，不允许混用 比如GetRowCount现在调用m_list_cache.size()，而CListCache对象的size方法不允许主线程调用 CListCache目前还是原型状态，还要折腾几天，之后会有CListSearchCache集成搜索并应用到媒体库窗口 显示ListItem的那些ListElement的静态数据对象最后应该是一个从CListSearchCache派生的类？还没确定 我希望用这个静态对象跨UI的维持特定UI列表元素的搜索状态 显示SongInfo的那些ListElement也需要一个CSongCache，可能使其基于一个歌曲列表对象 我正在考虑，使得CPlayer的m_playlist相关能力让另一个通用的类承担 像是也能用于维护我喜欢的音乐这个特殊列表（移除SongInfo中的is_favourite） WM_CLEAR_UI_SERCH_BOX的发送位置，三个cpp文件已经删了，但在CRecentList没有等价的位置 CRecentList::SaveData()不太合适？因为其在下一曲时会被调用， 另外CRecentList::SaveData()调用不足/过多？这是另一个问题（肃清CPlayer后研究） 那个行数变化时调用的方法看着很奇怪，和这个一样，我想可能不应该有这两个方法 实际上这没能覆盖所有情况，有很多不同步的bug在这里 \的头文件在Define.h include后其他地方不用再次include 但不知道为什么，加入新文件到项目时新文件需要在第一次build（即使失败）后才能认识到预编译头的存在...

排序确实有问题，或许需要为 CompareStringEx 加上 SORT_DIGITSASNUMBERS 标志，使其排序时解析数字 （[文档](https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-comparestringex)这么说的，我没试过） @zhongyang219 如果有元数据（艺术家/标题）的话，播放列表内多选右键重命名，可以使用模板重命名 简单的重命名的话我推荐 [ReNamer](https://www.den4b.com/products/renamer)，很好用 更新: ReNamer 也能直接读元数据，以前没注意到