Спасибо!Instructor wrote:Исправлено: ошибка при закрытии программы с открытым немодальным диалогом (Win7).
Scripts plugin
- Author
- Message
-
Offline
- Posts: 1862
- Joined: Mon Aug 06, 2007 1:07 pm
- Contact:
-
Offline
- Site Admin
- Posts: 6311
- Joined: Thu Jul 06, 2006 7:20 am
Добавлено: дублирующий метод WScript.Arguments.Count для WScript.Arguments.Length.
Added: duplicate method WScript.Arguments.Count for WScript.Arguments.Length.
Scripts plugin v7.8
Added: duplicate method WScript.Arguments.Count for WScript.Arguments.Length.
Scripts plugin v7.8
-
Offline
- Site Admin
- Posts: 6311
- Joined: Thu Jul 06, 2006 7:20 am
Исправлено: передача аргумента в VBS скриптах.
Fixed: passing arguments in VBS scripts.
Scripts plugin v7.9
Fixed: passing arguments in VBS scripts.
Scripts plugin v7.9
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
Добавлено: дублирующий метод WScript.Arguments.Count для WScript.Arguments.Length.
Code: Select all
//WScript.Arguments object
[uuid(DBE547D2-2917-4945-A73E-5E583C3F2EB8), helpstring("IWArguments object"), object]
interface IWArguments : IDispatch
{
//"Retrive argument by index."
[id(DISPID_VALUE), propget] HRESULT Item(int nIndex, [out, retval] BSTR *wpItem);
//"Get number of arguments."
[id(1), propget] HRESULT Length([out, retval] int *nItems);
//"Get number of arguments."
[id(2), propget] HRESULT Count([out, retval] int *nItems);
};
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
Instructor
Зато в JS играет, и в других языках будет играть.
Кстати, о других языках. Скрипты с расширением wsf не желают выполняться. Пишет "сервер сценариев не найден". В свою очередь cscript/wscript выполняют всё как надо. (И расширения wsh это тоже касается). Может стоит модернизировать алгоритм поиска годных для выполнения скриптовых файлов?
Зато в JS играет, и в других языках будет играть.
Кстати, о других языках. Скрипты с расширением wsf не желают выполняться. Пишет "сервер сценариев не найден". В свою очередь cscript/wscript выполняют всё как надо. (И расширения wsh это тоже касается). Может стоит модернизировать алгоритм поиска годных для выполнения скриптовых файлов?
-
Offline
- Site Admin
- Posts: 6311
- Joined: Thu Jul 06, 2006 7:20 am
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
Опять таки фич.реквест к плагину. И как ни странно, касается моего предыдущего поста(Раз уж с wsf и wsh не судьба)
Речь идет о библиотеках скриптов, точнее о библиотеках для скриптов. Как я это вижу:
В основном скрипте делаем такой вызов:Метод Library(условное название) получает аргументом имя файла-библиотеки, которую нужно загрузить. Искать библиотеку будет в наперед определенном месте(например в AkelFiles\Plugs\Scripts\libraries) по такому алгоритму:
1. Если расширение текущего(основного) скрипта xxx(js vbs) то ищем там скриптовой файл library.xxx и выполняем его(он в свою очередь создает глобальные объекты)
2. Иначе ищем файл library.dll - бинарный платформозависимый модуль, написанный на любом удобном языке. Короче плагин к плагину, который в скрипт добавляет глобальные функции. Ну и к этим функция с основного скрипта можно обращаться. В чем выгоден такой подход? В том, что транслируемыми языками(c/c++,delphi, пр) высокого уровня проще добираться до того или иного API и проще налаживать, чем с помощью oSys.Call() (а в некоторых случаях это вообще не возможно сделать через oSys.Call() - могу привести пример)
Речь идет о библиотеках скриптов, точнее о библиотеках для скриптов. Как я это вижу:
В основном скрипте делаем такой вызов:
Code: Select all
AkelPad.Library("library")
1. Если расширение текущего(основного) скрипта xxx(js vbs) то ищем там скриптовой файл library.xxx и выполняем его(он в свою очередь создает глобальные объекты)
2. Иначе ищем файл library.dll - бинарный платформозависимый модуль, написанный на любом удобном языке. Короче плагин к плагину, который в скрипт добавляет глобальные функции. Ну и к этим функция с основного скрипта можно обращаться. В чем выгоден такой подход? В том, что транслируемыми языками(c/c++,delphi, пр) высокого уровня проще добираться до того или иного API и проще налаживать, чем с помощью oSys.Call() (а в некоторых случаях это вообще не возможно сделать через oSys.Call() - могу привести пример)
-
Offline
- Posts: 3217
- Joined: Wed Nov 29, 2006 1:19 pm
- Location: Киев, Русь
- Contact:
Специальный метод для подключения - здорово! Можно было бы назвать Use или Include (я смотрел, в некоторых редакторах он называется Include).FeyFre wrote:В основном скрипте делаем такой вызов:Code: Select all
AkelPad.Library("library")
Но без пути не гибко; я предлагаю для скриптов завернуть в метод имеющуюся логику:
Code: Select all
eval(AkelPad.ReadFile(AkelPad.GetAkelDir(5) + "\\MyScript.js"));
Code: Select all
AkelPad.Include(AkelPad.GetAkelDir(5) + "\\MyLibrary.dll") //dll, js, vbs и т.п...
Ну и возвращать методом True (нашёл и подключил) или False (не смог).
Желателен ещё необязательный Boolean-параметр "Выводить или не выводить сообщение об ошибке" (по умолчанию "выводить").
Люди за такой метод только скажут спасибо!
-
Offline
- Posts: 876
- Joined: Tue Jul 24, 2007 8:54 am
Один-единственный модуль? А кто его будет поддерживать? И решать, какие функции добавить, а какие нет? Тогда уж делать полноценный LoadLibrary("..."), но тогда вопрос, как указать, что функция должна грузиться из такой-то длл-ки. Надо будет делать что-то вродеищем файл library.dll - бинарный платформозависимый модуль, написанный на любом удобном языке
hLib = LoadLibrary("...");
ImportFunctions(hLib, "Func1; Func2; Func3");
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
Include для DLL - так лучше не делать - многие не поймут, да(или поймут не правильно).
1. Возвращать не буль успешности а объект-namesapce.(null если не судьба).Например
2. Этот же объект-namespace становиться доступен глобально:
3. Алгоритм поиска можно в принципе сделать настраиваим:(? заменяется указаным именем и оттуда пытаются что-то загрузить)
В общем, прототипом этого всего есть модульная система некоторого популярного скриптового языка. К сожалению сам язык как WSH ScriptingEngine не реализован(и никто не желает этого делать, а я сам не справлюсь). Вот я решил выдернуть оттуда хотя бы что-то хорошее и прикрутить в к хорошей программе.
Я высказал упрощенную идею. Детали уже все продуманы(точнее одолжены кое-где), ну например:Ну и возвращать методом True (нашёл и подключил) или False (не смог).
Желателен ещё необязательный Boolean-параметр "Выводить или не выводить сообщение об ошибке" (по умолчанию "выводить").
1. Возвращать не буль успешности а объект-namesapce.(null если не судьба).Например
Code: Select all
var user32 = AkelPad.Library('user32');
user32.CreateWindowEx
Code: Select all
AkelPad.Library('gdi32');
gdi32.CreateWindowEx
Code: Select all
AkelPad.LibPath = "C:\\mydir1\\mydir2\\?.js;C:\\mydir1\\mydir2\\?.vbs;C:\\mydir1\\mydir2\\?.dll"
В общем, прототипом этого всего есть модульная система некоторого популярного скриптового языка. К сожалению сам язык как WSH ScriptingEngine не реализован(и никто не желает этого делать, а я сам не справлюсь). Вот я решил выдернуть оттуда хотя бы что-то хорошее и прикрутить в к хорошей программе.
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
А кто поддерживать будет плагины, если автор окочурится через два дня?Один-единственный модуль? А кто его будет поддерживать?
В последней инстанции - автор. Думаю автор всё-таки выслушает пожелания пользователей. А если нет - ну дык я не предлагаю полное замещение AkelPad.SystemFunction, я предлагаю облегчить жизнь скриптописателям.(Здорово же Вам облегчает жизнь new ActiveXObject("Scripting.FileSystemObject") вместо oSys.Call("kernel32::FindFirstFile"+_TCHAR) )И решать, какие функции добавить, а какие нет?
Ну это решает только часть проблемы. Да и велосипедостроением попахивает(в смысле TypeLib)hLib = LoadLibrary("...");
ImportFunctions(hLib, "Func1; Func2; Func3");
-
Offline
- Posts: 3217
- Joined: Wed Nov 29, 2006 1:19 pm
- Location: Киев, Русь
- Contact:
1,2 идея понравилась, 3-я - нет (не нравится сам факт поиска и перебора путей где-то, если я хочу подключить 1 файл, который лежит по точно известному мне пути).FeyFre wrote:Я высказал упрощенную идею. Детали уже все продуманы(точнее одолжены кое-где)...
Вот я решил выдернуть оттуда хотя бы что-то хорошее и прикрутить в к хорошей программе.
Реально облегчает!FeyFre wrote:...я предлагаю облегчить жизнь скриптописателям.(Здорово же Вам облегчает жизнь new ActiveXObject("Scripting.FileSystemObject") вместо oSys.Call("kernel32::FindFirstFile"+_TCHAR) )
И вообще, писать один и тот же код, который, к тому же, плохочитабелен - это очень НЕхорошая идея.
P.S. В тему: хотелось бы более лёгкого получения инфы от проги, чем этот путь (смотрел скрипт).
-
Offline
- Posts: 876
- Joined: Tue Jul 24, 2007 8:54 am
Ну то есть предполагается это тоже на Инструктора повесить? В таком случае легче в сам плагин функции встраивать.А кто поддерживать будет плагины, если автор окочурится через два дня?
А на мой взгляд, как раз вариант с одной единственной либой попахивает костылём. Тем более что после реализации подгрузки из захардкоденной либы до произвольных либ остается один шаг.Ну это решает только часть проблемы. Да и велосипедостроением попахивает