1

Topic: Thoughts about MFC

All resulted more low, it personally my reasons on library MFC and concerning a place of the given product in the modern world Besides, here: http://rsdn.org/forum/cpp.qt/6769008.1 the Author: MasterZiv Date: 27.04 18:21 I promised to companion MasterZiv to return to a subject of arguing MFC (only already in the given section, instead of in section on Qt). I started to be engaged on MFC in 1999. I will more precisely tell that it was the first class library mastered by me. After it was: a Borland C ++ Builder (VCL);.NET (C#) and, at last, Qt. Therefore - like as is with what to compare. However - to compare C# and MFC it is somehow illogical (different host languages), therefore we leave only that on a C ++ I will in passing note that I apply to some projects MFC and for today. ADVANTAGES: 1) Legkovesnost. As MFC is rather small object-oriented (however - about it hardly more low) a superstructure over WIN API it weighs at all much. To the modern measures - practically anything. 2) Intuitive clearness of library MFC for the developers owning WIN API. Class library MFC represents a dial-up of classes and methods for those entities which make a basis of window interface Windows that simplifies understanding of the entities defined in library MFC. 3) Great volume of operating time - as on the Internet (codeguru, codeproject etc.) And in old repositories of developers, therefore - possibility quickly to receive the answer (including here again - on ) on the most various aspects of application. 4) for the simplicity account, thanks to presence of source codes and already specified operating time - big  (possibility to make that the left heel of the Customer wants). 5) it is necessary to mark that MFC develops (truth extensively) - MFC Feature Pack  to develop applications with modern enough GUI. That fact that in  MSVC2015 returned MBCS - Multi Byte Character Set (which already threw out from MSVC2013) - also undoubtedly testifies to some popularity MFC today. LACKS (as always - an underside of advantages): a) for today, it appears to make simple enough things completely not simply. Certainly, if worked with MFC many long years an output you will find. But it already another story altogether So, for example, ComboBox as a part of a toolbar: in Qt some lines; On MFC - a heap of the code All right, we leave GUI. We look towards support of popular DBMS. However, here the pattern and that is worse. If VCL and Qt have decent support of a DBMS, for MFC - it is necessary to search and adjust different  to fulfill completely not difficult SQL request. b) the C codes ++ projects on Qt are much more readable and are laconic, rather than on MFC. Programming on MFC, the developer is always connected to superfluous (technical) entities which  would be possible to carry out from the application-oriented code. Even simple dialogue application (without Doc/View), abounds unnecessary in 99 % of situations with entities. So, calls DDX_Control (...) Abounding in DoDataExchange - also on  are represented to me by superfluous technical entities. c) transfer of a ready class from old in the new project is for MFC also dancing with a tambourine! If I want to transfer a window (in sense - successor CWnd)  files  (*.h) and a source code (*.cpp) it appears explicitly insufficiently. It is necessary ' to pick out ' both resources, and identifiers of resources and pens to transfer them on a new place. The conflict on identifiers of resources is a separate problem, there is no its desire to concern, will simply mark - that it is and spoils life of the developer (as always at the most inappropriate moment). In Qt, and in VCL, transfer is a simple copying of files then them we register the project - and we would forget about it! d) archaic architecture Doc/View (Document/kind) also enters superfluous, absolutely irrelevant essence for the XXI-st century. If in 1990, for the text editor it was actual, now is simply superfluous essence on which nevertheless, all library MFC is fastened. This complication which simply should be bypassed in the modern projects - ,  empty document class - is simple for support Doc/View e) Concept of OOP in MFC any vague. I admit that for 1990 it quite even it was normal. For example - the pattern observer for handling of messages is implemented by macroes BEGIN_MESSAGE_MAP/END_MESSAGE_MAP This decision in style old kind ANSI a C, but in any way in style of the modern C ++ If I in a dialog box (studio means) add new , this new member a class...... With any  it is declared as public - instead of private (or at the worst protected). That fact that the abstract classes in MFC are not interfaces, and contain implementation, also represents retreat from ideas of normal object-oriented design. I perfectly understand that there are requirements of compatibility with the old code, but after all could enter, along with support old, and any new variants - corresponding to a today's level of development of technologies... Or M $ already was going to bury MFC the Output: application MFC for today makes sense in simple projects where ease is important. Quite often it is simple a dialog box with statically  library MFC. Choice Qt is obvious To more difficult projects-. For old projects where to it MFC hundred years, also are not present possibilities/finance to pass to something new, application MFC also is actual. I thank all who had enough patience to read up to this line! And even more I thank those who expresses the thoughts in the given occasion!

