Страницы: 1
RSS
Передать управление другому макросу
 
Есть желание оптимизировать, но нет опыта :(  
Задача: оперативная выборка из базы данных (около 40 столбцов) по определенным критериям.  
Решение: данные организованы в список (лист “Данные”), на отдельном «листе управления» ”Главная” кнопки (штук 50), которые фильтруют список. На кнопки навешены макросы, отличающиеся друг от друга средней частью (часть2). Чтобы убрать лишнюю писанину, создан макрос Общий, которому передается управление после выполнения этой самой средней части:  
Sub МакросN ()  
часть1  
часть2  
Общий  
End Sub  
 
Sub Общий ()  
часть3  
End Sub  
 
Вопрос: можно ли еще сократить - в Общий передать часть1?  
Т.е. любой из МакросN вызывает Общий; Общий после выполнения часть1 определяет, какой именно МакросN его вызывал, и разрешает ему выполнить часть2; МакросN, выполнив часть2, любезно разрешает Sub_Общий завершить начатое дело.    
 
Вопрос попутный. По-другому организовать выборку?
 
Можно сложно, но проще с переключателями вместо кнопок, пример - в приложении
 
Похоже, что упакованные файлы приложений теперь нужно сохранять на диск, и лишь потом их открывать с диска. Такое на старом форуме было с файлами Excel 2007.
 
У меня и раньше все упакованные файлы нужно было сохранять на диск.  
Сейчас получилось только так: сохранить в папку загрузки Оперы, и лишь после этого открыть или сохранить на диск.    
За пример спасибо, скачал и убегаю, просмотрю позже.
 
стремление к повторному использованию кода правильно. Для этого оформить в виде подпрограмм общие части. Разных. если трудности с передачей параметров, то подумать об их обявлении в пространстве модуля.. или еще как извернуться :)
Живи и дай жить..
 
{quote}{login=ZVI}{date=20.12.2008 09:43}{thema=}{post}проще с переключателями вместо кнопок{/post}{/quote}  
Хорошая идея. Похожая мысль проскакивала - МакросN пишет в ячейку свое имя, а Общий использует запись для передачи управления.
 
Обычно для унификации функциональности кнопок используются объекты классов, реагирующих на события. Уже одна эта замысловатая фраза может отбить охоту разбираться с классами, особенно в начале освоения VBA.  
Помню эти трудности, поэтому предлагаю альтернативные варианты попроще.  
 
В приложении к предыдущему добавлен более универсальный вариант псевдо-класса для псевдо-кнопок. Макрос MyMacro1 сам разбирается, какая кнопка-автофигура его вызвала.
 
К сожалению, на листе множество кнопок-автофигур, многие из них объединены в группы с одинаковым текстом, но вызывающие разные макросы.  
Более развернуто.  
Есть лист с несоответствиями по качеству (браком), куда занесены данные - цех, вид документа, виновник, начальник, текст-описание, текст-устранение и т. д. Одна строка - один брак.  
Есть лист, где размещены кнопки для выборки. Например, кнопки "Акты" фильтруют данные по актам, но только по тому цеху, к которому "приписана" данная кнопка.  
Я думаю, для решения проблемы передачи управления другому макросу достаточно моего первого примера.  
 
А если материализовать мысль с записью имени макроса в ячейку и дальнейшем считывании его (имени) общим макросом? Как это может выглядеть?
 
Приложен вариант с макросом MyMacro1, который теперь определяет не название, а номер автофигуры-кнопки. Имена таких кнопок могут быть одинаковыми.  
 
А для идеи вызова макроса по его имени в ячейке можно использовать:  
Application.Run "ИмяМакроса"    
Но зачем это делать? В общий макрос можно просто передать параметр (номер или строку), по которой общий макрос и сориенттируется, что именно ему нужно сделать, в зависимости от параметра.
 
Спасибо, ZVI, это, по-моему, в самое яблочко!  
Пора начинать дружбу с VBA (А он не против?) :)
Страницы: 1
Читают тему
Наверх