Поиск  Пользователи  Правила  Войти
Форумы "Планета Excel" » Курилка
Страницы: 1 2 След.
RSS
Свойства и методы, установленные в VBA по умолчанию
 
#1
07.04.2024 20:29:49
Для некоторых объектов в VBA установлены свойства по умолчанию. Например, для ячейки свойство по умолчанию это значение ячейки. Вместо Cell.Value мы можем записать просто Cell. Для некоторых методов в VBA также существуют принятые умолчания. Например, вместо Application.Volatile True можно записать Application.Volatile. Для операторов существуют умолчания. Так, если в цикле шаг равен 1, то вместо For i=1 To 100  Step 1 записываем For i=1 To 100
Вопрос: какие свойства , методы, конструкции операторов приняты в VBA по умолчанию?
Изменено: Evgenyy - 07.04.2024 20:30:25
 
 
 
#2
07.04.2024 21:04:29
Evgenyy,  ой на кривую дорогу встаете :-).  Если пропуск STEP описан , то всякие неявные опущения, могут потом зло пошутить . Из подобного наверно сразу Variant приходит на ум в определении переменной.
По вопросам из тем форума, личку не читаю.
 
 
 
#3
07.04.2024 21:18:06
Ну что уж прямо так и на кривую? У многих авторов описаны в книгах подобные умолчания.
 
 
 
#4
07.04.2024 21:20:14
Согласен с БМВ, к тому же непонятно для чего их знать или запоминать.
 
 
 
#5
07.04.2024 21:25:04
Знание - сила, незнание - тьма.
 
 
 
#6
07.04.2024 21:33:14
Цитата
Evgenyy написал:
Ну что уж прямо так и на кривую?
на мой взгляд просто снижает читаемость и если это не документированная возможность, то в следующей версии может работать не так, как ожидаешь.
ну значения всяких комбобоксов , текстбоксов тоже вернет по умолчанию.
По вопросам из тем форума, личку не читаю.
 
 
 
#7
07.04.2024 21:42:07
Цитата
БМВ написал:
на мой взгляд просто снижает читаемость
Вопрос не в том хорошо это или плохо? Вопрос в том, что мы знаем об используемых в VBA умолчаниях. А уж применять эти умолчания или не применять, каждый решает сам.
 
 
 
#8
08.04.2024 02:25:25
Цитата
написал:
Вопрос: какие свойства , методы, конструкции операторов приняты в VBA по умолчанию?
На VBA можно добавить в метод(property или функцию) класса специальный атрибут, который делает его умолчательным. Причем атрибут можно добавить в парное свойство (Property Get/Let) и это будет работать практичеки как "Cell.Value" в обе стороны.
Код
Option Explicit

Private Prop1

Public Property Let Metod1(InValue)
    Attribute Item.VB_UserMemId = 0
    Prop1 = InValue
End Property

Public Property Get Metod1()
    Attribute Item.VB_UserMemId = 0
    Metod1 = Prop1
End Property

Но есть один нюанс, чтобы атрибут начал рабоать, после его прописывания нужно класс экспортировать, и вновь импортировать. Есть и более быстрый способ - скопировать класс перетаскиванием в другую открытую книгу, удалить в текущей, и вновь скопировать его из другой книги в текущую с уже "включенными" атрибутами.
Изменено: testuser - 08.04.2024 02:26:30
 
 
 
#9
08.04.2024 10:16:35
Цитата
БМВ: Evgenyy ,  ой на кривую дорогу встаете
полностью согласен. Сократите минимум, а ошибок можете потом собрать — максимум. Это ещё, если повезёт заметить ошибки …
    Если, на раннем этапе программирования я очень любил сокращения, то сейчас даже проверку на длину строки пишу If (Len(a) <> 0) Then вместо If Len(a) Then, как ранее. То же самое с If (InStr () <> 0) Then и If (Err.Number <> 0) Then. Не говоря уже про For Each cl In rng.Cells, rng.Areas(n).Cells(r, c) вместо rng( r ) или rng.Item( r ) и так далее. И да — я обычно заключаю в скобки условие, которое должно вернуть булево (за редкими исключениями) — так становится ещё понятнее и "правильнее".
    В общем, ваши мысли в коде должны быть прозрачны и однозначны, по возможности, а всякие сокращения просто вносят хаос на ровном месте, не давая ничего взамен.

    Несколько раз сокращения уже подводили меня. Уже не припомню, какие и в чём …
Теперь доверяю из значений по умолчанию — только значениям переменных. Но и с ними есть нюансы — например объекты, массивы и опциональные параметры.
Изменено: Jack Famous - 08.04.2024 10:23:51
Во всех делах очень полезно периодически ставить знак вопроса к тому, что вы с давних пор считали не требующим доказательств (Бертран Рассел) ►Благодарности сюда◄
 
 
 