2

Re: Thoughts about MFC

Hello, AlexGin, you wrote: give advice please on what  better  MFC as now   in life began to use MFC for GUI

3

Re: Thoughts about MFC

Hello, sergey2b, you wrote: S> give advice please on what  better  MFC as now   in life began to use MFC for GUI In due time quite good there was D.Kruglinski's book. Piter Press published it in Russian. Now can something new appeared. Except for the version of Studio and "new" Feature Pack the book is still actual.

4

Re: Thoughts about MFC

Hello, sergey2b, you wrote: S> Hello, AlexGin, you wrote: S> give advice please on what  better  MFC as now   in life began to use MFC for GUI there were many books on MFC Earlier. I will enumerate some, the most successful, from them: 1) Kruglinski , Uingou , Sheferd of J. - programming on Microsoft Visual C ++ 6.0 for professionals 2) Jeff Prosise - Programming Windows with MFC, Second Edition (is not present in Russian translation, I downloaded English-speaking) 3) Kate Gregory - Visual C Usage ++ 6 Where to find now these books - do not know. Can  download somewhere.

5

Re: Thoughts about MFC

Hello, sergey2b, you wrote: S> now   in life began to use MFC for GUI to Hardly you however. Johannesburg?

6

Re: Thoughts about MFC

Hello, bnk, you wrote: bnk> Hello, sergey2b, you wrote: S>> now   in life began to use MFC for GUI bnk> to Hardly you however. Johannesburg? I left therefrom in 11 year there are no USA

7

Re: Thoughts about MFC

Hello, sergey2b, you wrote: bnk>> it is hard to you however. Johannesburg? S> there are no USA Someone here recently, apparently, about backwardness/zakostenelosti of America spoke? Here, one more bright example As a matter of fact, - I will join Kruglinski. If before generally no business with the horror flying on wings of night MFC, had, you can look firststeps.ru

8

Re: Thoughts about MFC

Hello, V. Zudin, you wrote: SVZ> D.Kruglinski's book In due time was quite good. Piter Press published it in Russian. +100500 yes, it was very class book! Somewhere at me it still is,  in Russian in Peter-press. SVZ> now can something new appeared. Unfortunately, now anything on MFC new is not present SVZ> Except for the version of Studio and "new" Feature Pack the book is still actual. Well Feature Pack - I studied on the Internet () about five years ago. Here quite good resources: http://www.codeguru.com/cpp/cpp/cpp_mfc … uction.htm https://www.codeproject.com/Articles/21 … ature-Pack http://ntcoder.com/bab/tutorial_mfc_feature_pack1_part1 Besides, helps idle time  on a function/method/imeni_klassa title - on Feature Pack  not so much as   MFC, but at  - it is possible to find. And site MSDN - as the reference manual on classes and their methods.

9

Re: Thoughts about MFC

Hello, AlexGin, you wrote: AG> there were many books on MFC Earlier. I will enumerate some, the most successful, from them: AG> 1) Kruglinski , Uingou , Sheferd of J. - programming on Microsoft Visual C ++ 6.0 for professionals AG> 2) Jeff Prosise - Programming Windows with MFC, Second Edition (is not present in Russian translation, I downloaded English-speaking) AG> 3) Kate Gregory - Visual C Usage ++ 6 AG> Where to find now these books - do not know. Can  download somewhere. If are not, at my friend like as were, I will throw off if it will be necessary

10

Re: Thoughts about MFC

Hello, rumit7, you wrote: R> if are not, at my friend like as were, I will throw off if it will be necessary to Thanks, respected rumit7, at me all on MFC is It asked sergey2b which had a necessity for learning MFC.

11

Re: Thoughts about MFC

Hello, AlexGin, you wrote: AG> And even more I thank those who expresses the thoughts in the given occasion! To pluses MFC still it is possible to add a heap of wizards for VS which allow without manual  quickly and conveniently enough to add new methods, event handlers, to redefine the virtual functions. As good support COM. Well and me class CSocket for unpretentious network applications always was pleasant. For difficult things certainly it is not necessary to use this class.

12

Re: Thoughts about MFC

