AkelPad

FeyFre
Тотал 7,50а. С тем же самым командером на windows 7 и windows Wista (только что проверил, тоже на виртуалке), глюк не воспроизводится! вот что обидно!

Кстати, действительно! Что я привязался к командеру... Просто делаю в любой командной строке: "AkelPad.exe filename1.txt", снова иду в командную строку, делаю "AkelPad.exe filename2.txt", теперь ввожу/удаляю символ(слово, не важно), ctrl+s не работает!

Дело то не в фокусе имхо. После открытия по Ф4 я же нормально ввожу символы - стало быть редактор в фокусе. А вот Ctrl+S не срабатывает. Кроме того если открыть только один файл по Ф4 (либо через командную строку) - все чудесно работает, глюк начинается когда открываешь 2 и более файлов через ф4 (и обязательное условие - активные плагины LineBoard и ContextMenu, у которого в главном меню первой строкой идет CLEAR - без этих условий глюк не проявляется!!!).

А как создать дамп? Я в MSVS грубо говоря дилетант, с С++ я на "Вы", всю свою программистсткую жизнь только с Дельфи работал... И для меня слова "MSVS/NTSD/DbgView/любой другой отладчик не используя int 3" ни о чем не говорят... Если скажете как сделать дамп - сделаю... Гулять так гулять...

Для чистоты эксперимента вечером поставлю на виртуалку совсем чистую Windows XP SP3 x86 rus, вообще никакого софта, только командер и Akelpad... Проверю...

Дело то не в фокусе имхо.

ну нет, так нет.

MSVS/NTSD/DbgView/любой другой отладчик не используя int 3"

MSVS - Microsoft Visual Studio - родное актуальное IDE/отладчик для Windows
NTSD.exe - Symbolic Debugger for Windows 2000 - полноценный отладчик для Windows который есть во всех поставках Windows. В плане отладки может не меньше чем MSVS в том числе пошаговая отладка используя исходники.
DbgView утилита отслеживания отладочного вывода(OutputDebugString(), DbgPrint()) от Sysinternals. Отладчики ловят сами вывод у процессов которые ведут, эта ловит всё.
"не используя int 3" - означает отладку приложения не используя точек останова, ни машинных(инструкция int 3), ни OS(вызов DebugBreak()), ни IDE-шных. (int 3 - прерывание точки останова архитектуры 8086, активно используемое во времена DOS, также поддерживается остальными x86 архитектурами помимо отладочных регистров cr0-cr3, dr0-dr3).
Предлагалось не пользоваться бряками для инспекции состояния приложения а с помощью OutputDebugString печатать состояние, а вышеперечисленным софтом смотреть эту печать.
Но раз потеря - не потеря фокуса не влияет на баг, то вышесказанное можете забыть

А как создать дамп?

1. Качаем последнюю версию Process Explorer
2. Берем AkelPad именно версии постройки Инструктора
3. Воспроизводим баг
В вашем случае доходим до места перед несрабатывающим CTRL+S.(Ну или где нужно)
4. В Process Explorer находим процесс АкелПад, в контекстном меню есть подменю Create Dump в котором выбираете Create minidump... или Create Full Dump...

Всё. Получили дамп процесса. Любой уважающий себя отладчик натравливается на него, и разработчик видит состояние процесса, в том числе и стек вызовов каждого потока. При полном дампе разработчик видит всю виртуальную память процесса, будто бы запустил у себя в отладке.
Если файл при себе держит отладочную информацию - отладчик даже подхватит исходники приложения.

Так что если Вам не удастся обеспечить Инструктора подробной информацией о воспроизведении ошибки, то дамп будет единственным способом для Инструктора хоть как-то проанализировать баг. И то если он пожелает.

Итак, докладываю:
Поставил голую Windows XP SP3 x86 rus. Только командер и AkelPad. Включаю - баг не наблюдается. Почесав затылок начал устанавливать по одной все программы, которыми пользуюсь и проверять, не пришел ли баг... В конце концов обнаружил виновника торжества - им оказалась программа RBTray версии 3.3 (она удобно в трей все подряд сворачивает, ясное дело, что она у меня везде стояла ). Снес ее на реальной винде - баг исчез.
Фух!

Instructor
FeyFre
Спасибо за внимание - тот факт что ни у кого больше бага не наблюдается, натолкнул на поиски проблемы в своей системе. Осталось только не понятно, каким образом отключение плагинов LineBoard и ContextMenu гасило проявление бага и почему в AkelPad версии 4.4.3 баг не провлялся в любой конфигурации (или в теперь уже не бага AkelPad, а бага RBTray? ). Ну да ладно, новая версия RBTray не конфликтует с AkelPad, так что вопрос закрыт

FeyFre
Дополнительно спасибо за информацию по дампу - возьму себе на заметку на будущее и если Instructor захочет посмотреть, что же все-таки могло конфликтовать в AkelPad'e с RBTray, сделаю дамп памяти и вышлю
Хотя теперь он и сам может воспроизвести ситуацию, достаточно скачать и установить RBTray 3.3 http://sourceforge.net/projects/rbtray/ ... p/download или http://sourceforge.net/projects/rbtray/ ... e/download

