| View previous topic :: View next topic |
| Author |
Message |
Infocatcher
Joined: 06 Aug 2007
Posts: 1432
|
 Posted: Fri Jan 14, 2011 5:11 pm Post subject: |
 |
|
| Instructor wrote: | | Исправлено: ошибка при закрытии программы с открытым немодальным диалогом (Win7). |
Спасибо!  |
|
| Back to top |
|
 |
Instructor
Site Admin
Joined: 06 Jul 2006
Posts: 4646
|
| Posted: Sat Jan 15, 2011 10:15 am Post subject: |
|
|
Добавлено: дублирующий метод WScript.Arguments.Count для WScript.Arguments.Length.
Added: duplicate method WScript.Arguments.Count for WScript.Arguments.Length.
Scripts plugin v7.8 |
|
| Back to top |
|
|
Instructor
Site Admin
Joined: 06 Jul 2006
Posts: 4646
|
| Posted: Sat Jan 15, 2011 11:26 am Post subject: |
|
|
Исправлено: передача аргумента в VBS скриптах.
Fixed: passing arguments in VBS scripts.
Scripts plugin v7.9 |
|
| Back to top |
|
|
FeyFre
Joined: 07 Aug 2007
Posts: 1892
Location: Vinnitsa, Ukraine
|
| Posted: Sat Jan 15, 2011 11:27 am Post subject: |
|
|
| Quote: | | Добавлено: дублирующий метод WScript.Arguments.Count для WScript.Arguments.Length. |
| Code: | //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);
}; |
Со всем уважением, но Count - метод, а не свойство. Источник |
|
| Back to top |
|
|
Instructor
Site Admin
Joined: 06 Jul 2006
Posts: 4646
|
| Posted: Sat Jan 15, 2011 11:36 am Post subject: |
|
|
FeyFre
Изменил хотя видится, что для VBScript это роли не играет. |
|
| Back to top |
|
|
FeyFre
Joined: 07 Aug 2007
Posts: 1892
Location: Vinnitsa, Ukraine
|
| Posted: Sat Jan 15, 2011 12:50 pm Post subject: |
|
|
Instructor
Зато в JS играет, и в других языках будет играть.
Кстати, о других языках. Скрипты с расширением wsf не желают выполняться. Пишет "сервер сценариев не найден". В свою очередь cscript/wscript выполняют всё как надо. (И расширения wsh это тоже касается). Может стоит модернизировать алгоритм поиска годных для выполнения скриптовых файлов? |
|
| Back to top |
|
|
Instructor
Site Admin
Joined: 06 Jul 2006
Posts: 4646
|
| Posted: Mon Jan 17, 2011 4:36 pm Post subject: |
|
|
| FeyFre wrote: | | Может стоит модернизировать алгоритм поиска годных для выполнения скриптовых файлов? |
Да, убрал. Wsf и wsh файлы являются лишь посредниками для JS и VBS, а их посредничество, насколько я вижу, держится на WScript.exe/CScript.exe. |
|
| Back to top |
|
|
FeyFre
Joined: 07 Aug 2007
Posts: 1892
Location: Vinnitsa, Ukraine
|
| Posted: Mon Jan 17, 2011 5:07 pm Post subject: |
|
|
Instructor
Ну при желании можно и плагином научиться понимать например wsf файлы. Очень было бы неплохо для составления библиотек файлов. Нужно посмотреть сделано ли это ещё где-нибудь(например в wine) |
|
| Back to top |
|
|
FeyFre
Joined: 07 Aug 2007
Posts: 1892
Location: Vinnitsa, Ukraine
|
| Posted: Thu Jan 27, 2011 5:25 pm Post subject: |
|
|
Опять таки фич.реквест к плагину. И как ни странно, касается моего предыдущего поста(Раз уж с wsf и wsh не судьба)
Речь идет о библиотеках скриптов, точнее о библиотеках для скриптов. Как я это вижу:
В основном скрипте делаем такой вызов: | Code: | | AkelPad.Library("library") |
Метод Library(условное название) получает аргументом имя файла-библиотеки, которую нужно загрузить. Искать библиотеку будет в наперед определенном месте(например в AkelFiles\Plugs\Scripts\libraries) по такому алгоритму:
1. Если расширение текущего(основного) скрипта xxx(js vbs) то ищем там скриптовой файл library.xxx и выполняем его(он в свою очередь создает глобальные объекты)
2. Иначе ищем файл library.dll - бинарный платформозависимый модуль, написанный на любом удобном языке. Короче плагин к плагину, который в скрипт добавляет глобальные функции. Ну и к этим функция с основного скрипта можно обращаться. В чем выгоден такой подход? В том, что транслируемыми языками(c/c++,delphi, пр) высокого уровня проще добираться до того или иного API и проще налаживать, чем с помощью oSys.Call() (а в некоторых случаях это вообще не возможно сделать через oSys.Call() - могу привести пример) |
|
| Back to top |
|
|
VladSh
Joined: 29 Nov 2006
Posts: 2510
Location: Киев, Русь
|
| Posted: Fri Jan 28, 2011 7:57 am Post subject: |
|
|
| FeyFre wrote: | В основном скрипте делаем такой вызов: | Code: | | AkelPad.Library("library") |
|
Специальный метод для подключения - здорово! Можно было бы назвать Use или Include (я смотрел, в некоторых редакторах он называется Include).
Но без пути не гибко; я предлагаю для скриптов завернуть в метод имеющуюся логику:
| Code: | | eval(AkelPad.ReadFile(AkelPad.GetAkelDir(5) + "\\MyScript.js")); |
в
| Code: | | AkelPad.Include(AkelPad.GetAkelDir(5) + "\\MyLibrary.dll") //dll, js, vbs и т.п... |
т.о. можно будет передавать и внешние (не AkelFiles) пути.
Ну и возвращать методом True (нашёл и подключил) или False (не смог).
Желателен ещё необязательный Boolean-параметр "Выводить или не выводить сообщение об ошибке" (по умолчанию "выводить").
Люди за такой метод только скажут спасибо! |
|
| Back to top |
|
|
Fr0sT
Joined: 24 Jul 2007
Posts: 850
|
| Posted: Fri Jan 28, 2011 11:42 am Post subject: |
|
|
| Quote: | | ищем файл library.dll - бинарный платформозависимый модуль, написанный на любом удобном языке |
Один-единственный модуль? А кто его будет поддерживать? И решать, какие функции добавить, а какие нет? Тогда уж делать полноценный LoadLibrary("..."), но тогда вопрос, как указать, что функция должна грузиться из такой-то длл-ки. Надо будет делать что-то вроде
hLib = LoadLibrary("...");
ImportFunctions(hLib, "Func1; Func2; Func3"); |
|
| Back to top |
|
|
FeyFre
Joined: 07 Aug 2007
Posts: 1892
Location: Vinnitsa, Ukraine
|
| Posted: Fri Jan 28, 2011 11:49 am Post subject: |
|
|
Include для DLL - так лучше не делать - многие не поймут, да(или поймут не правильно). | Quote: | Ну и возвращать методом True (нашёл и подключил) или False (не смог).
Желателен ещё необязательный Boolean-параметр "Выводить или не выводить сообщение об ошибке" (по умолчанию "выводить"). |
Я высказал упрощенную идею. Детали уже все продуманы(точнее одолжены кое-где), ну например:
1. Возвращать не буль успешности а объект-namesapce.(null если не судьба).Например | Code: | var user32 = AkelPad.Library('user32');
user32.CreateWindowEx |
2. Этот же объект-namespace становиться доступен глобально: | Code: | AkelPad.Library('gdi32');
gdi32.CreateWindowEx |
3. Алгоритм поиска можно в принципе сделать настраиваим: | Code: | | AkelPad.LibPath = "C:\\mydir1\\mydir2\\?.js;C:\\mydir1\\mydir2\\?.vbs;C:\\mydir1\\mydir2\\?.dll" |
(? заменяется указаным именем и оттуда пытаются что-то загрузить)
В общем, прототипом этого всего есть модульная система некоторого популярного скриптового языка. К сожалению сам язык как WSH ScriptingEngine не реализован(и никто не желает этого делать, а я сам не справлюсь). Вот я решил выдернуть оттуда хотя бы что-то хорошее и прикрутить в к хорошей программе. |
|
| Back to top |
|
|
FeyFre
Joined: 07 Aug 2007
Posts: 1892
Location: Vinnitsa, Ukraine
|
| Posted: Fri Jan 28, 2011 1:46 pm Post subject: |
|
|
| Quote: | | Один-единственный модуль? А кто его будет поддерживать? |
А кто поддерживать будет плагины, если автор окочурится через два дня? | Quote: | | И решать, какие функции добавить, а какие нет? |
В последней инстанции - автор. Думаю автор всё-таки выслушает пожелания пользователей. А если нет - ну дык я не предлагаю полное замещение AkelPad.SystemFunction, я предлагаю облегчить жизнь скриптописателям.(Здорово же Вам облегчает жизнь new ActiveXObject("Scripting.FileSystemObject") вместо oSys.Call("kernel32::FindFirstFile"+_TCHAR) ) | Quote: | hLib = LoadLibrary("...");
ImportFunctions(hLib, "Func1; Func2; Func3"); |
Ну это решает только часть проблемы. Да и велосипедостроением попахивает(в смысле TypeLib) |
|
| Back to top |
|
|
VladSh
Joined: 29 Nov 2006
Posts: 2510
Location: Киев, Русь
|
| Posted: Fri Jan 28, 2011 2:24 pm Post subject: |
|
|
| FeyFre wrote: | Я высказал упрощенную идею. Детали уже все продуманы(точнее одолжены кое-где)...
Вот я решил выдернуть оттуда хотя бы что-то хорошее и прикрутить в к хорошей программе. |
1,2 идея понравилась, 3-я - нет (не нравится сам факт поиска и перебора путей где-то, если я хочу подключить 1 файл, который лежит по точно известному мне пути).
| FeyFre wrote: | | ...я предлагаю облегчить жизнь скриптописателям.(Здорово же Вам облегчает жизнь new ActiveXObject("Scripting.FileSystemObject") вместо oSys.Call("kernel32::FindFirstFile"+_TCHAR) ) |
Реально облегчает!
И вообще, писать один и тот же код, который, к тому же, плохочитабелен - это очень НЕхорошая идея.
P.S. В тему: хотелось бы более лёгкого получения инфы от проги, чем этот путь (смотрел скрипт). |
|
| Back to top |
|
|
Fr0sT
Joined: 24 Jul 2007
Posts: 850
|
| Posted: Fri Jan 28, 2011 2:27 pm Post subject: |
|
|
| Quote: | | А кто поддерживать будет плагины, если автор окочурится через два дня? |
Ну то есть предполагается это тоже на Инструктора повесить? В таком случае легче в сам плагин функции встраивать.
| Quote: | | Ну это решает только часть проблемы. Да и велосипедостроением попахивает |
А на мой взгляд, как раз вариант с одной единственной либой попахивает костылём. Тем более что после реализации подгрузки из захардкоденной либы до произвольных либ остается один шаг. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
