Как удалить "хвосты" от удаленных вручную листов рабочей книги?

Добрый день.
Листы, создаваемые программным кодом, путем копирования из шаблонного, и имеющие программный код обработчиков своих предопределенных процедур, иногда (в результате сбоев в работе и остановки исполнения кода по ошибке) не могут быть так же -программно- и своевременно удалены из книги и остаются в виде не нужных "хвостов". Я периодически затирал их вручную тупо удалением листа через контекстное меню ярлыка листа и считал, что этого достаточно.
Как выяснилось, в инспекторе объектов эти объекты продолжают существовать, но не могут быть там же удалены вручную. Соответствующая опция просто не активна. По имени листа, например WorkSheets("Лист1").Delete программно он тоже не собирается удаляться. Ошибка.
Перебор листов рабочей книги через For Eaсh вообще не замечает их существования. Как будто их нет.
Как избавиться от таких объектов?

0

Сообщение от Сфалерит Дело в том, что созданных листов за сеанс работы можно наплодить кучу, которая приведет к перегрузу оперативной памяти

Я имел в виду не сеанс, а время выполнения основного макроса. Макрос закончился запускаем удаление.

Сообщение от Сфалерит Явные глюки возникают в основном всегда при отладке, если ставишь условие на изменение какой-то переменной.

Если речь о Debug.Assert, вот, кстати, ни когда этим не пользовался, мне всегда проще написать простое условие.

Добавлено через 18 минут
Решение я вижу такое, это можно сделать программно:
1) скопировать все листы в новую книгу.
2) экспортировать все модули vba с помощью VBE
3) импортировать эти модули в vba-проект новой книги.

0

Сообщение от testuser2 Я имел в виду не сеанс, а время выполнения основного макроса. Макрос закончился запускаем удаление.

Не. Так не работает. Все много запущеннее )))
Макросов, которые бы создали листы и удалили их - очень мало среди постоянно находящихся в работе. Отдельные макросы создают листы. Потом пользователь работает с этими листами и Логпрог интерактивно отрабатывает иные макросы, которые дают пользователю новые данные. Часто организуют переходы из отрисованной на листе таблицы к другой таблице, которая раскрывает суть какого-то выбранного пользователем параметра. Таким образом отдельно друг от друга существует несколько листов с обработчиками событий листа. Все обработчики спят и код не исполнется, пока пользователь не здействует какой-то из них какими-то действиями. Обработчики выполняют набор команд и снова код отстанавливает выполнение. А когда пользователь дает команду ХАРЭ, сворачиваем лист, то он удаляется с сохранением или без сохранения в БД правок, которые на нем сделаны. Т.е. код отрабатывает интерактивно по сотне раз, то запускаясь, то вновь останавливаясь отработав свое, реагируя буквально на каждое перемещение по листу и между листами и каждый раз производя какие-то узкие манипуляции с одним и тем же листом или группой.
Т.е. разные макросы, запущенные и отработавшие свое в совершенно разное время, корпят над одним и тем же листом данных.

Добавлено через 5 минут

Сообщение от testuser2 мне всегда проще написать простое условие.

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

Добавлено через 2 минуты

Сообщение от testuser2 Решение я вижу такое, это можно сделать программно: 1) скопировать все листы в новую книгу. 2) экспортировать все модули vba с помощью VBE 3) импортировать эти модули в vba-проект новой книги.

Ну, по сути, это опять же, не решение, а способ обойти проблему. Собственно, то, что уже сделано. Только сделано вручную, а тут предложение автоматизировать этот процесс.
Как бы, да. Вариант рабочий. Но, наверняка же имеется прямое решение по удалению, без переноса данных в другую книгу... Должно быть. Просто мы не знаем, как это делать.

0

Сообщение от Сфалерит Как избавиться от таких объектов?

Все новые листы создавать в новой, специально созданной для этого "временной" книге.
Не?

0

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

0

Сообщение от Сфалерит И второй - это временный файл со всеми этими листами, каждый из которых имеет обработчики стандартных событий листа.

Обработчики событий не обязательно добавлять внутрь листа, можно сделать отдельный класс с обработчиками.

1

В создании классов дуб. Не пользовался этой возможностью. Смутно представляю себе, как это лист окажется без кода если модули класса присутствуют? А как они вызываются, если не кодом обработчика события листа?
У меня нет кнопок для каких-либо команд. Весь интерфейс реализован на оценке положения активной ячейки. Определенный набор изменения положений воспринимается как команда. Так же, как команды воспринимается двойной клик, нажатие правой кнопки мыши, Enter и Tab
как без обработчиков onkey и задействования предопределенных обработчиков событий листа можно это реализовать?

0

