Bugs / Найденные баги (1)
- Author
- Message
-
Offline
- Posts: 15
- Joined: Fri May 10, 2013 3:29 am
Странные даты изменения файла
При создании файлов типа txt в Акелпаде почему-то вижу у них странные даты "последнего изменения", от 1999 до 2014 года. А при изменении этих файлов, опять же Акелпадом, дата изменения не обновляется, остаётся прежней. Файл-Эксплорер использую с QtTabBar'ом и думал, что это его проделки. Но обычным Нотепадом или УльтраЭдитом даты изменения записываются нормально.
4.8.4 (x64) Win7
4.8.4 (x64) Win7
-
Offline
- Posts: 84
- Joined: Fri May 28, 2010 1:28 pm
При использовании GoldenDict (GoldenDict-1.5.0-RC-11) захватывается только одна буква слова, с notepad и Notepad++ работает нормально.
У меня было, делал репорт, но закономерностей не нашел. Удалил *.ini тулбаров и контекстного меню, вроде больше не беспокоило.Drugmix wrote:У меня в подменю "Plugins" рандомно исчезают некоторые менюитемы из списка.
-
Offline
- Posts: 15
- Joined: Fri May 10, 2013 3:29 am
OK, thanks!KDJ wrote:You should disable this option.фдуч wrote:"Save file time" is checked (ON).
1. Advice: call this option "Preserve 'modified' time" (Не обновлять время изменения), otherwise it can be understood as opposite.
2. Still, however this option is, it's a bug if Akelpad creates files with strange "Last modified" time, like... 1699 AD. Kinda Time Machine?
-
Offline
- Site Admin
- Posts: 6311
- Joined: Thu Jul 06, 2006 7:20 am
См. PaintOptions = 1. Если ручной параметр PaintOptions уже содержит флаг 1, то скорее всего используется txt.coder. В этом случае, перевод можно осуществить, предварительно выделив текст.private_joker wrote:При использовании GoldenDict (GoldenDict-1.5.0-RC-11) захватывается только одна буква слова, с notepad и Notepad++ работает нормально.
Тестоваяфдуч wrote:...Akelpad creates files with strange "Last modified" time, like... 1699 AD.
-
Offline
- Posts: 84
- Joined: Fri May 28, 2010 1:28 pm
Instructor
Действительно, так заработало. Яндексом искать по сайту (по привычке, для в основном русскоязычных ресурсов) была не лучшая идея, поди ж ты, а вот google и внутренний поиск находит.
Действительно, так заработало. Яндексом искать по сайту (по привычке, для в основном русскоязычных ресурсов) была не лучшая идея, поди ж ты, а вот google и внутренний поиск находит.
-
Offline
- Site Admin
- Posts: 6311
- Joined: Thu Jul 06, 2006 7:20 am
Выложите/вышлите папку с AkelPad'ом. Укажите операционную систему.Drugmix wrote:У меня в подменю "Plugins" рандомно исчезают некоторые менюитемы из списка.
Не пробовал воспроизводить , но это уже заморочки системы.Drugmix wrote:У меня наблюдается медленная прорисовка содержимого окна акелпада после n (~50) часов неактивности. Это уже известный баг?
yozhic
Выложите/вышлите указанный текст в виде файла в кодировке Юникод.
Northtech
Программе приходиться часто вызвать функцию прорисовки картинки, чтобы заполнить область, где будет рисоваться текст.
-
Offline
- Posts: 30
- Joined: Thu Aug 21, 2008 9:31 pm
Instructor
Пытался перекодировать в 866 кодировку строку в файле, набранном в кодировке 1251, и обнаружил странное поведение Акелпада. Такое впечатление, что внутренняя команда перекодировки (Alt+R) работает наоборот!
Пример. Файл открыт в кодировке 1251. Первая строка в файле набрана в кодировке 1251, вторая - в кодировке 866 (при открытии файла в кодировке 866 2-я строка читается правильно).
При перекодировке обеих строк из 1251 в 866, казалось бы, первая строка должна стать такой же, как исходная вторая (то, что мне было нужно), но нет! Первая строка становится абракадаброй, а вторая - такой, как исходная первая! То есть реально происходит перекодировка из 866 в 1251.
А вот при перекодировке обеих строк из 866 в 1251 происходит то, чего я добивался: первая строка становится такой, как исходная вторая, то есть реально происходит перекодировка из 1251 в 866.
Это баг, или так и задумано?
Пытался перекодировать в 866 кодировку строку в файле, набранном в кодировке 1251, и обнаружил странное поведение Акелпада. Такое впечатление, что внутренняя команда перекодировки (Alt+R) работает наоборот!
Пример. Файл открыт в кодировке 1251. Первая строка в файле набрана в кодировке 1251, вторая - в кодировке 866 (при открытии файла в кодировке 866 2-я строка читается правильно).
При перекодировке обеих строк из 1251 в 866, казалось бы, первая строка должна стать такой же, как исходная вторая (то, что мне было нужно), но нет! Первая строка становится абракадаброй, а вторая - такой, как исходная первая! То есть реально происходит перекодировка из 866 в 1251.
А вот при перекодировке обеих строк из 866 в 1251 происходит то, чего я добивался: первая строка становится такой, как исходная вторая, то есть реально происходит перекодировка из 1251 в 866.
Это баг, или так и задумано?