Комментарии 13
Моя программерская карьера 14 лет назад началась с того, что я два года не вылезал из экселя и VBA… Аж всплакнул от ностальгии.
Запомню на всякий случай, вдруг случится необходимость опять с VBA столкнуться.
Запомню на всякий случай, вдруг случится необходимость опять с VBA столкнуться.
VBA это конечно «шедевр». Положу в закладки рядом с проверкой массива Dim a() As String на на nil.
Но всё таки может лучше сразу написать интерпретатор нормального языка на VBA и писать на нём.
If (Not a) <> (Not 0) Then
ub=UBound(a)
End if
Но всё таки может лучше сразу написать интерпретатор нормального языка на VBA и писать на нём.
Что за трешовый код? Проверку на инициализацию надо делать так
Public Function IsArrayInitialized(arr) As Boolean
On Error Resume Next
Dim rv As Long: rv = UBound(arr)
IsArrayInitialized = (Err.Number = 0)
End Function
Незнаю что более трешовое on error resume next или (not a)<>-1
За то я знаю. Ваш код ужасен. Если так нужно использовать проверку на инициализацию массива включайте в свои проекты функцию IsArrayInitialized(). Примеров ее реализации различными путями множество. И кстати да, как уже было сказано никакого nil — в VBA нет.
Класс!!! +100
Почему работа с API вам кажется лучше, чем работа с исключениями?
Я уже не совсем точно помню деталей работы исключений. Но постараюсь объяснить на пальцах.
Возбуждение исключений инициирует кучу ненужных вызовов (попытку вызова обработчика и т.п.), что ведёт в том числе к замедлению работы программы.
Эти исключения затем попадают в список, когда исследуешь причины падения, отлаживаешь программу через ProcDump и др., в итоге видишь винегрет, где придётся разбираться, какое из исключений критическое, а какое нет. При массовом использовании такой функции получаешь просто нереальное число мусора в отладке.
В более сложных сценариях, без нормальной проверки указателей на объекты, используя именно такой способ (понадеясь на мощь On Error Resume Next) можно нарваться на краш.
P.S. Ну и я бы не назвал это работой с API. Просто разбор полей родной VBA-шной структуры.
Возбуждение исключений инициирует кучу ненужных вызовов (попытку вызова обработчика и т.п.), что ведёт в том числе к замедлению работы программы.
Эти исключения затем попадают в список, когда исследуешь причины падения, отлаживаешь программу через ProcDump и др., в итоге видишь винегрет, где придётся разбираться, какое из исключений критическое, а какое нет. При массовом использовании такой функции получаешь просто нереальное число мусора в отладке.
В более сложных сценариях, без нормальной проверки указателей на объекты, используя именно такой способ (понадеясь на мощь On Error Resume Next) можно нарваться на краш.
P.S. Ну и я бы не назвал это работой с API. Просто разбор полей родной VBA-шной структуры.
Кстати, никакого nil в VBA нет.
«Вот так, с помощью нехитрых приспособлений буханку белого (или черного) хлеба можно превратить в троллейбус… Но зачем?»
Не спорю, получилось красиво, хотя я вначале был заинтригован и ожидал в основе что-то элегантней обычного eval. В целом, надеюсь, что хайп вокруг ФП скоро уляжется в конкретной ограниченной области его применения.
Не спорю, получилось красиво, хотя я вначале был заинтригован и ожидал в основе что-то элегантней обычного eval. В целом, надеюсь, что хайп вокруг ФП скоро уляжется в конкретной ограниченной области его применения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Функциональные интерфейсы… в VBA