Сообщение от Сфалерит предопределенных обработчиков событий листа можно это реализовать?

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

0

Да, увы, код регулярно дописывается и сбои после новых дописок всегда проскакивают. Например, сегодня утром прекрасная новость, порожденная новым кодом. Вдруг оказалось, что в отдельно сохраняемых книгах имя листа почему-то иной раз задается с обрамляющими ковычками. Как так происходит - фиг знает. Если в ярлычке листа смотришь его название - там не предраться. Оно такое же, как и должно быть. Если наводишь курсор на переменную с именем листа, то контекстная подсказка в редакторе VBA - тоже не выдает засады. Все корректно. И только лишь Watch окно наблюдения за значением переменной выдало суть проблемы. Только внем видно, что лист имеет имя, которое обрамлено в доп. пару ковычек. Откуда сия зараза прет и почему не в каждом случае, а в отдельных - надо еще разбираться. Но факт... вот такие вот сюрпризы - они вылезают не сразу порой. И дело тут не в не объявленных переменных. В коде, который генерирует файл с этими листами - все объявлено. Нет переменных отладочных никаких. Просто либо глюк, который придется обходить заплатками, либо сам где-то профукал. Буду искать еще. Но скорее всего глюк, потому что присвоение имени листа не прямое, а через string переменную, берущую значение из ячейки. В ячейке точно нет никакого обрамления в ковычки. Мне лень лишиние ковычки рисовать. Я этого не делаю. А вот откуда их выковырял сам Ексель - вопрос века! Кстати, к числу таких условно глюков, которые приходится латать, например относится результат выполнения ThisWorkBook.path
Ну кто бы мог подумать, что на разных версиях Ексель и ОС он выдает разное? В одних случаях с закрывающим слэшем, в других - без него. И вот работает себе прога нормально, пока ее не перенес на другой комп. И таких моментов дохрена. Я вот не понимаю эти истории про хороших програмеров, которые все это могут предвидеть. Скорее, подобные суждения идут от недостатка опыта от людей, ничего серьезного не создававших и ограничивавшихся процедурками в два десятка строк кода. Для них применение Option Explicit - потолок профессионализма.

Сообщение от testuser2 либо динамически добавлять код в эту книгу, либо (самый лучший вариант) добавляние заранее заготовленных шаблонных листов уже содержащих код.

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

0

Посмотрел код чуть внимательнее - на предмет архитектурных улучшений - но бесполезно.
Кто-то пропускает свой код через обфускатор, а Вы , Сфалерит, пишите как будто специально как обфускатор.

Обработчик событий всех листов можно сделать один, в модуле ЭтаКнига
Только донастроить условия для определенных разрешенных шаблонов имен листов

Добавлено через 6 минут
Но от событий в такой мешанине лучше бы отказаться, работать только кнопками.

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

2

Я не совсем понял, как это один обработчик событий всех листов ?
Вот у меня допустим есть лист c названием "A1" и "есть" лист с названием "A2"
Допустим, я в обоих листах по очереди сделал двойной клик. Один и тот же обработчик должен будет два раза отработать.
Но каким образом ему будет передаваться выполнение? Что запустит этот обработчик? Какое событие??

0

Двойной клик запустит каждый раз событие книги
В этой событийной процедуре указан объект Sh - конкретный лист, на котором произошел DoubleClick

1

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

0

Пример лайт:

Вложения

tmpWorkbook.zip (10.7 Кб, 4 просмотров)

1

Сообщение от KoGG а Вы , Сфалерит, пишите как будто специально как обфускатор.

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

0

Сообщение от Сфалерит Но рекурсию организовать не удается, т.к. вызов AH событиен, _ т.е. пока не отработает обработка текущего события , не сможет сработать вызов обработки иного события - т.е не будет _ запущена вторая AH из нового контекста.

Можно попытаться разнести запуск экземпляров АН в разные Excel.Application.
Пущай работают параллельно.

0

С этим уже поздно. Тут всю архитектуру приложения переделывать придется. Проще писать все заново, чем править то, что есть. Ибо нестыковок будет вылезать уйма. Утону в них. На основное ядро управления - AH, AR, AN - все параметры приложения завязаны. Эти три процедуры банкуют, раздавая указания и синхронизируя все остальные.

0

Сообщение от Jamaica пока не отработает обработка текущего события , не сможет сработать вызов обработки иного события - т.е не будет _ запущена вторая AH из нового контекста.

Здесь не пойму точно о какой ситуации речь, но вообще внутри события/процедуры можно пропустить (тобеж позволить) другое событие (если оно стит в очереди выполнения), для этого достаточно добавить DoEvents (иногда лучше два DoEvents подряд). Если событие инициировано внутри процедуры (допустим изменена ячейка) то событие выполняется внутри этой процедуры (без ожидания), т.е. это равноценно вызову другой процедуры.