#10
08.04.2024 17:29:34
Выскажусь в пользу сокращений. Имхо, сама концепция-то сокращений правильная, как способ освобождения кода от всяческой избыточности и улучшения читабельности и т.д. Однако в объектной модели или может быть даже в автоматике самого языка не все так гладко устроено, в рез. чего приходится отказываться от некоторых приемов. В добавок если еще добавить случаи мертвых библиотечных ссылок в референсах, там вообще всякая чихорда начинает твориться, но, полагаю, их веротность нельзя принимать за норму. И вот, допустим, если представить код с обильным использованием коллекций или словарей и указанием в каждом случае метода item, наверное это будет грязно. Вот я, в частности, когда только осваивал словари, когда узнал о кратком обращение (без .item) прям удивился, насколько код станоится приятней и читабельней. В этом наверное и есть одна из лучших частей ООП.
 
 
 
#11
08.04.2024 18:33:00
Цитата
testuser: указанием в каждом случае метода item, наверное это будет грязно
я в словарях тоже .Item не использую. Но это не те сокращения, о которых речь. Range().(1) — это нормальное сокращение от Range().Item(1), однако сейчас для меня прямое указание Range().Areas(1).Cells(1,1) более предпочтительно.
    У словарей всё проще — получить значение по ключу можно только через v=dic(Key) или v = dic.Item(Key) и тут уже грех не сократить, т.к. других методов просто нет при той же записи.

    Ещё простой пример с диапазоном (как объекте с наибольшим, пожалуй, количеством методов): Dim x: x = Range() (массив или значение) и Set x = Range() (строго диапазон). Легко ошибиться.
А вот так: Set x = Range().Value уже получим ошибку, что гораздо лучше, чем получить диапазон вместо массива или наоборот.
Во всех делах очень полезно периодически ставить знак вопроса к тому, что вы с давних пор считали не требующим доказательств (Бертран Рассел) ►Благодарности сюда◄
 
 
 
#12
08.04.2024 20:16:34
Я бы разделил мир VBA и миры Excel, Word, ...
Сам по себе VBA достаточно компактный язык и описан в этом  разделе.
Изменено: sokol92 - 08.04.2024 20:17:58
Владимир
 
 
 
#13
09.04.2024 14:42:12
Кстати, небольшая задача по данной теме.
Как в "полном" виде выглядит оператор:
Код
Range("A1") = 1

Мой вариант ответа:
Скрытый текст
Владимир
 
 
 
#14
09.04.2024 15:12:03
Цитата
sokol92: Как в "полном" виде выглядит оператор:
мне .Value2 было бы достаточно  :)
Изменено: Jack Famous - 09.04.2024 15:12:20
Во всех делах очень полезно периодически ставить знак вопроса к тому, что вы с давних пор считали не требующим доказательств (Бертран Рассел) ►Благодарности сюда◄
 
 
 
#15
09.04.2024 16:29:11
Цитата
sokol92 написал:
Скрытый текст
Добрый день, Владимир!
Туда еще можно .ActiveWorkbook.ActiveSheet. втиснуть  :)
 
 
 
#16
09.04.2024 16:37:26
Здравствуйте, Владимир!
Не знал, как с этим быть. Вродe, Excel.Application, Value(...) - обязательная программа, а  .ActiveWorkbook.ActiveSheet. под капотом (?)   :)

Update. Можно еще так проверять выводы (VBS):

Код
Call Run_macro
Sub Run_macro()
   set objExcel = CreateObject ("Excel.Application")
   objExcel.Visible = True    
   objExcel.Workbooks.Add
   objExcel.Range("A1")=1
End sub


Кстати, в LibreOffice много языков программирования (Basic, Python, Java, ...) и границы между языком программирования и объектной моделью Calc (аналог Excel) отчетливо видны и документированы.
Изменено: sokol92 - 09.04.2024 16:49:17
Владимир
 
 
 
#17
09.04.2024 18:31:37
Цитата
sokol92: Кстати, в LibreOffice много языков программирования (Basic, Python, Java, ...)
я, собственно, только его вижу в качестве возможного аналога для перехода
Во всех делах очень полезно периодически ставить знак вопроса к тому, что вы с давних пор считали не требующим доказательств (Бертран Рассел) ►Благодарности сюда◄
 
 
 
#18
09.04.2024 20:53:55
Цитата
sokol92 написал:
Excel.Application.Range("A1").Value(xlRangeValueDefault) = 1
Зачем городить огороды? Прислушайтесь к Чехову, а не к БМВ. Как говорил Чехов: "Краткость - сестра таланта". Предпочитаю короткий, лаконичный, работоспособный код, поэтому и спрашиваю как и что можно записать коротко, без лишних букв и цифр.
 
 
 
#19
09.04.2024 20:58:10
Цитата
Evgenyy написал:
Прислушайтесь к Чехову, а не к БМВ
Не уверен, что Антон Павлович знал Excel  на том же уровне, что Михаил.