psa1974
Это скорее всего бага RBTray ибо с другим софтом этого назначения у меня работает. Я например пользуюсь Iconic Tray Она мощнее RBTray с точки зрения основной функции(минимизация), и пока меня не подводила, не падала, побочных эффектов не давала, не смотря на то что лет 8 не обновлялась(дата бинарных файлов - 9 ноября 2002 года - могут же писать люди!).

и почему в AkelPad версии 4.4.3 баг не провлялся в любой конфигурации

Если не заметили, релиз плагина ContextMenu v6.0 под 4.4.4 сопровождался не хилым объемом новых фич, а значит и реализация этих фич тоже изменилась, так что оттуда может вылезти не то что бага, а мать родная, и это будет не удивительно.
Ага, вот и нашел возможную причину бага: RBTray лезет в системное меню окна и пытается туда вселить собственные пункты.

Дополнительно спасибо за информацию по дампу - возьму себе на заметку на будущее

Я совсем не уверен что Борланд кушает эти дампы. Так что специально для них придется Вам пересаживаться на C++. Впрочем возможно какое-то Борладовское RTFM что-то конкретное по этому поводу может сказать наверняка.

FeyFre
Посмотрел на Iconic Tray - да, удобная софтинка, горячие клавиши - предел мечтаний

Ага, вот и нашел возможную причину бага: RBTray лезет в системное меню окна и пытается туда вселить собственные пункты.

Я так понял, что удалось воспроизвести мою ситуацию?
Возможно это причина, видать неспроста они в следующих версиях отказались от этой идеи. Хотя, опять же, LineBoard чисто интуитивно (исходники не смотрел) не связан с меню... Однако влияет... Глубоко оно как-то закопано...

Я совсем не уверен что Борланд кушает эти дампы. Так что специально для них придется Вам пересаживаться на C++

Не, пересаживаться на C++ пока не планируется. Но зато если что я буду знать, как разработчику на С++ отдать дамп на растерзание
Хотя конечно подобную ситуевину выявить на удаленной системе весьма проблематично в любом случае.

psa1974
Вот это баг репорт понимаю: сам нашел ошибку, сам нашел причину ошибки Пользуюсь WinXP SP3 x86.

1) При копировании нетекстовых фрагментов копируется только кусок (подозреваю, до первого нулевого символа).

2) В списках ручной перекодировки нету UTF16, хотя в Настройках-Параметры-Фильтр они есть.

Акель 4.4.4

2) В списках ручной перекодировки нету UTF16, хотя в Настройках-Параметры-Фильтр они есть.

Акель 4.4.4

1. Замечено ещё в AkelPad 4.1.7
2. Объяснено Инструктором как фича тут

2. Объяснено Инструктором как фича тут

Досадно... довелось мне тут столкнуться с файлом, где сначала идёт текст в ANSI, а затем в UTF16. А надо его было перегнать в ANSI. И не скопируешь UTF16 часть в новый док (по причине глюка №1), и не сконвертируешь на месте (по причине глюкофичи №2).

А интересно, в чем же причина №2? То, что в выделенной области может остаться "разорванный" символ? Так с UTF8 такая же фигня, однако в неё перекодировать можно.

Единственное что могу посоветовать до выхода фикса - попробовать скомбинировать HexSel и какой-нибудь скрипт для перекодировки Hex в символы.

Fr0sT

1) При копировании нетекстовых фрагментов копируется только кусок (подозреваю, до первого нулевого символа).

Стандартный текстовый буфер обмена не имеет параметра указывающего длину текста, т.к. предполагается, что текст заканчиватся NULL символом. Однако можно скопировать текст методом Drag'n'Drop с версии 4.2.6 это поддерживается.

Досадно... довелось мне тут столкнуться с файлом, где сначала идёт текст в ANSI, а затем в UTF16.

Такого я еще не встречал

Такого я еще не встречал

Демонстрирую до чего могут довести кривые руки ) (Хоть и пример искусственный, но реально на такое можно попасть тоже)В результате получаем файл который имеет в виду Fr0sT.

Instructor

Стандартный текстовый буфер обмена не имеет параметра указывающего длину текста, т.к. предполагается, что текст заканчиватся NULL символом. Однако можно скопировать текст методом Drag'n'Drop с версии 4.2.6 это поддерживается.

Аааа, вот оно что...

Такого я еще не встречал

Проще простого: писал лог в юникоде (по дефолту), а у нас все под ФАР-ом сидят, пришлось делать вывод в ASCII. А сконвертить имеющийся файл забыл, вот и получилась такая мешанина).

А как насчёт UTF16 кодировок в окне ручной перекодировки?

Проще простого: писал лог в юникоде (по дефолту), а у нас все под ФАР-ом сидят, пришлось делать вывод в ASCII. А сконвертить имеющийся файл забыл, вот и получилась такая мешанина).

Дело конечно не моё, но я бы посоветовал подвесить за одно место "всех сидящих под ФАР-ом", вместо перекодировки в ANSI.
Какой резон сидеть в UNICODE системе и пользоваться ANSI софтом? Пусть пользуются 98 виндой, раз так хотят.
Невылавливаемых багов захотели? Они вам гарантированны.(А если ещё кривомозгие программисты/пользователи которые вместо того что-бы указать в настройках кодировку windows-1251 лезут в настройки системы и подставляют кодировке 1252(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\1252) таблицу перекодировки c_1251.nls, то вообще можно вешать без суда и следствия.)