R6034(не смог правильно инициализировать CRT)
Причину ошибки выяснил: возникает при попытке подгрузить плагин(либо при автозагрузке, либо при перечислении в окне плагинов. Хотя в при автозагрузке у меня не всегда выскакивает), у которого есть манифест. Но Акел не падает, работает дальше.
Плагин с манифестом с CRT не линкуется вообще, только с user32 и kernel32(манифест туда попал случайно, вероятнее всего при добавления 64-битной платформы студия сделала лишнее).
(Вынужден линковать Акел с libcmt.lib на 32-битной платформе ибо с какого-то перепугу AkelEdit.obj требует @__security_check_cookie@4)
У меня неумный вопрос... Открыл проект QSearch8x, добавил новую платформу x64 (настройки наследованы от Win32), и при попытке собрать Release x64 выдаёт вот что:
1>DialogSwitcher.obj : error LNK2001: unresolved external symbol __imp_SendMessageW
1>DialogSwitcher.obj : error LNK2001: unresolved external symbol __imp_ShowCaret
...
1>QSearch.obj : error LNK2001: unresolved external symbol __imp_RegQueryValueExW
1>QSearch.obj : error LNK2001: unresolved external symbol __imp_wsprintfA
...
1>QSearchDlg.obj : error LNK2001: unresolved external symbol __imp_GetWindowLongA
1>QSearchDlg.obj : error LNK2001: unresolved external symbol __imp_CreateWindowExW
...
1>QSearch.obj : error LNK2001: unresolved external symbol __imp_RegQueryValueExW
advapi32.lib
Я так предполагаю, студия настройки дополнительных либ при переходе через платформу копировать не пожелала(на всякий случай. Я бы тоже не пожелал бы). Я точно не вспомню, было ли у меня такое, или нет.(Только у меня версия студии 9.0, и поведение может быть разным)
PS: не забудьте что для сабклассинга на x64 нужно использовать Get/SetWindowLongPtr
Instructor wrote:Выход использовать свои memcpy и memset (код можно взять из StrFunc.h v4.4).
Кстати, насчёт этого. То, что я хочу предложить далее, не относится к архитектуре x64, а относится к архитектуре AkelPad и всех его плагинов. По моим наблюдениям, практически все плагины так или иначе используют некоторые стандартные функции из набора StrFunc.h, StackFunc.h и, возможно, WideFunc.h.
Предложение: почему бы не вынести эти функции в отдельный вспомогательный .dll файл? Типа сделать что-то наподобие AkelPad-CRT. Это сразу "облегчило" бы все плагины, которые используют данные функции.
Ставил x64-версию на Win7, следующие наблюдения:
1. Нет отдельно скачиваемого Plugs-пака - плохо.
2. Плаги только с английским интерфейсом - плохо.
3. Устанавливал Akel как обычную прогу (первый пункт при установке); запускаю обычный блокнот Windows, в верхней строке пишет "AkelPad - Блокнот", хотя если посмотреть "О программе", то показывает, что это виндовый notepad.exe... - странно всё это.
4. Ни один из плагов FeyFre не заработал, при вызове пишет "dll соотв. плагина по такому-то пути не может быть открыт", или что-то типа того, хотя все dll там есть (правильные пути).
Не знаю, связано ли с этим, но почему-то на папке с AkelPad'ом установлен замочек, хотя доступ на запись в папку и все вложенные папки/файлы под текущим пользователем имеется.
VladSh
2. Выберите "Вид->Язык->Русский" и плагины будут на русском.
3. Чудеса "AkelPad" вместо "Безымянный"
4. Когда делал релиз забыл, что у FeyFre dll для x64 в папке Plugsx64. Попробую автоматизировать, чтобы исключить такую ситуацию. AkelPad-4.5.5-x64-setup.exe перезалил.