VisualBasic + WinAPI

[kiber_punk]

Посоветуйте литературу/статьи/ресурсы(ссылки) по использованию WinAPI в VB.

[Хакер]

В таким случаев принято давать ссылки на Дэниела Эпплмана, но я не признаю его книжку, в ней много ошибок.

Использования WinAPI в VB мало чем отличается от использования WinAPI в других языках. Нужно читать первоисточник — документацию по API из MSDN.

Все особенности использования WinAPI в VB не специфичны для самих API а проистекают из особенностей VB. Соответственно, и читать нужно о секретах, хитростях и тонкостях устройства VB.

[kiber_punk]

Не мог бы привести общий пример импорта библиотек и вызова функций?

[Хакер]

Обычный импорт: нужная функция объявляется в TLB, TLB подключается к проекту. Вызывается как обычная функция.
Отложенный импорт: нужная функция объявляется с помощью Declare Sub/Function, почти так же, как обычная. Вызывается как обычная функция.

[Денис]

Обычный импорт: Отложенный импорт:

kiber_punk
Причем все это относится к раннему связыванию. Если программа не найдет библиотеку с функцией, то программа не запустится совсем.
Есть же еще такая вещь как позднее связывание. Что очень удобно при, например, написании плагинов. Программа запускается, в ней загружается библиотека, и если программа библиотеку не найдет, то программист сможет обработать ошибку и выдать соответствующее предупреждение пользователю.
Кроме того, в VB6 в основном используются ActiveX DLL, которые подключаются через пункт меню. В этих библиотеках передаются целые классы, что задумывалось как штука несомненно удобная. Но многим не нравится.

[arthur2]

Если программа не найдет библиотеку с функцией, то программа не запустится совсем.

А ошибку отлавливать не пробовал?

[Хакер]

А ошибку отлавливать не пробовал?

Прямо в ядре системы

P.S. Впрочем, Денис тоже испортил свой пост с тех пор, как я прочитал его впервые.

[arthur2]

При обычном импорте через тлб - да, не запустится, при Declare - ошибка ловится без каких-либо ухищрений. Даже можно поискать ненайденную библиотеку.

[BV]

Обычный импорт: нужная функция объявляется в TLB, TLB подключается к проекту

Я уже говорил это Артуру, повторю и тебе: а с каких пор TLB и IDL стали частью VB? Это отдельная технология и отдельный язык, не имеющие ничего, кроме COM, общего с VB. И упоминать TLB в качестве решения раннего связывания допустимо только как хак

[Хакер]

Я уже говорил это Артуру, повторю и тебе: а с каких пор TLB и IDL стали частью VB?

Я уже слышал эту глупость. С тем же успехом можно сказать, что и WinAPI не являются частью VB, а значит это хак.

[arthur2]

BV С каких пор то, что подключается штатным способом - является хаком? Тогда уж и подключение ActiveX (которые - о ужас! - тоже могут быть написанны на других языках) - это тоже хаки

Возможно, я тебя удивлю, но при подключении референцев в диалоге открытия файлов в поле "Тип файлов" числится ПО УМОЛЧАНИЮ : "Type Librearies (*.olb;*.tlb;*.dll)"

[Денис]

При обычном импорте через тлб - да, не запустится, при Declare - ошибка ловится без каких-либо ухищрений. Даже можно поискать ненайденную библиотеку.

Код в студию!
Но даже если и можно отловить ошибку, все равно обработка ошибки будет при запуске приложения?

[Хакер]

Код в студию!

Вполне сам можешь вызов функции обрамить On-Error-ами.

[arthur2]

Код в студию!

on error goto errH:
Не?

Но даже если и можно отловить ошибку, все равно обработка ошибки будет при запуске приложения?

Ошибка будет происходить при первом вызове задекларированной функции. При обработке ошибки нужно сменить текущую директорию и снова вызвать функцию - если библа будет там, то функция сработает.

Хакер, кстати, предлагал ещё какой-то способ - можно поискать по форуму.

[Денис]

При обработке ошибки нужно сменить текущую директорию и снова вызвать функцию - если библа будет там, то функция сработает.

К сожалению, у меня нет бейсика под рукой, чтоб проверить. Но в любом случае, после ключевого слова Lib требуется обязательно указать строку-константу. Из-за этого описаные тобой костыли. А если у программы несколько плагинов в разных папках, так и скакать по ним? Глупо.

[arthur2]

после ключевого слова Lib требуется обязательно указать строку-константу

в которой допустимы относительные пути

И кстати по-моему (поправьте, если это не так), после первого вызова функции искать библу больше уже не нужно.

[Денис]

после ключевого слова Lib требуется обязательно указать строку-константу

в которой допустимы относительные пути

При чем тут относительные пути? Если я говорю о том, что при позднем связывании юзер может добавить в файл ini любые дополнительные библиотеки лежащие возможно по разным путям.

