AkelPad

Posted: **Tue Jan 04, 2011 10:13 pm**

Последовательность "AkelPadScript:" + hInstanceDLL + ":" + WScript.ScriptName не обязательно уникальна, ибо все составные не уникальны глобально.

Posted: **Tue Jan 04, 2011 10:46 pm**

И сколько же потребуется запустить AkelPad'ов, чтобы hInstanceDLL совпали?

Вряд ли кто-то еще решит обозваться «AkelPadScript».
По крайней мере, ничего страшного при совпадении не произойдет.

Или нужно как-то там перебирать окна, созданные текущим процессом, наверное.

Posted: **Wed Jan 05, 2011 2:57 pm**

Infocatcher wrote:На первый взгляд, проще всего вот так:

Все равно это лучше предыдущего варианта. Обновлено:
goToLongestLine.js
AESCrypt.js *
converter.js
getHash.js
LinesFilter_mod2.js

* Вообще говоря, сейчас там всегда модальный диалог, но в коде предусмотрено открытие немодального диалога, так что пусть будет.

[Upd]
И, резюмируя предыдущее...
Будет ли что-нибудь из LinesFilter_mod.js/LinesFilter_mod2.js (см. viewtopic.php?p=10324#p10324 + немного далее) и RenameFile_mod.js (viewtopic.php?p=10561#p10561) включено в скрипты, поставляемые вместе с плагином?
«Безопасно» ли хранить скрипты в UTF-8/UTF-16 с BOM (см. viewtopic.php?p=10161#p10161 и далее)? Точнее, кто при запуске скрипта читает файл, и где это будет работать.

Posted: **Wed Jan 05, 2011 3:26 pm**

Добавлено: поддержка x64.
Добавлено: возможность использовать bCatchEsc=true и запускать скрипт несколько раз.

Added: support for x64.
Added: ability to use bCatchEsc = true and run the script several times.

ChmKeyword.js v1.3

Posted: **Wed Jan 05, 2011 3:28 pm**

Infocatcher wrote:«Безопасно» ли хранить скрипты в UTF-8/UTF-16 с BOM...

Да, с тех пор как AkelPad сам занимается обработкой скрипта (без WScript.exe).

Posted: **Wed Jan 05, 2011 5:18 pm**

Instructor
И на кой тогда там все еще повсюду \u041D и прочие радости?

Posted: **Wed Jan 05, 2011 7:15 pm**

Instructor wrote:ChmKeyword.js v1.3

Там в 108-й строке

Code: Select all

      AkelPad.MemCopy(lpStructure + (_X64?8:8), lpKeywordBuffer, 2 /*DT_QWORD*/);  //HH_AKLINK.pszKeywords

Так и задумано?

Posted: **Wed Jan 05, 2011 7:20 pm**

Infocatcher, да. Просто писалось по шаблону.

Code: Select all

typedef struct tagHH_AKLINK
{
     int      cbStruct;
     BOOL     fReserved;
     LPCTSTR  pszKeywords;
     LPCTSTR  pszUrl;
     LPCTSTR  pszMsgText;
     LPCTSTR  pszMsgTitle;
     LPCTSTR  pszWindow;
     BOOL     fIndexOnFail;
} HH_AKLINK;

Posted: **Thu Jan 06, 2011 5:51 am**

FeyFre wrote:Последовательность "AkelPadScript:" + hInstanceDLL + ":" + WScript.ScriptName не обязательно уникальна, ибо все составные не уникальны глобально.

hInstanceDLL может совпасть с hInstanceDLL другого процесса?

Infocatcher wrote:И на кой тогда там все еще повсюду \u041D и прочие радости?

Встроенные уже написаны

, а скрипты, что на форуме, без проблем могут быть скопированы и сохранены в Ansi кодировке, например, человеком из КНР.

Infocatcher wrote:Будет ли что-нибудь из ... включено в скрипты, поставляемые вместе с плагином?

Включил наработки из RenameFile_mod.js.

Posted: **Thu Jan 06, 2011 12:45 pm**

hInstanceDLL может совпасть с hInstanceDLL другого процесса?

Да.
HINSTANCE он же HMODULE он же указатель на место куда загружен образ:
1. Вспомните WIN16, int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow);
hPrevInstance - до сих пор описывается как дескриптор предыдущего загруженного экземпляра приложения(хоть и всегда ноль), а в те времена в MSDN прямо писалось что аргументы-HINSTANCE - адреса.
2. Так показывают различные вспомогательные утилиты, например VMMAP Руссиновича(посмотрите в отладке какой нибудь модуль, а потом в этом процессе с помощью VMMAP найдите что лежит по адресу - значению модуля).
3. Так пишет Рихтер, ну например в "Создание эффективных WIN32-приложений с учётом специфики 64-разрядной версии Windows" (ссылку я тут где-то писал).
4. Ну в крайнем случае загляните в в память самостоятельно (LPBYTE)hInstanceDLL - я там вижу старое доброе MZђ

Раз уж выяснили, что HINSTANCE - адрес в памяти, то что мешает загружать модуль в одно и то же место во всех процессах? Только занятость этого места, которая не гарантированна. Так что hInstanceDLL может и совпасть.
А вот если туда привлечь GetCurrentProccessId() то уникальность в разных экземплярах приложения гарантированна.

Posted: **Thu Jan 06, 2011 1:10 pm**

FeyFre

Раз уж выяснили, что HINSTANCE - адрес в памяти, то что мешает загружать модуль в одно и то же место во всех процессах?

Видимо не зря было придумано разделять память между процессами

Posted: **Thu Jan 06, 2011 3:33 pm**

FeyFre wrote:Так что hInstanceDLL может и совпасть.
А вот если туда привлечь GetCurrentProccessId() то уникальность в разных экземплярах приложения гарантированна.

Заменить-то не проблема. Или даже добавить. Только я пока не понял, надо ли.

Instructor wrote:
Infocatcher wrote:Будет ли что-нибудь из ... включено в скрипты, поставляемые вместе с плагином?
Включил наработки из RenameFile_mod.js.

О, правильное восстановление выделения. Будем знать.

А модифицированный LinesFilter.js долго изучать, или там что-то не понравилось?

[Upd]
И в SearchReplace.js надо сделать перевод фокуса на уже открытое окно при повторном вызове.

Posted: **Fri Jan 07, 2011 2:33 am**

Instructor wrote:Включил наработки из RenameFile_mod.js.

Code: Select all

        //Close editing file
        if (AkelPad.SendMessage(hMainWnd, 273 /*WM_COMMAND*/, 4324 /*IDM_WINDOW_FILECLOSE*/, 0))
        {
          ...
          //Open file
          AkelPad.OpenFile(pNewFileFullName, 0, AkelPad.GetEditCodePage(hWndEdit), AkelPad.GetEditBOM(hWndEdit));

Эксперимент подтверждает, что hWndEdit уже закроется, и будут использованы параметры только что открытого документа.

Posted: **Fri Jan 07, 2011 6:00 am**

Infocatcher wrote:И в SearchReplace.js надо сделать перевод фокуса на уже открытое окно при повторном вызове.

Сделано.

Эксперимент подтверждает...

Исправлено.

Posted: **Fri Jan 07, 2011 6:37 am**

2KDJ
FileInfo.js is very good. But when I change the pString into Chinese, the result of stats isn't align like before.
Because of Chinese Character is DoubleByteChar, it seem a Chinese-Char's width equal two latin's.
I suggest one more line of code for support that, like this:

Code: Select all

function Pad(pString, nLen, pType, pChar)
{
  nLen = nLen - pString.replace(/[\u0000-\u00ff]/g,"").length;

AkelPad

Scripts discussion (1)