VB6: Взаимодействие с невидимой формой

Question

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

• Создание новой формы с передачей hwnd этой формы, чтобы на ней размещались все применимые окна. Действительно легко сделать, вероятно, довольно гибкий. Все еще некрасиво.
• Вызов видимой формы вручную, извлечение значений, передача заполненных пользователем данных в невидимую форму. Это решение, вероятно, самое простое, но это также и взлом. Это ужасное решение, если оно использовалось для более чем небольшого числа форм, но, вероятно, оно будет.
• Создание нового класса с рефакторингом форм для запуска по событиям.
• Установка главной формы видимой, но извращение функции загрузки, чтобы она ничего не отображала.

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

• Что я на самом деле и сделал: вставил вызов выполнения оболочки в уязвимом месте, что запускает новый экземпляр копии программы, которая была скомпилирована с разными флагами. Это не так плохо, как кажется. Частично проблема использования любого другого решения состоит в том, что ЛЮБОЕ время, когда я хочу добавить другой код в мой код, мне нужно создать новый класс контроллера, который по-разному обрабатывает соответствующие события. Большая часть интерфейса программы уже отделена от ее реализации, но создание нового пользовательского интерфейса требует от меня добавления дополнительных обработчиков событий и тому подобного. По общему признанию это, вероятно, только потребовало бы приблизительно 3 обработчиков событий, запрашивающих пользователя для ввода, когда события инициированы.

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

Answer 1

последний вариант предпочтительнее; после рефакторинга не должно быть избыточного кода

возиться с невидимыми формами - довольно хороший показатель необходимости рефакторинга!

Answer 2

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

Сделайте резервную копию или проверьте все в вашем контроле исходного кода и создайте ветку.

Создайте новый проект ActiveX DLL. Я бы назвал это некоторым вариантом UI_Controller

Примечание. Новый проект заставит вас определить скрытые зависимости в EXE-файле.

Сделайте ссылку на все, что сейчас является EXE-файлом.

Сделайте так, чтобы проект EXE ссылался на UI_Controller.

Создайте класс для каждой основной формы в приложении.

Скопируйте второстепенные диалоги в DLL-библиотеку UI_Controller.

Для каждой формы создайте интерфейсный класс в DLL-библиотеке UI_Controller (форма будет реализуя это)

Пример: если у вас есть шесть основных форм, у вас есть шесть интерфейсов форм и шесть классов контроллеров

Просмотрите форму для каждой процедуры и события. Скопируйте процедуру в класс контроллера UI и сделайте ее общедоступной.

Убедитесь, что у каждого класса контроллеров есть процедура Init.

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

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

Измените любые прямые ссылки на форму на вызов в интерфейсе.

Ваши основные формы должны реализовывать каждый интерфейс. Создайте класс GlobalMultiUse в своей DLL контроллера UI, который позволяет EXE регистрировать каждую форму на своем контроллере. Подпрограммы регистра должны принимать только объект интерфейса формы. В вашем приложении инициализации передайте все основные формы для правильной функции регистрации, прежде чем делать что-либо еще.

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

Когда программное обеспечение работает без ошибок. Проверьте это в своем контроле источника или сделайте резервную копию.

Начните заменять каждую процедуру ОДНОЙ из ваших основных форм вызовом соответствующего метода формы вашего контроллера. Если какая-либо другая форма вызывает что-то в форме, над которой вы работаете, переключитесь на контроллер.

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

Когда это работает правильно, работайте над другой формой. Продолжайте делать это, пока все формы не будут преобразованы.

Очистите все, что не используется.

Проверка, и если она прошла, то все готово.

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

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