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


Public Var1 as integer
Public Var2 as string


Функция:


Public Function GetData(a as integer, b as integer) as MyClass
dim TempClass As MyClass
set TempClass = NEw MyClass

TempClass.Var1=a*b
TempClass.Var2=a+b

set GetData=TempClass

End Function

На выходе получаем класс и читаем два значения. Пр желании и 10 и 100 и коллекции и что угодно.
dim NewClass as MyClass

set Myclass=GetData(2,4)



Удачи.




Magnus

2 Eternal

Вообще-то, глобальные переменные это плохая практика. В больших проэктах от них все зло и баги. Равно как и передача параметров byref, только если точно знаете что делаете.


Magnus

Если не возражаете, укажу на пару ошибок:

Во-первых, если функция публичная то UDT не может быть использован как ее результат, генерится ошибка времени компиляции.
Во-вторых, если функция вынесена в модуль, то и тип должен выть глобальным, к примеру в том же модуле, снова получаем #1.
Для реализации, можно обьявить функцию как Friend , но в этом случае ее не смогут использовать внешние обьекты.

И еще одно: параметр "b" в последнем пример передан как Variant. Если тип не указан, он всегда по умолчанию Variant, декларация через запятую не работает.

Ничего личного, просто мне кажется варинт с использованием класса наиболее верным, так как работает для всего проэкта глобально и без огранчений как для типов, тем более что в этом случае для передаваемых параметров можно определить Property Get/Let и в них проверять значения на соответствие.



Magnus

И использование глобальных переменных или классов надо варьировать

Позволю себе не согласится. Представьте себе большой проэкт, порядка 40-50 форм, около сотни классов, пару сотен модулей. Многие классы и модулю имеют схожую функциональность(поддержка форм, к примеру, каждый работает со своим субьектом). Представляете количество переменных в подобном проэкте? Публичных функций, типов и т.д. Естественно что в очень многих случаях нужны глобальные параметры, но для нервного спокойствия кодера, в подобном случае лучше создать отельный публичный класс(GlovalOptions) инициализировать его в начале работы и читать все из него. Преимущества?

Все необходимые параметры в одном месте.
Контроль установки/чтения параметров.
Возможность создать свойтва "только для чтения" - сберегает массу нервных клеток.


Magnus

Ты все верно говоришь , классы это хорошо. Но ты же не будешь их лепить для
решения относительно простых вещей, а будешь использовать глобальные.
Для простых вещей да. Для очень простых :).
ООП - рулит. :)

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



Иногда проще не писать класс , а использовать доброе процедурное и функциональное программирование.
У нас с тобой разные школы :). Я не пишу классы "абы було", если нужен просто набор функций , они прекрасно уживаются в модуле.



Magnus