Продолжение VBA (Warning! Ламеризм!)

[konev]

Регулярно пользуюсь VBA (конкретно, для Excel), профессиональным программером не являюсь.. Но вот что-то мне подсказывает, что возможности, которые предлагаются в VBA по умолчанию, существенно беднее тех, которыми обладает, например, просто VB (как среда разработки, я имею ввиду). Т.е. набор например, control'ов в обычном VB должен бы быть существенно больше. Кроме того, наверное, в последнем существует множество встроенных функций, а так же специальных классов для всего, что только возможно..

В частности, вот такой пример – встретил где-то в форуме конструкцию:

Необязательно читать файл ручками.
Грузишь его в пикчербокс, .Point - узнаёшь цвет нужного пикселя, .Pset - рисуешь точку нужного цвета.
Потом сохраняешь SavePicture

*Не забыть Picture1.Autoredraw = True и Savepicture "", Picture1.Image (а не Pic-ture1.Picture)

Мне эти английские слова ни о чем не говорят, хелп мой на них не реагирует (хотя по сути все ясно).

Вопросы. 1) Ну, во-первых, насколько верно то, что я написал в первом абзаце?
2) Понятно, что библиотек существуют тысячи, но вот есть ли какой-то канонический список стандартных библиотек, который отсутствует в VBA и который нужно просто туда засандалить и получить полноценную среду разработки (ну или хотя бы приблизиться к этому)? Если да, то где такой список взять (вместе с самим библиотеками и спецификацией).
3) Какие, вкратце, принципиальные вещи есть в VB, которые невозможно реализовать в VBA?

[alibek]

1. Скорее неверно, чем верно. Да, в VBA нельзя разрабатывать свои компоненты, но у него другое предназначение -- не разработка приложений, а расширение функциональности конкретного приложения.
2. Особой разницы нет. ActiveX-библиотеки будут работать совершенно одинаково и в VB, и в VBA. С Native-библиотеками иногда бывают сложности, но в целом особых отличий нет.
3. А это разве не очевидно? В VB ты создаешь автономное приложение. VBA -- это расширение какого-либо проекта в основном родительском приложении.

[konev]

1. Скорее неверно, чем верно. Да, в VBA нельзя разрабатывать свои компоненты, но у него другое предназначение -- не разработка приложений, а расширение функциональности конкретного приложения.

Конкретизирую этот вопрос. Верно ли, что в VBA (по умолчанию) гораздо беднее набор контролов и встроенных функций?

2. Особой разницы нет. ActiveX-библиотеки будут работать совершенно одинаково и в VB, и в VBA. С Native-библиотеками иногда бывают сложности, но в целом особых отличий нет.

Второй был про другое, он очень практический. Если первое (в данной редакции) верно, то где взять список библиотек (и сами библиотеки), чтобы подгрузить его в VBA, и получить тот набор финтифлюшек, который доступен по умолчанию в VB. Например, чтобы я мог воспользоваться словами Point, Pset, SavePicture, Autoredraw

3. А это разве не очевидно? В VB ты создаешь автономное приложение. VBA -- это расширение какого-либо проекта в основном родительском приложении.

Это конечно. Но в общем-то на VBA можно много чего написать, не имющего отношения к приложению. Уже любая форма не является непосредственно расширением приложения, а самостоятельно живущий объект (хотя обычно ее привязывают к приложению в VBA).

Иначе говоря, все, что может сделать, например, пятиклассник на VB, можно сделать и на VBA (ну только Excel придется оставить работать). Вопрос тут в том, чего принципиально нельзя сделать на VBA.

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

Да, из всех вопросов самый важный 2-й (про конкретные библиотеки).

[GSerg]

konev, фигнёй страдать неполезно (а весь вопрос есть страдание фигнёй и ничто иное).
Просто начни писать на VBA и всё. И тогда поймёшь, что тебе надо и что нет.

[konev]

konev, фигнёй страдать неполезно (а весь вопрос есть страдание фигнёй и ничто иное).
Просто начни писать на VBA и всё. И тогда поймёшь, что тебе надо и что нет.

Извини, не увидел ответа на свои вопросы в твоем посте.

[tyomitch]

VB -- это VBA + DAO + библиотека форм + компилятор.
Вот, вроде, и всё.

Все встроенные средства VB, кроме работы с данными и с формами, в VBA есть. В т.ч. SavePicture.

Отодрать библиотеку форм от VB, и подключить к VBA, нельзя. Но можно разыскать (или написать) что-нибудь подобное, если есть слишком много лишнего времени.

Из-за того, что VBA не компилируется, на нём нельзя сделать такие изощрённые вещи, как глобальный хук. Но для нормальных задач его должно хватать.

[alibek]

tyomitch, ты что-то путаешь
SavePicture (а также LoadRes*, Clipboard.*, *.Scale*, Licenses.*, Printer.*) в VBA отсутствуют. Да и DAO в VB не включается вроде бы.

[tyomitch]

alibek, кинь на форму Data -- подключится.