Hello, Evgeniy Skvortsov, you wrote: ES> To pluses MFC still it is possible to add a heap of wizards for VS which allow without manual  quickly and conveniently enough to add new methods, event handlers, to redefine the virtual functions. +100500 it, certainly is doubtless so, the studio is a lot of that (in respect of preparations for new applications) is able to make itself. Often it seems to me that M $ supplied the studio with such dial-up of wizards for MFC to hide all   applications  libraries. Type: "and at on it - directly from a box, both here it, and here that..." - in general some decision, can even quite good somehow to compensate swelling of an application-oriented C ++ the code. ES> as good support COM. Yes, COM - the good piece, but at level of the modern decisions is difficult enough bagatelle. For today more simple are claimed for application-oriented application of the decision.

13

Re: Thoughts about MFC

Hello, AlexGin, you wrote: AG> All resulted more low, it personally my reasons on library MFC and concerning a place of the given product in the modern world AG> Besides, here: http://rsdn.org/forum/cpp.qt/6769008.1 the Author: MasterZiv Date: 27.04 18:21 - I promised to companion MasterZiv to return to subject AG> arguings MFC (only already in the given section, instead of in section on Qt). Well, then I should participate in topic AG> 1) Legkovesnost. As MFC is rather small object-oriented (however - about it hardly more low) Well, it is very surprising to hear such, but I understand you. In sense, I would tell as, but many developers do not understand it. For many MFC is a huge and terrible monster. AG> it is fine, we leave GUI. We look towards support of popular DBMS. However, here the pattern and that is worse. If VCL and Qt AG> have decent support of a DBMS for MFC - it is necessary to search and adjust different  that AG> to fulfill completely not difficult SQL request. Yes it is necessary to tell at once simply that in MFC supports of programming from a DBMS simply are not present. That dashing  that there interposed at the time of 6.0 suits only a tick in marketing articles. AG> b) the C codes ++ projects on Qt are much more readable and are laconic, rather than on MFC. It do not agree. Very much depends on what project, what code as it is written, etc. For example, mine personally the code on MFC always was a candy... Programming on MFC, developer AG> is always connected to superfluous (technical) entities which  would be possible to carry out from the application-oriented code. AG> even simple dialogue application (without Doc/View), abounds unnecessary in 99 % of situations with entities. AG> so, calls DDX_Control (...) Abounding in DoDataExchange - also on  are represented to me superfluous AG> by technical entities. It do not agree. Very strongly it do not agree. AG> c) Transfer of a ready class from old in the new project is for MFC also dancing with a tambourine! AG> if I want to transfer a window (in sense - successor CWnd)  files  (*.h) and a source code (*.cpp) AG> it appears explicitly insufficiently. It is necessary ' to pick out ' both resources, and identifiers of resources and pens AG> to transfer them on a new place. The conflict on identifiers of resources is a separate problem, there is no its desire to concern, AG> will simply mark - that it is and spoils life of the developer (as always at the most inappropriate moment). AG> In Qt, and in VCL, transfer is a simple copying of files then them we register the project - and we would forget about it! Well, resources are a separate subject and actually with MFC or QT it is feeblly connected. But I can tell that these problems are easy enough, because all it becomes mechanically. AG> d) archaic architecture Doc/View (Document/kind) also enters superfluous, absolutely irrelevant essence for the XXI-st century. , arrived... In QT Doc/View enter (in 4.5 it seems) it is progressive, and here - is archaic? The strange logic... Here MDI it is archaic, here it - yes, on 100 %, and it is very bad that this architecture of frames  in most that on is backbone MFC. Here it - really is very bad and . AG> if in 1990, for the text editor it was actual, now is simply superfluous essence on which AG> nevertheless, all library MFC is fastened. This complication which simply should be bypassed in the modern projects - AG> ,  empty document class - is simple for support Doc/View Well... It is not right on 100 %. AG> e) Concept of OOP in MFC any vague. I admit that for 1990 it quite even it was normal. AG> For example - the pattern observer for handling of messages is implemented by macroes BEGIN_MESSAGE_MAP/END_MESSAGE_MAP It not Observer Observer is just Doc/View... And it is implementation of controlers in MVC which everywhere, in all systems die off now as superfluous. Also it is very good, declarative decision. For example, in QT such is not present, more precisely too is, but it there is hidden from the code generally. AG> This decision in style old kind ANSI a C, but in any way in style of the modern C ++ AG> If I in a dialog box (studio means) add new , this new member a class... AG>... With any  it is declared as public - instead of private (or at the worst protected). Yes declare it as you want, it bears.... AG> That fact that the abstract classes in MFC are not interfaces, and contain implementation, also represents AG> retreat from ideas of normal object-oriented design. Well also that,  the architectural decision, anything terrible. Light a wedge on interfaces did not converge. In classes with COM/OLE there on the contrary interfaces . In general, at you , one-sided representation about OOP so, well, it is possible to listen certainly to you on this subject, but it is not interesting. MFC is most that on there is an OOP. Code MFC nevertheless is archaic enough, almost templates and generic programming there are not used, there not  STL, and still it is a lot of that. AG> the Output: application MFC for today makes sense in simple projects where ease is important. AG> choice Qt is obvious to more difficult projects-. AG> For old projects where to it MFC hundred years, also are not present possibilities/finance to pass to something new, application MFC also is actual. Yes is not present, all not so. If programming desktop UI under Windows actually alternatives MFC both were not is necessary, and is not present. It is not dependent on complexity of the project. Business in other, as UI only under Win already very few people wants, and generally Desktop very few people wants. Here in such conditions MFC precisely passes. Does not pull.