0

DoEvents експлуатировать в коде заложено. Можно не дожидаясь отработки одного "контекста" (работа процедур заполнения данными какого-то листа) запускать уже следующий. Такая необходимость возникает, когда запускается длительный процесс. Например анализ нового прайса и его автостыковка с уже существовавшими ранее с приблизительно похожими значениями. Сответствующая процедура пытается вычислить степень похожести названий товаров и наиболее похожие слинковать между собой. Процесс может занимать до нескольких часов, когда строк в стыкуемых прайсах по нескольку тысяч. Но, хоть этот функционал и работает, я избегаю его использования. И вот почему.
Слишком много переменных в проекте. Переменных уровня проекта. Все они активно взаимодействуют и меняют свои значения. Передавать их через заголовки процедур не реально. Но это не самое страшное. Больше печалит объем данных. Оперативка раздуется, если передавать не по ссылке, а по значению, плодя каждый раз новые экземпляры массивов данных.
Параметры исчисляются сотнями. Поэтому побочный эффект не желательного использования и одновременного изменения одной и той же переменной двумя разными процедурами вразрез практически гарантирован. Т.е. последствия такой работы всегда рулетка. Поэтому, если так делаю, то лучше не дышать и тихо ждать, что будет дальше? Так что, DoEvents вариант признан мною нежелательным для данной архитектуры приложения, не гарантирующим стабильности работы. Однако, когда сильно надо - запускаю. Но не на всех операциях откатывает безошибочно.
Еще проблема DoEvents связана с тем, что код под его контролем склонен самопроизвольно тухнуть. Обрывать цепочку исполнения на текущей процедуре, не возвращаясь к довыполнению предшествующей. Это тоже одна из его бед. Почему такое иногда происходит, я не совсем понимаю. Не смог найти закономерности.

0

Сообщение от Сфалерит Параметры исчисляются сотнями.

А для кого придумали классы, структуры, пользовательские типы?

Сообщение от Сфалерит одновременного изменения одной и той же переменной двумя разными процедурами

"Глобальные переменные - зло" (с)

0

Сообщение от I can А для кого придумали классы, структуры, пользовательские типы?

Для сокращения объема кода и читабельности кода. Но количество информации они не сокращают. Если определенный объем информации нужен, то он нужен и каждый экземпляр класса\типа если ее требует, то он ее требует. Хоть ты массивы используй с одним из индексов для отдельных экземпляров структур (мой вариант), хоть структурируй классами и типами. Чудес не произойдет.
Добавлено через 1 минуту

Сообщение от I can "Глобальные переменные - зло" (с)

Тут соглашусь. Но Бэйсик не очень то подходит для сложных структур данных. Не под них он создавался. А потому формально можно глобалку комуфлировать, но то все равно пародия на объектно-структурированное программирование будет - вычурно. Я даже не пытаюсь.
Контекст каждого создаваемого листа содержит десятки мегабайт информации. Ее нельзя каждый раз заново в полной мере копировать в каждый новый экземпляр. Оперативка не даст. Поэтому много информации имеет видимость уровня модуля, чтобы с ней работать по ссылке.
Я прежде всего рассматриваю проекты на VBA как инструмент откатки идей автоматизировать то, что еще не делалось в помине. Тут главное попробовать сделать на самом примитивном уровне, откорректировать свои представления о решении задачи, когда в процессе кодирования откроешь для себя сложности, о которых ранее не задумывался. Вот, когда появится более менее красивый алгоритм решения, то при необходимости уже есть смысл его реализовывать в виде самостоятельного независимого приложения в иной среде программирования. Но в данный момент у меня нет такой нужды. Задачи, решенные весьма на скорую руку, по итогу закрыты. То, что делает программа - мне достаточно. 20% усилий дали свои 80% эффекта. А то, что я отнюдь не оптимально кодирую - спору нет. Я - не профессионал. Я делаю для себя по мере наличия времени. Я всю жизнь учусь. Всю жизнь совершенствуюсь в данном вопросе. Открываю для себя новые инструменты в VBA объектной модели Екселя. Мой код постепенно эволюционирует в сторону упрощений и изящества. До совершенства ему очень далеко. Но эволюция все время происходит. И ее можно даже проследить от процедуры к процедуре, названия которым даются в алфавитном порядке от одной из первых - aa до выполненной на днях kt. Одно и то же ранее и сейчас реализуется по-разному. Первые процедуры были очень примитивны по набору используемых объектов Excel. Код был много более громоздок, чем если б я его писал сейчас. Но он работает и мне нет смысла его трогать.

0