Кроме того:

Sub SavePicture(Picture As IPictureDisp, filename As String)
Member of stdole.StdFunctions
Saves a picture to a file

[alibek]

А удали DAO из референсов и работать перестанет
Скорее всего подключение это чисто интерфейсное.

А вот stdole я недоглядел, каюсь

[konev]

VB -- это VBA + DAO + библиотека форм + компилятор. Вот, вроде, и всё.

Все встроенные средства VB, кроме работы с данными и с формами, в VBA есть. В т.ч. SavePicture.

Отодрать библиотеку форм от VB, и подключить к VBA, нельзя. Но можно разыскать (или написать) что-нибудь подобное, если есть слишком много лишнего времени.

Из-за того, что VBA не компилируется, на нём нельзя сделать такие изощрённые вещи, как глобальный хук. Но для нормальных задач его должно хватать.

Спасибо, это именно то, о чем я спрашивал.

- - -

SavePicture действительно есть, но нет point, pset и picturebox, которыми я как раз хотел воспользоваться так, как об этом написано в цитате из первого поста . Что тут можно сделать средствами VBA?

И еще вопрос насчет этой библиотеки stdole. Можно ли где-то прочитать полное описание ее содержимого? В MSDN посмотрел, но там только обрывочные какие-то сведения. (Хотя первый раз пользовался MSDN, может что-то не понял).

[tyomitch]

А удали DAO из референсов и работать перестанет
Скорее всего подключение это чисто интерфейсное.

Ну как, датабиндинг контролов и все дела... В VBA ты этого подключением DAO не добьёшься. (Ведь не добьёшься?)

SavePicture действительно есть, но нет point, pset и picturebox, которыми я как раз хотел воспользоваться так, как об этом написано в цитате из первого поста . Что тут можно сделать средствами VBA?

Парсить BMP руками: формат в том топике был дан.

И еще вопрос насчет этой библиотеки stdole. Можно ли где-то прочитать полное описание ее содержимого? В MSDN посмотрел, но там только обрывочные какие-то сведения. (Хотя первый раз пользовался MSDN, может что-то не понял).

Полнее негде.

[konev]

Отодрать библиотеку форм от VB, и подключить к VBA, нельзя.

Мучает вопрос - а почему собсно нельзя? Можно ли сформулировать некую глубинную причину, ведь среды вроде как одинаковые? Или просто так сложилось по прихоти разрабов?

- - -

И еще я там задавал вопрос за номером 2, пока на него не ответили толком. Есть ли некий список библиотек, который не установлен по умолчанию в VBA, но про который всем, кто активно пользует VBA, известно, что вот эти библиотеки - они реально весьма полезные и часто бывают нужны?

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

[alibek]

Нельзя потому что нельзя. By design.
А второй вопрос бессмысленный. Естественно, в разных проектах устанавливаются и используются разные библиотеки.

[konev]

Не понимаю я, что такого бессмысленного в вопросе. Приведу пример.
Вот был такой мега язык - TurboPascal 6.0. Мощнейший был язык,
таких дел можно было наворотить, зная один только условный оператор..

У него была например библиотека (модуль, по-тогдашнему) CRT. Без этой библиотеки очень много чего сделать было сложно (хотя никто не говорит, что невозможно - asm и hex никто не отменял). И человеку, который собрался что-то писать на TP 6.0, весьма полезно было заранее ознакомится с этой библиотекой, а также с оператором uses crt;

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

[tyomitch]

konev, наш препод по Паскалю нам на одном из первых занятий запретил пользоваться модулем CRT. Именно потому, что на нём можно наворотить слишком много ерунды. И мы весь год писали без него, причём писали вполне рабочие программы.

Зачем он, вообще, нужен? для графики -- не нужен совсем, для текстовых мегакрутых интерфейсов -- есть TurboVision и т.п.

При чём тут упомянут hex, не понял совершенно.


А если хочется ознакомиться с тонной безусловно полезных функций, 99% которых никогда в жизни не понадобятся, -- просто читай MSDN подряд

[konev]

Либо ничего, либо MSDN подряд. Других вариантов конечно нет.

Ладно, видать со времен моей юности подходы к изучению средств разработки сильно поменялись. Ну хоть сайтецы, где лежит много разных библиотек с хорошими описаниями можете подсказать?

Кстати, как без CRT реализовать clrscr? Помнится, весьма удобная была функция.

[tyomitch]

Либо ничего, либо MSDN подряд. Других вариантов конечно нет.

Ладно, видать со времен моей юности подходы к изучению средств разработки сильно поменялись. Ну хоть сайтецы, где лежит много разных библиотек с хорошими описаниями можете подсказать?

Все библиотеки -- они для чего-то. Библиотек "для просто так" нет. И не было.

Кстати, как без CRT реализовать clrscr? Помнится, весьма удобная была функция.

1) зачем она нужна? в смысле, реально зачем?
2) чисто формально, можно вывести 25 пустых строк -- эффект тот же.