14

Re: Thoughts about MFC

Hello, respected MasterZiv, you wrote: MZ> Well then I should participate in a topic Is glad to welcome, respected MasterZiv AG> 1) Legkovesnost. As MFC is rather small object-oriented (however - about it hardly more low) MZ> Well, it is very surprising to hear such, but I understand you. In sense, I would tell as, but many developers not MZ> understand it. For many MFC is a huge and terrible monster. I try to be objective. It is faster small working horsy AG> b) the C Codes ++ projects on Qt are much more readable and are laconic, rather than on MFC. MZ> it do not agree. Very much depends on what project, what code as it is written, etc. MZ> For example, mine personally the code on MFC always was a candy... All the matter is that on MFC is a lot of that superfluous it is necessary to do by hands. An example: ProgressBar or ComboBox in composition ToolBar-a of a head window (for project MFC Feature Pack) - for MFC a heap of any code, additional classes with the redefined virt-methods etc. the Same for Qt - some modest (rather simple) lines of the code. I will note that here it is not necessary to perceive something as insult (I do not run into your code), simply I establish the obvious fact for MFC. Both mine, and yours, and mister Gates the code on MFC, will possess all  that, than any possesses mfts-shnyj the project. AG> programming on MFC, developer AG> is always connected to superfluous (technical) entities which  would be possible to carry out from the application-oriented code. AG> even simple dialogue application (without Doc/View), abounds unnecessary in 99 % of situations with entities. AG> so, calls DDX_Control (...) Abounding in DoDataExchange - also on  are represented to me superfluous AG> by technical entities. MZ> it do not agree. Very strongly it do not agree. To me, analog DoDataExchange for WindowsForms for some reason will not be remembered. Something means all the same in conservatory (in M $) corrected. And in Qt - that is analog DoDataExchange?  it there simply is not present - as it there is not necessary, since there all it "behind a frame" (generated code all automatically, there is carried out in separate files, unlike MFC, where "all in one big heap"). About DoDataExchange and other low-level thingummies: all of them originate in  kind WinAPI. They originate there, even when like as are not present similar global api-shnoj function (absolute analog). Yes, for the end 1990 and the beginnings 2000 it was smart. However, for today it any more so. AG> It is necessary ' to pick out ' both resources, and identifiers of resources and pens AG> to transfer them on a new place. The conflict on identifiers of resources is a separate problem, there is no its desire to concern, AG> will simply mark - that it is and spoils life of the developer (as always at the most inappropriate moment). AG> In Qt, and in VCL, transfer is a simple copying of files then them we register the project - and is forgotten about it! MZ> well, resources are a separate subject and actually with MFC or QT it is feeblly connected. The organization '  ' in Qt cardinally differs from WinAPI - from here  and "feet grow". MZ> But I can tell that these problems are easy enough, because all it becomes mechanically. If in a solution of the order 50 projects, it already turns> d) Archaic architecture Doc/View (Document/kind) also enters superfluous, absolutely irrelevant essence into not sickly hemorrhoids AG for the XXI-st century. MZ> Zdrasti, arrived. . In QT Doc/View enter (in 4.5 it seems) it is progressive, and here - is archaic? MZ> the strange logic... Model/View for Qt is absolutely another, ideology Model/View for Qt is a variant of development, it , in difference from Doc/View for MFC the Example: in MFC Doc/View it is imposed always (for MDI and even for SDI constructions), thus it is not connected with what or a designing pattern - it simply represents an atavism, actual unless for text editors For Qt - Model/View it is a project architectural option (it helps to coordinate change of the data for pattern MVC in the project) - in the most simple case it is possible to manage and without it, creating high-grade (SDI, MDI, dialogue) application with modern GUI. About the document/kind - a question: Why the SAME PEOPLE did not leave this idea in.NET? After all neither in WinForms, nor in WPF this obsession Doc/View it is not watched. In ASP.NET MVC - absolutely other ideas which are much more perspective are accepted and are convenient for the application-oriented programmer, rather than the document/kind in MFC... MZ> Here MDI it is archaic, here it - yes, on 100 %, and it is very bad that this architecture of frames  in most that on is MZ> backbone MFC. Here it - really is very bad and . MDI sometimes allows to solve a problem, and sometimes creates problems. Here all depends on the project. AG> e) concept of OOP in MFC any vague. I admit that for 1990 it quite even it was normal. AG> for example - the pattern observer for handling of messages is implemented by macroes BEGIN_MESSAGE_MAP/END_MESSAGE_MAP MZ> It not Observer Simply one of it (not rather successful) implementations. I will tell so - Observer, but spoiled to the full unrecognizability MZ> Observer is just Doc/View... Well, if to speak with some stretch it can and Observer, but also strange enough. Anyway, this Observer is similar "Demjanovoj an ear" - it impose practically needlessly. AG> that fact that the abstract classes in MFC are not interfaces, and contain implementation, also represents AG> retreat from ideas of normal object-oriented design. MZ> in general, at you , one-sided representation about OOP so, well, it is possible to listen certainly to you on this subject, but MZ> it is not interesting. MFC is most that on there is an OOP. My representation about OOP was generated from the analysis of those decisions that is in modern Java and first of all in.NET. But even in the modern C ++, these decisions already left that is accepted in MFC (left ). MZ> Code MFC nevertheless is archaic enough, almost templates and generic programming, there not  STL there are not used, MZ> and still it is a lot of that. +100500 It seems that MFC appeared before implementation STL - here and an explanation. MZ> yes is not present, all not so. If programming desktop UI under Windows actually alternatives MFC both were not is necessary, and is not present. Well allow to look, what alternatives and of what are: 1).NET: 1.1. WindowsForms; 1.2. WPF; 2) Qt (here as under-variant QML); 3) Java (yes, a little not , but nevertheless). MZ> it is not dependent on complexity of the project. Business in other, as UI only under Win already very few people wants, and generally Desktop very few people wants. In a certain niche - it is a lot of (even much) who wants! MZ> here in such conditions MFC precisely passes. Does not pull. Certainly, document circulation now all on Web (something is on.NET and something on Java). The Lion's share of modern technical desktop projects - on Qt. P.S. For today desktop is and control IoT of systems, both scientific computations, and show business. In general - it is time to our discussion in