Цитата
Evgenyy написал:
"Краткость - сестра таланта".
... но мачеха гонорара (что иногда относится и к программистам).  :)
Владимир
 
 
 
#20
09.04.2024 21:06:37
Цитата
sokol92 написал:
но мачеха гонорара
но это не у Чехова
 
 
 
#21
10.04.2024 07:33:07
Так если подумать, возможных сокращений не так и много, кроме упоянутых If, For.. Но если взглянуть на вопрос немного иначе, точнее это будет уже другой вопрос, например - как работает невидимая автоматика языка - то таком ракурсе можно было бы выделить не мало нюансов. Вот, допустим, такая конструкция в vb* работает не очень правильно
Код
If условие1 OR условие2 Then

При выполении данной строчки кода будет проверено услвие1 и условие2 даже если условие1 верное, хотя фактически было бы достаточно выполнения условия1 чтобы войти в блок. И в таком случае технически более правильно будет работать Select Case, хотя это будет длинее и менее читаемо..
Код
Select Case True
Case условие1, условие2
***
End Select
Изменено: testuser - 10.04.2024 07:35:57
 
 
 
#22
10.04.2024 12:31:03
Цитата
testuser написал:
невидимая автоматика языка
ну приведенный пример вполне понятен, ибо if обрабатывает логическое выражение а оно  записано "условие1 OR условие2"  так как выражения могут быть разные , включая NOT(условие1 OR условие2)  и более сложные , то разбирать и оптимизировать фантазию прогера компилятор не должен.
По вопросам из тем форума, личку не читаю.
 
 
 
#23
10.04.2024 13:01:11
БМВ, в JS, например, не так работает, проверял
 
 
 
#24
10.04.2024 13:03:07
да везде работает "оптимально", не только в JS  ))

Цитата
БМВ написал:
компилятор не должен

и всё-таки не "компилятор", а интерпретатор
Изменено: nilske - 10.04.2024 13:09:51
 
 
 
#25
10.04.2024 13:15:06
Касаемо затронутой темы, можно еще привести пример (без примера, на словах )). Допустим константы, по логике программы лучше их использовть там где они уместны. Но в VB есть небольшой нюанс.. Когда константа передается в другую процедуру, она перестает быть константой. Если быть точнее она копируется в другую переменную, которая уже может быть изменена внутри вызываемой процедуры. Если сравнить, передачу обычной переменной по ссылке с передачей константы, то во втором случае добавляются дополнительные издержки на копирование. В случае со длинными строками это должно быть особенно заметно..
Изменено: testuser - 10.04.2024 13:19:36
 
 
 
#26
10.04.2024 14:06:10
Цитата
testuser написал:
такая конструкция в vb* работает не очень правильно
VBA не одинок в этой компании. См. статью о коротком замыкании.

Кстати, такая формула
Код
=ЕСЛИ(ИЛИ(1=1; MyFunc());1;0)

вызывает функцию MyFunc.
Изменено: sokol92 - 10.04.2024 14:12:20
Владимир
 
 
 
#27
10.04.2024 14:54:16
Цитата
sokol92 написал:
вызывает функцию MyFunc.
Видимо так работает калькуляция..
А нет, так не срабатывает, т.е. калькуляция может избирательно работать
Код
=ЕСЛИ(ИЛИ(C10;0);1;MyFunc())
Изменено: testuser - 10.04.2024 15:05:39
 
 
 
#28
10.04.2024 15:15:52
Цитата
nilske написал:
да везде работает "оптимально", не только в JS  ))
Ну там другие зато погремушки, там царство дикой автоматики безальтернативной динамической типизации.
 
 
 
#29
10.04.2024 16:03:48
Цитата
БМВ: так как выражения могут быть разные , включая NOT(условие1 OR условие2)  и более сложные , то разбирать и оптимизировать фантазию прогера компилятор не должен.
при ВЫПОЛНЕНИИ 1го условия, уже неважно, что после OR, потому что оно 1е выполнено. Не думаю, что это невозможно описать алгоритмом.
    Функция Iif() тоже вычисляет ОБА исхода и хрен пойми, зачем она это делает …
Во всех делах очень полезно периодически ставить знак вопроса к тому, что вы с давних пор считали не требующим доказательств (Бертран Рассел) ►Благодарности сюда◄
 
 
 
#30
10.04.2024 16:31:09
Цитата
Jack Famous написал:
Не думаю, что это невозможно описать алгоритмом.
повторю мысль. Логическое выражение может быть достаточно сложным и если прогер не озадачился его упрощением согласно булевой алгебре, то алгоритм принятия решения что нужно и что нет считать может быть более трудоемким чем тупо просчитать все условия. например (TRUE OR TRUE OR TRUE) AND FALSE .
Изменено: БМВ - 10.04.2024 16:32:37
По вопросам из тем форума, личку не читаю.
 
 
 
Страницы: 1 2 След.
Наверх