[arthur2]

лежащие возможно по разным путям.

То есть, вообще где попало? что-то не очень представляю себе такую организацию плагинов. Плагины должны лежать в одной папке. Или - в разных подпапках одной папки.

[Денис]

То есть, вообще где попало?

К сожалению, ни программистам, ни их программам, юзеры ничего не должны. Эт я тебе как админ говорю.
Допустим, у нас в рабочей папке есть папка "Plugins"
Если в ней все плагины свалены в одну кучу, то доступ (при раннем связывании) мы получим примерно так:

Код: Выделить всё

Declare Sub mfunc Lib "Plugins\lib1.dll" ()

Но если плагины организованы в подпапки, каждый со своим описанием, вспомогательными папками итд. То тогда как?

[arthur2]

К сожалению, ни программистам, ни их программам, юзеры ничего не должны.

Поиск плагинов где попало можно осуществить хоть c Declare, хоть с CreateObject - не вижу принципиальной разницы. Другое дело, что ни в том ни в другом случае я бы не стал обеспечивать программу такой возможность, потому что

Плагины должны лежать в одной папке.

А юзер, конечно, ничего не должен - это программа должна перенести их в специально для плагинов предназначенную папочку. Или - ещё правильнее - инсталлятор.

[Денис]

не вижу принципиальной разницы.

Да ну как же так?
Код давай. Я не верю.

[arthur2]

Если в ней все плагины свалены в одну кучу, то доступ (при раннем связывании) мы получим примерно так:

Код: Выделить всё

Declare Sub mfunc Lib "Plugins\lib1.dll" ()

Но если плагины организованы в подпапки, каждый со своим описанием, вспомогательными папками итд. То тогда как?

Вероятно, так:

Код: Выделить всё

Declare Sub mfunc Lib "Plugins\plug1\lib1.dll" ()

[arthur2]

не вижу принципиальной разницы.

И кстати по-моему (поправьте, если это не так), после первого вызова функции искать библу больше уже не нужно.

Код давай. Я не верю.

Если моё предположение не верно - то да, вижу разницу. Но если верно - не вижу смысла выкладывать очевидный код.

[Хакер]

Денис, с помощью Declare, пусть и не самым красивым путём, можно загрузить любую DLL, важно только придерживаться правила «каждому плагину — своё папка, каждому плагину — одинаковое имя DLL».

[Денис]

программа должна перенести их в специально для плагинов предназначенную папочку. Или - ещё правильнее - инсталлятор.

Правильно, а в ней папочки: Plug1, Plug2, Plug3. Хорошо, допустим наш инсталлятор установил прогу с тремя предустановленными нами же плагинами. При этом он нам еще и перекомпилировал программу так, что статически привязал ее к этим трем папкам.
И что дальше? Юзер решил установить сторонний плагин. И что ему делать?

И кстати по-моему (поправьте, если это не так), после первого вызова функции искать библу больше уже не нужно.

А вот тут я не вижу разницы. В случае с ранним (статическим) связыванием мы все равно на каждый устанавливаемый плагин будем вынуждены объявить пачку Declare. В случае с поздним (динамическим) связыванием, мы просто будем по мере необходимости подсовывать в вызов LoadLibrary нужный путь из конфигурационного файла (или даже в CreateObject, если мы пишем ActiveX плагин).

Если моё предположение не верно - то да, вижу разницу. Но если верно - не вижу смысла выкладывать очевидный код.

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

Денис, с помощью Declare, пусть и не самым красивым путём, можно загрузить любую DLL, важно только придерживаться правила «каждому плагину — своё папка, каждому плагину — одинаковое имя DLL

Я только что описал этот самый путь. Надеюсь, более менее правильно. Он имеет смысл для open-source-проектов, которые могут перекомпилировать себя самостоятельно, как тот же Lazarus.
В VB с помощью Declare писать плагины это - извращение.

[Хакер]

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

Хватит нести чушь.

[Денис]

Ну ладно. Хватит, так хватит.

[arthur2]

Не, ну при чем здесь перекомпиляция? Под очевидным кодом я имел ввиду код смены текущей директории.

[Денис]

Не, ну при чем здесь перекомпиляция? Под очевидным кодом я имел ввиду код смены текущей директории.

В таком случае, если твое предположение верно, и однажы вызванная по одному пути библиотека будет вызываться все время из одного и того же расположения, то тогда, меняя путь, мы можем выполнять одинаковые функции из разных библиотек. Но как это проверить, если под рукой нет бейсика (у меня).

[Хакер]

Но как это проверить, если под рукой нет бейсика (у меня).

Не надо это проверять. 1000 раз это уже проверили, о чём тебе здесь и твердили.

Правда вызвать получится только один раз, потом хоть заменяйся текущую директорию.