15

Re: Thoughts about MFC

Hello, AlexGin, you wrote: AG> To me, analog DoDataExchange for WindowsForms for some reason will not be remembered. Something means all the same in conservatory (in M $) corrected. Well so there the concept another, there published - properties of objects, and objects from the saved images of the objective system are recovered. AG> and in Qt - that is analog DoDataExchange?  it there simply is not present - as it there is not necessary, since there all it "behind a frame" (all AG> automatically generated code, there is carried out in separate files, unlike MFC, where "all in one big heap").ui files there. As a matter of fact too analog of that decision that is made in WinFOrms. Yes, it is carried out from the source code but if it is necessary to correct in large quantities something - more difficult. If you do not want to use wizards and design tools UI - too it is more difficult, though not much more. But as a whole, so on and quits, is both pluses, and minuses. To compare it hardly it is possible, too different decisions. AG> About DoDataExchange and other low-level thingummies: all of them originate in  kind WinAPI. Yes it is fine, well absolutely it is not connected in any way. Absolutely new concept in MFC for communication  WinAPI with  forms and for communication of the data from dialogue dataful in shape on MFC/C ++. Where you there saw roots WinAPI - difficult to understand...  that just is the code, instead of the data though if to abstract, it is possible DDX not to perceive as the code, and to perceive as special declarative DSL,  to describe any aspects of operation of the form. Basically in an ideal it also should be such, purely declarative. MZ>> but I can tell that these problems are easy enough, because all it becomes mechanically. AG> if in a solution of the order 50 projects, it already turns to not sickly hemorrhoids Well you will not alter at once all 50 projects. . On one, AG>> d) Archaic architecture Doc/View (Document/kind) also enters superfluous, absolutely irrelevant essence for the XXI-st century. MZ>> Zdrasti, arrived... In QT Doc/View enter (in 4.5 it seems) it is progressive, and here - is archaic? MZ>> the strange logic... AG> Model/View for Qt is absolutely another, ideology Model/View for Qt is a variant of development, it , in difference from Doc/View for MFC Well-well. With  it absolutely another? It it also is, MVC, Subject/Observer, classics from GoF. Absolutely different implementations and approaches, it yes, in MVC the idea is taken in purer type, in QT the list, the table and the table with hierarchy made a lot of standard  data models. (By the way not so it is pleasant to me, it is clumsily enough made, pure Subject/Observer is not present generally). AG> the Example: in MFC Doc/View it is imposed always (for MDI and even for SDI to a construction), No, it is not imposed it always, is Dialog based applications. Well, it it is a little stronger than it is necessary it is built in kernel MFC, it yes, and I about it already wrote. Including unfortunate MDI. AG> thus it is not connected with what or a designing pattern - it AG> simply represents an atavism, actual unless for text editors AG> For Qt - Model/View it is a project architectural option (it helps to coordinate change of the data for pattern MVC in the project) - AG> in the most simple case it is possible to manage and without it, creating high-grade (SDI, MDI, dialogue) application with modern GUI. I once again speak, at you the strange logic. The same decision, the same pattern to you in one case is pleasant, accepted to an innovation, in other case it seems archaic and wrong. And this with the fact that in MFC Doc/View was from the very beginning, with 90, and in QT appeared only in 21 century because well it is visible developers all already rubbed the nose of them in a shit and swore, and where at you Doc/View or MVC. AG> About the document/kind - a question: Why the SAME PEOPLE did not leave this idea in.NET? AG> After all neither in WinForms, nor in WPF this obsession Doc/View it is not watched. AG> in ASP.NET MVC - absolutely other ideas which are much more perspective are accepted and are convenient for the application-oriented programmer, rather than the document/kind in MFC... MFC and WinForms have been made for the different purposes. MFC - for creation Word and Excel, WInFOrms - on changeover VisualBasic, for creation of the corporate applications consisting in the core from such concepts UI, as "form". Well, are not necessary there Doc/View. (For the same - to kill VisualBasic - formed and Delphi which author of idea did and WinFOrms). AG> Well if to speak with some stretch it can and Observer, but also strange enough. Without stretches, it it also is. AG> My representation about OOP was generated from the analysis of those decisions that is in modern Java and first of all in.NET. AG> But even in the modern C ++, these decisions already left that is accepted in MFC (left ). Who to you told, what.net is exemplary OOP? Who to you told, what the modern C ++ is an OOP (only OOP)? AG> It seems that MFC appeared before implementation STL - here and an explanation. It appeared long before even till the moment of appearance of thought about STL. AG> in general - it is time to our discussion in

