Цель использования подпрограмм над функциями

Я работаю с Access на некоторое время сейчас, и хотя я понимаю очевидное преимущество функции над Sub, было то, что она может возвращать значения в результате, я не уверен, почему я должен использовать Sub над функцией. В конце концов, если я не ошибаюсь; Функции могут делать все, что может сделать Subs?

Примечание. Я полностью знаю, как использовать Sub и Function, чтобы не искать объяснения того, как они работают.

Ответ 1

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

Ответ 2

Что касается производительности, здесь это не будет проблемой.

Основное отличие состоит в том, что определяемая пользователем функция может использоваться в выражении в вашем коде, где не может быть sub.

Это действительно ОГРОМНАЯ Эверест на разнице здесь.

Это различие действительно не ограничено Access, но имеет тенденцию применяться к каждому языку программирования и системе, о которых я могу думать, что поддерживает создание пользовательских функций.

Ключевым преимуществом использования определенной функции является МНОГО, но самая основная проблема заключается в том, что такую ​​функцию можно использовать в EXPRESSIONS.

Например, при нажатии кнопки на кнопке в форме вы можете, как правило, использовать одну процедуру VBA [Event Code], прикрепленную к этой кнопке.

Однако вы также можете разместить выражение в листе свойств следующим образом:

=MyUserFunction()

Вышеприведенный совет, так как тогда вы можете выделить 10 элементов управления в форме и ввести выражение выше, и вы просто назначили указанную выше функцию этим 10 кнопкам. Вы не можете сделать это с помощью юнита.

Еще одно существенное различие заключается в том, что вы можете использовать функцию в качестве источника данных (выражение) для текстового поля формы или отчета (опять же вы не можете сделать это с помощью sub).

Еще одно существенное отличие заключается в том, что вы можете использовать эти функции в SQL. Это поистине фантастическая способность, так как тогда у вас может быть код "run" для каждой строки запроса. И это означает, что вы можете расширить возможности и функционально SQL.

И вы даже можете использовать эту идею для отображения переменной VBA в sql-запросе, поскольку вы просто создаете публичную функцию, которая возвращает переменную VBA, и это может быть использовано в запросе - вы не можете использовать переменные VBA в запросе!

И это расширение SQL открывает бесконечные идеи:

Поэтому я могу создать публичную функцию под названием ToMorrow()

Public Function Tomorrow() as date

   Tomorrow() = date() + 1

End Function.

Теперь в построителе запросов я могу:

Select FirstName, lastName, Tomorrow() as NextDay from tblCustomers

И вы даже можете создавать пользовательские преобразования, такие как:

Select FirstName, LastName, Celsius([DailyGreenHouseTemp]) from tblGreenHouse.

Вышеуказанное ежедневное чтение температуры может в Фаренгейте, и вам просто нужно определить публичную функцию, называемую Celsius, как это:

Public Function Celsius(Temperature As Variant) As Variant

   Celsius = (Temperature * 1.8) + 32

End Function

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

Итак, как только мы определяем такую ​​публичную функцию, тогда ключевая концепция такова, что такая функция может использоваться не только в коде VBA как выражение, но ТАКЖЕ можно использовать достаточно удивительно, эта способность включает SQL.

Так что даже в коде вы можете пойти:

If MyCustomfucntion(SomeVar) = lngTestValue then

В приведенном выше примере вы не можете использовать суб в выражениях VBA.

И еще более интересным является использование пользовательского XML для лент в Access, а затем, если вы используете выражение function() для атрибута "on action", вы можете избежать необходимости обратного вызова ленты. Еще лучше, что лента вызовет эти функции() в текущей форме, а не модуль общедоступного кода, как вы ДОЛЖНЫ делать с обратными вызовами ленты.

Возможно, я мог бы набрать еще 10 страниц на разницу, но я думаю, что это начнет быть избыточным, и я не хочу казаться каким-то конденсированным здесь.

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

И преимущества использования функции в Access или практически любого языка программирования тоже одинаковы. Например, я могу определить пользовательскую функцию в t-sql (scalar) - и снова вы можете использовать эту функцию t-sql в любом из ваших t-sql-кода или даже в запросах, которые вы создаете и используете для SQL-сервера.

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

Ответ 3

Да, функция - это просто Sub, который возвращает значение.

Ответ 4

Я не совсем уверен, однако, я думаю, что подсистемы быстрее, чем функции, потому что переменные подпрограммы определены при создании подпрограммы и к ней обращаются путем ссылки на ячейку памяти. Функции должны выделять пространство памяти при каждом доступе.

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

Ответ 5

FWIW (моя теория;) -

Давайте подумаем о реальном мире, чтобы понять это.

Предположим, вы хотите что-то сделать. Есть (по крайней мере) два способа сделать это.

В первую очередь, отправьте запросы на информацию помощникам, и они вернутся с информацией для вас. поэтому вы остаетесь в контроле, т.е. вся информация возвращается вам, и вы решаете, что делать дальше, если таковые имеются. это больше зависит от централизованной среды. это суть "функции" в vba

Во-вторых, разделите работу на отдельные задачи и назначьте ответственность своим помощникам, чтобы завершить задачу для вас, т.е. фактическая работа выполняется здесь помощниками в отличие от просто сбора информации. В этом суть "sub" в vba.

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

Конечно, вы можете испортить цель и иметь функции, которые работают, а субмастеры просто получают информацию, но это будет просто сбивать с толку, когда все сломается! О, но вы не можете это сделать, прочитайте эту ссылку - http://www.cpearson.com/excel/differen.htm, в которой говорится, что Excel запрещает функции, изменяющие значения ячеек, а субсайты вызывается из ячеек.

Ответ 6

Вы заметите, что события всегда являются subs, никогда не функционируют. Однако в MS Access может быть полезно создавать функции, если вы хотите использовать их как свойство события:

On Close: = MyCloseFunction()

Subs может возвращать значение ByRef.