Сообщение Re[2]: Мысли об MFC от 04.05.2017 11:56
Изменено 04.05.2017 12:27 AlexGin
Re[2]: Мысли об MFC
Здравствуйте, qaz77, Вы писали:
Q>Здравствуйте, AlexGin, Вы писали:
AG>d) Архаичная архитектура Doc/View (Документ/Вид)
AG> Это усложнение, которое просто приходится обходить в современных проектах -
AG> напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View
Q>Вот здесь не соглашусь.
Q>Апп визард и в 6.0, и в современных студиях позволял отказаться от Doc/View.
Q>При этом класса документа не создавалось вообще, а вместо CView подставлялся просто CWnd.
Q>Это и в MDI работало, и в SDI.
Как это может реально работать, если и SDI, и MDI проекты в InitInstance создают и 'регистрируют' шаблон документа?
Ниже приведен пример из одного из моих старых проектов: переопределенный метод InitInstance:
Вот такие есть шаблоны документов:
CMultiDocTemplate: https://msdn.microsoft.com/en-us/library/58d94y2f.aspx
CSingleDocTemplate: https://msdn.microsoft.com/en-us/library/7yha6tek.aspx
Каждый из них определяет набор: документ/окно_рамки/вид для каждого дочернего MDI (или же для единственного SDI) окна.
Этот механизм встроен в самое ядро MFC, посему его обойти не так-то просто.
В реальности — проще оставить 'фейковый' (пустой) класс документа, нажели пытаться обойти архитектуру Doc/View, заложенную в фундамент MFC
Q>Единственная известная мне фича, жестко завязанная на Doc/View, это предварительный просмотр печати (который CPreviewView, кажется).
Q>Если им пользоваться, то да, только фейковые документы, док-темплейты и вьюшки.
Да, это одна из фич, завязанных на Doc/View.
Ещё интересная фича:
переопределив этот метод, можем заменить сообщение о том, что юзер забыл сохранить документ.
Другое дело, что все эти фичи НЕ стоят тех усложнений и ограничений, что дополнительно вносит Doc/View
Q>Сам я в Doc/View от MFC много толку не вижу.
+100500
Да, именно поэтому данная архитектура и не сохранилась, по крайней мере в таком виде как в MFC, для современных фреймворков.
Q>Там все слишком ориентированно на файлы и сложно под свою задачу кастомизировать.
Q>Мне всегда было проще свой Model/View замутить.
Совершенно верно! У меня точно такая же проблема.
ИМХО все равно, потребуется разрабатывать свою бизнес-логику (включая свою реализацию "документа"), посему Doc/View от MFC и теряет смысл.
Q>Здравствуйте, AlexGin, Вы писали:
AG>d) Архаичная архитектура Doc/View (Документ/Вид)
AG> Это усложнение, которое просто приходится обходить в современных проектах -
AG> напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View
Q>Вот здесь не соглашусь.
Q>Апп визард и в 6.0, и в современных студиях позволял отказаться от Doc/View.
Q>При этом класса документа не создавалось вообще, а вместо CView подставлялся просто CWnd.
Q>Это и в MDI работало, и в SDI.
Как это может реально работать, если и SDI, и MDI проекты в InitInstance создают и 'регистрируют' шаблон документа?
Ниже приведен пример из одного из моих старых проектов: переопределенный метод InitInstance:
m_pPhoneBookTemplate = new CMultiDocTemplate(IDR_PhoneBookTYPE,
RUNTIME_CLASS(CPhoneBookDoc),
RUNTIME_CLASS(CChildFrame), // настраиваемая дочерняя рамка MDI
RUNTIME_CLASS(CPhoneBookView));
if (!m_pPhoneBookTemplate)
return FALSE;
AddDocTemplate(m_pPhoneBookTemplate);
Вот такие есть шаблоны документов:
CMultiDocTemplate: https://msdn.microsoft.com/en-us/library/58d94y2f.aspx
CSingleDocTemplate: https://msdn.microsoft.com/en-us/library/7yha6tek.aspx
Каждый из них определяет набор: документ/окно_рамки/вид для каждого дочернего MDI (или же для единственного SDI) окна.
Этот механизм встроен в самое ядро MFC, посему его обойти не так-то просто.
В реальности — проще оставить 'фейковый' (пустой) класс документа, нажели пытаться обойти архитектуру Doc/View, заложенную в фундамент MFC
Q>Единственная известная мне фича, жестко завязанная на Doc/View, это предварительный просмотр печати (который CPreviewView, кажется).
Q>Если им пользоваться, то да, только фейковые документы, док-темплейты и вьюшки.
Да, это одна из фич, завязанных на Doc/View.
Ещё интересная фича:
virtual BOOL SaveModified( );
переопределив этот метод, можем заменить сообщение о том, что юзер забыл сохранить документ.
Другое дело, что все эти фичи НЕ стоят тех усложнений и ограничений, что дополнительно вносит Doc/View
Q>Сам я в Doc/View от MFC много толку не вижу.
+100500
Да, именно поэтому данная архитектура и не сохранилась, по крайней мере в таком виде как в MFC, для современных фреймворков.
Q>Там все слишком ориентированно на файлы и сложно под свою задачу кастомизировать.
Q>Мне всегда было проще свой Model/View замутить.
Совершенно верно! У меня точно такая же проблема.
ИМХО все равно, потребуется разрабатывать свою бизнес-логику (включая свою реализацию "документа"), посему Doc/View от MFC и теряет смысл.
Re[2]: Мысли об MFC
Здравствуйте, qaz77, Вы писали:
Q>Здравствуйте, AlexGin, Вы писали:
AG>d) Архаичная архитектура Doc/View (Документ/Вид)
AG> Это усложнение, которое просто приходится обходить в современных проектах -
AG> напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View
Q>Вот здесь не соглашусь.
Q>Апп визард и в 6.0, и в современных студиях позволял отказаться от Doc/View.
Q>При этом класса документа не создавалось вообще, а вместо CView подставлялся просто CWnd.
Q>Это и в MDI работало, и в SDI.
Как это может реально работать, если и SDI, и MDI проекты в InitInstance создают и 'регистрируют' шаблон документа?
Ниже приведен пример из одного из моих старых проектов: переопределенный метод InitInstance:
Вот такие есть шаблоны документов:
CMultiDocTemplate: https://msdn.microsoft.com/en-us/library/58d94y2f.aspx
CSingleDocTemplate: https://msdn.microsoft.com/en-us/library/7yha6tek.aspx
Каждый из них определяет набор: документ/окно_рамки/вид для каждого дочернего MDI (или же для единственного SDI) окна.
Этот механизм встроен в самое ядро MFC, посему его обойти, увы, не так-то просто (когда-то я экспериментировал с этим).
В реальности — проще оставить 'фейковый' (пустой) класс документа, нажели пытаться обойти фундаментальную архитектуру Doc/View
Q>Единственная известная мне фича, жестко завязанная на Doc/View, это предварительный просмотр печати (который CPreviewView, кажется).
Q>Если им пользоваться, то да, только фейковые документы, док-темплейты и вьюшки.
Да, это одна из фич, завязанных на Doc/View.
Ещё интересная фича:
переопределив этот метод, можем заменить сообщение о том, что юзер забыл сохранить документ.
Другое дело, что все эти фичи НЕ стоят тех усложнений и ограничений, что дополнительно вносит Doc/View
Q>Сам я в Doc/View от MFC много толку не вижу.
+100500
Да, именно поэтому данная архитектура и не сохранилась, по крайней мере в таком виде как в MFC, для современных фреймворков.
Q>Там все слишком ориентированно на файлы и сложно под свою задачу кастомизировать.
Q>Мне всегда было проще свой Model/View замутить.
Совершенно верно! У меня точно такая же проблема.
ИМХО все равно, потребуется разрабатывать свою бизнес-логику (включая свою реализацию "документа"), посему Doc/View от MFC и теряет смысл.
Q>Здравствуйте, AlexGin, Вы писали:
AG>d) Архаичная архитектура Doc/View (Документ/Вид)
AG> Это усложнение, которое просто приходится обходить в современных проектах -
AG> напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View
Q>Вот здесь не соглашусь.
Q>Апп визард и в 6.0, и в современных студиях позволял отказаться от Doc/View.
Q>При этом класса документа не создавалось вообще, а вместо CView подставлялся просто CWnd.
Q>Это и в MDI работало, и в SDI.
Как это может реально работать, если и SDI, и MDI проекты в InitInstance создают и 'регистрируют' шаблон документа?
Ниже приведен пример из одного из моих старых проектов: переопределенный метод InitInstance:
m_pPhoneBookTemplate = new CMultiDocTemplate(IDR_PhoneBookTYPE,
RUNTIME_CLASS(CPhoneBookDoc),
RUNTIME_CLASS(CChildFrame), // настраиваемая дочерняя рамка MDI
RUNTIME_CLASS(CPhoneBookView));
if (!m_pPhoneBookTemplate)
return FALSE;
AddDocTemplate(m_pPhoneBookTemplate);
Вот такие есть шаблоны документов:
CMultiDocTemplate: https://msdn.microsoft.com/en-us/library/58d94y2f.aspx
CSingleDocTemplate: https://msdn.microsoft.com/en-us/library/7yha6tek.aspx
Каждый из них определяет набор: документ/окно_рамки/вид для каждого дочернего MDI (или же для единственного SDI) окна.
Этот механизм встроен в самое ядро MFC, посему его обойти, увы, не так-то просто (когда-то я экспериментировал с этим).
В реальности — проще оставить 'фейковый' (пустой) класс документа, нажели пытаться обойти фундаментальную архитектуру Doc/View
Q>Единственная известная мне фича, жестко завязанная на Doc/View, это предварительный просмотр печати (который CPreviewView, кажется).
Q>Если им пользоваться, то да, только фейковые документы, док-темплейты и вьюшки.
Да, это одна из фич, завязанных на Doc/View.
Ещё интересная фича:
virtual BOOL SaveModified( );
переопределив этот метод, можем заменить сообщение о том, что юзер забыл сохранить документ.
Другое дело, что все эти фичи НЕ стоят тех усложнений и ограничений, что дополнительно вносит Doc/View
Q>Сам я в Doc/View от MFC много толку не вижу.
+100500
Да, именно поэтому данная архитектура и не сохранилась, по крайней мере в таком виде как в MFC, для современных фреймворков.
Q>Там все слишком ориентированно на файлы и сложно под свою задачу кастомизировать.
Q>Мне всегда было проще свой Model/View замутить.
Совершенно верно! У меня точно такая же проблема.
ИМХО все равно, потребуется разрабатывать свою бизнес-логику (включая свою реализацию "документа"), посему Doc/View от MFC и теряет смысл.