Я взялся за задачу написать собственный эмулятор терминала. Если проект когда-нибудь воплотится в жизнь, он станет точной копией VanDyke SecureCRT.
Он должен поддерживать протоколы Telnet и SSH, а если дела пойдут хорошо, возможно, и больше.
На данный момент я работаю над самым простым из них — Telnet.
Приложение представляет собой MFC MDI, и здесь мне нужен ваш совет. Как лучше его структурировать?
Создать один шаблон документа для каждого протокола? Это кажется ужасной тратой, поскольку большая часть кода останется прежней.
Должно ли все быть сделано в классе Document? И есть ли просмотр только для отображения?
Или пусть представление выполняет всю работу по подключению, чтению пользовательского ввода и отображению вывода сервера?
Должно ли быть два представления? По одному на каждый протокол? Насколько я понимаю, это не так-то просто сделать и лучший способ сделать это возвращает меня к сценарию с двумя шаблонами документов.
Я написал работающий клиент Telnet для командной строки и на данный момент я дошел до того момента, когда мне нужно решить, как поступить с Windows.
Избегайте MDI, если можете. Это модель пользовательского интерфейса, которая еще не устарела. Вы столкнетесь с ошибками на системном уровне, которые обычно не имеют решения.
Спасибо @IInspectable за комментарий. Я не знаю, как я придерживался MDI. Тем не менее, это хобби/учебный проект. По профессии я не программист, поэтому какие бы знания я ни получил от этого, это будет плюс. Вдобавок ко всему, большая часть кода, который я пишу, вполне может быть использована в следующем проекте, когда мне будет достаточно MDI :D





В MFC вы обычно мало работаете (я бы сказал вообще) с классом шаблона документа. Шаблон документа — это ассоциация идентификатора ресурса с документом, фреймом-окном и классом представления. Платформа выполняет все свои операции, и я не понимаю, почему может потребоваться изменить ее поведение. Вместо этого вы создаете экземпляры класса CSingleDocTemplate (SDI) или CMultiDocTemplate (MDI) — по одному для каждой желаемой комбинации — в члене InitInstance() класса вашего приложения.
Одним из решений может быть:
CWinApp::InitInstance(), и я бы сказал, сохраните два указателя экземпляра.GetDocument()) напрямую или, что предпочтительнее, через функции-члены документа.(1) Если вы обнаружите, что данные и/или операции двух протоколов очень похожи или почти идентичны, поэтому такая реализация была бы «ужасной тратой», вы можете определить общего предка или «базовый» класс документа (с помощью некоторые виртуальные или чисто виртуальные члены) и измените два класса документов так, чтобы они наследовались от этого, а не от CDocument.
(2) Совет по реализации: проверьте функции UpdateData(), OnUpdate() и UpdateAllViews().
(3) Возможно, вы захотите использовать отдельные потоки для операций подключения/отправки/чтения, особенно если вы подключаетесь к нескольким серверам и/или ваш API является только синхронным/блокирующим. Эти операции могут «заморозить» ваше приложение до тех пор, пока сервер не ответит.
Чтобы написать «чистый» MFC, попытайтесь структурировать свою программу так, чтобы класс(ы) документа не имел своих классов представления, т. е. класс документа не должен «знать» или делать предположения о своих представлениях. Для выполнения специальных обновлений вы можете закодировать необходимую информацию в параметрах #include и lHint функции pHint; вызов UpdateAllViews() означает полное обновление для всех представлений документа.
Определить два или более классов представления не особенно сложно, по крайней мере, я не понимаю, почему. Вы даже можете найти примеры использования двух или трех классов представления для одного и того же документа, например «графического» и «форменного», в одном дочернем фрейме MDI или в отдельных дочерних фреймах (в этом случае фреймворк называет их , например Документ1[1], Документ1[2] и т. д.). И если операции представления по существу одинаковы, вы можете просто определить один тип представления и вызвать виртуальные функции-члены базового класса документа (фактически это вызовет переопределенные функции).
Большое спасибо. Я буду следовать этому подходу. Ваше здоровье
Архитектура представления документов основана на MVC. С этим связан паттерн Observer. В общем, представления должны выполнять часть графического интерфейса/презентации, а документ - часть «модели».