16

Re: Thoughts about MFC

Hello, AlexGin, you wrote: AG> d) Archaic architecture Doc/View (Document/kind) also enters superfluous, absolutely irrelevant essence for the XXI-st century. AG> if in 1990, for the text editor it was actual, now is simply superfluous essence on which AG> nevertheless, all library MFC is fastened. This complication which simply should be bypassed in the modern projects - AG> ,  empty document class - is simple for support Doc/View Here I will disagree.  the wizard both in 6.0, and in the modern studios allowed to refuse from Doc/View. Thus document class did not form generally, and instead of CView it was substituted simply CWnd. It and in MDI worked, and in SDI. The unique feature known to me rigidly fastened on Doc/View, is press print preview (which CPreviewView, it seems). If it to use, yes, only  documents, dock-templejty and . I in Doc/View from MFC pound I do not see much. There all too  on files and is difficult under the task . It was always easier to me Model/View to stir up.

17

Re: Thoughts about MFC

Hello, qaz77, you wrote: Q> Hello, AlexGin, you wrote: AG> d) Archaic architecture Doc/View (the Document/kind) AG> This complication which simply should be bypassed in the modern projects - AG> ,  empty document class - is simple for support Doc/View Q> Here I will disagree. Q> App the wizard both in 6.0, and in the modern studios allowed to refuse from Doc/View. Q> Thus the document class did not form generally, and instead of CView was substituted simply CWnd. Q> It and in MDI worked, and in SDI. How it can really work, if both SDI, and MDI projects in InitInstance create and ' register ' a document template? The example from one of my old projects is more low resulted: redefined method InitInstance: m_pPhoneBookTemplate = new CMultiDocTemplate (IDR_PhoneBookTYPE, RUNTIME_CLASS (CPhoneBookDoc), RUNTIME_CLASS (CChildFrame),//provisionable child frame MDI RUNTIME_CLASS (CPhoneBookView)); if (! m_pPhoneBookTemplate) return FALSE; AddDocTemplate (m_pPhoneBookTemplate); Here such there are templates of documents: CMultiDocTemplate: https://msdn.microsoft.com/en-us/library/58d94y2f.aspx CSingleDocTemplate: https://msdn.microsoft.com/en-us/library/7yha6tek.aspx Each of them defines a dial-up: the document/okno_ramki/kind for everyone child MDI (or for only thing SDI) windows. This mechanism is built in kernel MFC, therefore it to bypass, alas, not so simply (once I experimented it). In a reality - to leave '  ' (empty) document class easier,  to try to bypass fundamental architecture Doc/View Q> the Unique feature known to me rigidly fastened on Doc/View, it is press print preview (which CPreviewView, it seems). Q> If it to use, yes, only  documents, dock-templejty and . Yes, it is one of the features fastened on Doc/View. Still an interesting feature: virtual BOOL SaveModified (); redefining this method, we can replace the message that the user forgot to save the document. Another matter that all these features do not stand those complications and restrictions that Doc/View Q> I in addition import in Doc/View from MFC I pound I do not see much. +100500 yes for this reason the given architecture also was not saved, at least in such type as in MFC, for modern . Q> There all too  on files and is difficult under the task . Q> it was always easier To me Model/View to stir up. Exactly! At me just the same problem.  all the same, it is required to develop the business logic (including the implementation of "document"), therefore Doc/View from MFC and is lost by meaning.

18

Re: Thoughts about MFC

Hello, AlexGin, you wrote: AG> As it can really work, if both SDI, and MDI projects in InitInstance create and ' register ' a document template? Well here works - and all. Now near at hand MSVC 2013, we do New project-> MFC-> MFC Application. In the same place, where it is selected MDI/SDI/Dialog based, there is an option "Document/View architecture support". If a tick it is removed, no templates of documents and so forth are generated, in InitInstance, somewhere else. ChildView becomes simply successor CWnd. AG> still an interesting feature: AG> AG> virtual BOOL SaveModified (); AG> AG> redefining this method, we can replace the message that the user forgot to save the document. "To save the document" is the same files gives. And if at us the DB or simply on the fly somewhere is written? Besides there is a simple alternative - return from OnClose windows-frameworks to a call of parent implementation.

19

Re: Thoughts about MFC

Hello, Evgeniy Skvortsov, you wrote: ES> To pluses MFC still it is possible to add a heap of wizards for VS which allow without manual  quickly and conveniently enough to add new methods, event handlers, to redefine the virtual functions. Unfortunately, in the modern versions of studio adding something in source codes by means of wizards strongly spoiled. Earlier labels//{{AFX_ were added... For an insertion in strictly led out places. Now such labels are not added, all is molded in the end. With namespace it is never kind normally did not work. Determinations of functions-members were molded behind a closing parenthesis namespace and it was necessary to transfer hands. It is the extremely inconvenient to add files (wizard Add class) if the project file lies not in a root of a folder with source codes. Files always strive to form near to a project file. For rumpling it it is actual, since with the same name.vcproj under different versions of studio lie in . It is Not a lot of not in a subject. Became painful about the editor of resources. Editing of the table of lines in new studios it is simple a song. In VC6 was quite convenient. Import of a resource from a file, for example icons, adds in the project "res/my_icon.ico" and "./res/my_icon.ico". An output such. In MSVC 6.0 class a wizard and the editor of resources worked quite tolerably and its usage could accelerate development. Then MS all spoiled and now more forces leaves on struggle against consequences. As a result now in 2013 studios a class a wizard I do not use generally.

20

Re: Thoughts about MFC

Hello, qaz77, you wrote: Q> In MSVC 6.0 class a wizard and the editor of resources worked quite tolerably and its usage could accelerate development. Q> then MS all spoiled and now more forces leaves on struggle against consequences. Q> as a result now in 2013 studios a class a wizard I do not use generally. MSVC 6.0 generally was the best version of studio. Since following (2000 +) it rewrote on , and all spoiled (IMHO).

21

Re: Thoughts about MFC

Hello, MasterZiv, you wrote: MZ> MSVC 6.0 generally was the best version of studio. Since following (2000 +) it rewrote on , MZ> and all spoiled (IMHO). +100500 It seems that those years, when was not.NET (was not neither WinForms, nor WPF), manual M $ saw MFC as the main tool for development desktop applications. However, from the middle 2000 situation changed: this library ceased (almost completely) to develop, the studio (is more exact - its author M $) concerned to MFC as ' the malicious stepmother ' P.S. Once again I want to underline: I am not going to conduct here discussion in style  - type there are only the correct and WRONG bagatelles Are not present, I want here on the contrary - to state my point of view and to help to understand in essence to colleagues (and in something even to me) with merits and demerits inherent modern MFC! P.P.S. If this subject can open to me and other old residents of forum MFC something new it will be possible to tell safely that - our diligence did not disappear for in vain!!!

22

Re: Thoughts about MFC

Hello, qaz77, you wrote: Q> Well here works - and all. Q> now near at hand MSVC 2013, we do New project-> MFC-> MFC Application. Q> In the same place where it is selected MDI/SDI/Dialog based, there is an option "Document/View architecture support". Q> If a tick it is removed, no templates of documents and so forth are generated, in InitInstance, somewhere else. Q> ChildView becomes simply successor CWnd. By the way, yes! Even works! Checked up on MSVC 2015 (CE Update 3) - surprising nearby! It is possible not ' to drag ' behind itself "document" Unfortunately, it does not cancel some overhead on the codes: so are generated CMainFrame (successor CMDIFrameWndEx), and CChildFrame (successor CMDIChildWndEx), some actions of technical character with these (the superfluous also become???) entities. But it quite in style of the technologies accepted in 1990, then it was in a trend. However, nevertheless, it is already pleasant step forward for the programmer

23

Re: Thoughts about MFC

Hello, AlexGin, you wrote: AG> However, nevertheless, it is already pleasant step forward for the programmer It not a step forward, and it is simple this possibility yet did not break. Now was not too lazy, launched MSVC 6.0 under  XP. There in  a wizard the option "Document/View architecture support" is present.

24

Re: Thoughts about MFC

Hello, MasterZiv, you wrote: AG> If in a solution of the order 50 projects, it already turns to not sickly hemorrhoids MZ> Well you will not alter at once all 50 projects... If at me is  with 50th projects, and here in one of them I should add a dialogue window - besides such, what I  some years ago in absolutely other project ExternalProject (well or found it on codeguru/codeproject). It would Seem - simply copy dialogue files in the project and register in project files... Here all dancing with tambourines also begins: I. The first round - to pull out from file ExternalProject.rc all resources necessary to me and to transfer to a file *.rc the demanded project in mine  a solution It - only the first part of manual laborious operation. II. Identifiers are a second part. Here it is necessary to track, that ID from this ' new ' for mine  a window solution it was not intersected with the existing. If it will be intersected, probably two variants: 1) UB with all delights (glitches, embarkations etc.); 2) all transits normally and not terribly for application operation. I will note that in  resources there are some categories: #define _APS_NEXT_RESOURCE_VALUE 224 #define _APS_NEXT_COMMAND_VALUE 32901 #define _APS_NEXT_CONTROL_VALUE 1150 #define _APS_NEXT_SYMED_VALUE 101  here it is important that on all these categories it was intersected nothing. And all identifiers, in all it is necessary to compare 50 projects with ' new ' a window... In Qt - sm above: simply copy dialogue files in the project and register in project files...... And any dancings, also the tambourine is not necessary...

25

Re: Thoughts about MFC

Hello, AlexGin, you wrote: AG> 1) UB with all delights (glitches, embarkations etc.); AG> 2) all transits normally and not terribly for application operation. AG> I will note that in  resources there are some categories: AG> AG>#define _APS_NEXT_RESOURCE_VALUE 224 AG>#define _APS_NEXT_COMMAND_VALUE 32901 AG>#define _APS_NEXT_CONTROL_VALUE 1150 AG>#define _APS_NEXT_SYMED_VALUE 101 AG> AG>  here it is important that on all these categories it was intersected nothing. AG> and all identifiers, in all 50 projects should be compared with ' new ' a window... In antecedents it dared through RiverBlade ResOrg And generally I heard () that the foreheads, responsible for operation with Resources in a Visual Studio in the childhood saved life to Bill Gates, therefore to dismiss or somehow to punish it it is impossible