Делаю пользовательскую функцию



Но не могу вызвать (например в событии кнопки на форме) ее в формате =filtr_01()
Вылетает ошибка "Введенное выражение содержит функцию с неверным числом аргументов"
Если явно объявить переменные в функции =filtr_01(0, #1/1/2022#) то все работает.
Почему не дает вызывать без явного задания опциональных переменных?

Да, вот еще момент: происходит такое если функция определена в модуле формы (из которой вызывается). Если же перенести функцию в обычный модуль то все нормально вызывается без параметров. Во вложении тестовая база с функцией в модуле формы

Я так и не понял чем это лучше прямого вызова функции из события элемента (кнопки в данном случае). Какие дает преимущества?

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

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

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

Так я так и делаю: при нажатии на кнопку обращаюсь к функции. Функция считывает с формы порядка 15-20 контролов (группы переключателей, флажки, поля), формирует строку фильтра и применяет его к нужной форме. В целом похожий (одинаково использующий бОльшую часть контролов-параметров) но с небольшими различиями (по разному интерпретирующий или вообще игнорирующий несколько оставшихся контролов) фильтр мне нужен в нескольких местах: показать в подчиненной форме актуальные записи, отобранные в определенном разрезе; в этой же подчиненной форме в похожем разрезе показать уже не актуальные, исторические записи на определенную дату; показать актуальные записи но в несколько более широком разрезе в отдельной модальной форме, открываемой по отдельной кнопке. Каждый из этих фильтров формируется и затем применяется разными событиями разных контролов (грубо говоря разными кнопками). Поэтому я и сделал общую функцию, которая в зависимости от переданного параметра dbl (обозначает нужный вариант строки фильтра, значения 0, 1 или 2) и переданной даты istDate (второй параметр) формирует в бОльшей части похожую но различающуюся нюансами строку фильтра. В каждой из кнопок, запускающей тот или иной вариант функции, я на событие "Нажатие кнопки" вешаю вызов функции "=filtr_01(dbl;istDate)" (dbl и istDate прописываю в виде значений разумеется).

Все работает. Но захотелось мне dbl и istDate сделать опциональными параметрами. istDate вообще используется только в одном варианте фильтра из трех возможных, вариант с dbl=0 (основной) используется в вызовах из событий нескольких контролов. Что бы удовлетворить свою хотелку (без которой, разумеется, можно спокойно обойтись) я функцию объявляю так:


Но если функция находится в модуле формы, то она не хочет вызываться из события нажатия кнопки "=filtr_01()", ругается на неверное число аргументов и хочет что бы я обязательно указал что dbl=0 и istDate=#1/1/2022#, т.е. вызывать ее надо обязательно "=filtr_01(0;#1/1/2022#)". Если же саму функцию из модуля формы перенести в обычный модуль, то вызов из события нажатия кнопки "=filtr_01()" работает и внутри функции dbl и istDate принимают прописанные им по умолчанию значения (но при этом мне не очень нравится что функция находится в общем модуле). Вот меня и интересует: почему так?

Да, я, безусловно, знаю (и использую) вариант присваивания нужному событию "Процедура обработки событий" и прописывание нужной обработки в теле соответсвующей Private Sub. Но иногда, как в описываемом случае, несколько кнопок вызывают по сути одну и туже функцию с немного различающимися параметрами. И мне эстетически не нравится плодить в модуле формы кучу Private Sub каждой кнопки, которые внутри себя содержат всего одну и туже строку с вызовом общей функции. Чем плохо прописывать вызов этой функции сразу в нужном событии кнопок, не плодя кучу Private Sub в модуле формы? Я реально не понимаю чем это плохо и был бы рад узнать.

ЗЫ Если в Private Sub нужного события кнопки больше чем одна строка и это наполнение отличается от наполнения других Private Sub других кнопок то в этом случае все понятно, и, собственно, я так и делаю. Но однотипные Private Sub в модуле только ухудшают, на мой взгляд, навигацию по тексту модуля...

Про длинные объяснения согласен.
Во вложении форма с двумя кнопками. Они одинаковым способом вызывают одинаковые функции. Вся разница - одна функция находится в общем модуле а вторая - в модуле формы. Почему одна кнопка работает а вторая вызывает ошибку?

ЗЫ Моя задача решена изначально, способ ее решения (всегда явно указывать аргументы при вызове функции даже если эти аргументы опциональные) очевиден. Мне любопытны нюансы, а именно почему не работает вторая кнопка...

Сорри, не приложил файл...

Да, дата - это аргумент, и он будет меняться. Но он реально используется только в одном варианте вызова функции из трех. И в этом варианте я ее вызову из процедуры, где и присвою этой входящей дате нужное значение. В двух других вариантах вызова функции (при других значениях dbl) дата внутри функции не используется, мне все равно какая она, пусть будет та которая задается по умолчанию (Optional ByVal istDate As Variant = #1/1/2022#)

Хмм... Чем дальше в лес тем толще партизаны... У меня а2016, но не думал что это вообще влиять должно. Ну да ладно, буду иметь в виду что либо вызывать из процедуры обработки события либо, если напрямую, то указывать все аргументы даже если они объявлены опциональными...