26

Re: Thoughts about MFC

Hello, AlexGin, you wrote: AG> Yes as though ID  as a part of this window it was not intersected... AG> If it will be intersected, probably two variants: 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 CONTROL_VALUE it was intersected nothing. ID  should be unique only within a parent window. If there are two dialogues ID them  can be intersected without consequences. I, for example, use simple names of type IDC_NAME, IDC_COMMENT in different windows. The preinstalled identifiers do not cause conflicts: IDOK, IDCANCEL. Than  is worse? Even in more difficult cases (child dialog, property page) with duplication ID there are no problems. We admit at me there is a template child dialogue in 2-mja editors and the button: IDC_ZEDIT1, IDC_ZEDIT2, IDC_ZBUTTON. We interpose some copies of such child dialogue in popup dialogue, all will work apprx. I see only one possibility of the conflict. When one of recently acquired IDC_... Already is in resource.h with other value. As you new IDC_... In resource.h you add? I would interpose the unit into the end launched compilation. If the compiler starts to shout about macro redefinition, only then to start to worry...

27

Re: Thoughts about MFC

Hello, qaz77, you wrote: Q> I see only one possibility of the conflict. When one of recently acquired IDC_... Already is in resource.h with other value. Q> as you new IDC_... In resource.h you add? Manually - I try to pick up number which is not present. Yes, I interpose into the end resource.h, however, if in other project of a solution there are values already equal to it in its file resource.h? Then I search, I adjust ID new  - that there were no conflicts. Q> I would interpose the unit into the end launched compilation. Similarly, I interpose into the end.

28

Re: Thoughts about MFC

Hello, qaz77, you wrote: Q> There in  a wizard the option "Document/View architecture support" is present. Yes it there from time immemorial is present. On my storage from the Visual C version ++ 1.5 (Yes here such I old). Document/View it is supported at level MFC, and DI (CreateMDIWindow ()) "" in Windows at level API. This that gray window, is more exact area MDI Main Window on which "are grazed" MDIChild. And MFC Feature Pack is the library bought from Petersburg firm BCG  over normal MFC, earlier was called BCGControlBar. I BCGControlBar know this since those times when it on codeproject free was. Then I on it densely sat down, therefore as from similar MFC "extensions" is there was at that point in time the most acceptable that I then saw. It seems that was not mistaken. Those who well knows BCGControlBar, in MFC Feature Pack understand without the problems, there almost all titles of classes remained former, simply replaced CBCG **** on CMFC ****. On BCG I simple changeover of class names translated the projects on MFC Feature Pack (well almost).

29

Re: Thoughts about MFC

Hello, AlexGin, you wrote: AG> Then I search, I adjust ID new  - that there were no conflicts. For a Visual Studio 6.0 at me  has been written, which allowed to renumber the selected lines from number which was at the first selected line.

30

Re: Thoughts about MFC

Hello, Nikolaz, you wrote: N> Hello, qaz77, you wrote: N> Document/View it is supported at level MFC, and DI (CreateMDIWindow ()) "" in Windows at level API. N> This that gray window, is more exact area MDI Main Window on which "are grazed" MDIChild. +100500 N> And MFC Feature Pack is the library bought from Petersburg firm BCG  over normal MFC, earlier was called BCGControlBar. Exactly! I remember I was engaged with BCGControlBar on projects of very old operation still in 2001 N> this BCGControlBar I know since those times when it on codeproject free was. Then I on it densely sat down, therefore as from similar MFC "extensions" is there was at that point in time the most acceptable that I then saw. It seems that was not mistaken. This development outstripped the time - years on five if it is no more. N> Those who well knows BCGControlBar, in MFC Feature Pack understand without the problems, there almost all titles of classes remained former, simply replaced CBCG **** on CMFC ****. On BCG I simple changeover of class names translated the projects on MFC Feature Pack (well almost). Yes, there small distinctions were, but in general it was possible so to do quite.

31

Re: Thoughts about MFC

Hello, AlexGin, you wrote about MFC. Also I will disagree on Document/View. In my opinion, you simply did not learn them well to prepare or use not there where they are required. For creation of various editors it is simple that the doctor registered. And if something is required another forms Dialog Based and there you are free to do all that wants. I would tell differently - standard means MFC "from a box" do not encourage some approaches, however do not forbid them. For example, nobody hinders to create multiwindow application generally without a mention of documents and types. Implement the simplified frames, the blessing, source codes standard MS delivers.

32

Re: Thoughts about MFC

Hello, respected Went, you wrote: W> Also I will disagree on Document/View. In my opinion, you simply did not learn them well to prepare or use not there where they are required. For creation of various editors it is simple that the doctor registered. Yes, it so. To write the editor of the text/pictures/videos - it is ideal on MFC. But, for example, for SCADA systems, it is not so actual. We had development SCADA on MFC. It turned out in general not bad (even it konkurento-is suitable), but very many in library MFC it appeared simply excessive. W> and if something is required another forms Dialog Based and there you are free to do all that wants. I would tell differently - standard means MFC "from a box" do not encourage some approaches, however do not forbid them. Dialog Based it is good. But only for rather not the big utilities. I in course that Dialog Based can have both Menu, and ToolBar, and StatusBar (all in one). Thus the dialog box can be partitioned by splitters. The modern design GUI turns out in general. There was at us such project about five years ago (telef-book). However, all decent modern applications it is normal MDI + Dockable (in respect of GUI). The data storage organization - on MS a SQL Server or on ORACLE the server. Here from these positions also it turns out that MFC actually ' remained ' at the rate of about 10... 15 summer prescription W> For example, hinder nobody to create multiwindow application generally without a mention of documents and types. Implement the simplified frames, the blessing, source codes standard MS delivers. Unfortunately, here already IMHO for MFC "the train left" More precisely - remains only, perhaps, Dialog Based as the variant with a minimum overhead projector remaining on a C ++ needs to be developed All using Qt.

33

Re: Thoughts about MFC

Hello, AlexGin, you wrote: AG>... WTL - is even more superficial, is even closer to WinAPI

34

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 At me was such: a Visual C ++ and MFC Like quite good but to compare there is nothing, others were not)) Pluses: cheap also it is possible to download in pdf.

35

Re: Thoughts about MFC

Hello, savitar, you wrote: S> Hello, AlexGin, you wrote: AG>>... S> WTL - is even more superficial, is even closer to WinAPI Yes, but here to be torn through it ' a jungle ' even more  P.S. On a court yard of 2017 - on computers (even old) the programs developed on.NET and Java fly! We, apologists of a C ++, risk today - in a pursuit for , we can quite turn to "machine slaves" we Can optimize that AT ALL does not demand any optimization... Well actually - what difference: update of a head window transits for 0.3 sec or for 0.5 sec - if, for example, the period of this update 5 sec???

36

Re: Thoughts about MFC

Hello, AlexGin, you wrote: S>> WTL - is even more superficial, is even closer to WinAPI AG> Yes, but here to be torn through it ' a jungle ' even more  by Imho, is not present in WTL any jungle, there the main thing its concept to understand. Here on  there are two excellent articles on giblets WTL, I on them and understood. Absolutely thin superstructure over WINAPI, perfectly approaches for writing of small applications with not so difficult interface. Besides initially it supported all versions  and mobile system of those years (whether as there it was called Windows CE that) Now it is all is irrelevant, but if it is necessary to write any small  that it is quite possible to use, for  on bare  same a pure hell. Plus it in the core for GUI is intended, there remaining classes that practically and are not present.

37

Re: Thoughts about MFC

Hello, AlexGin, you wrote: AG> But, for example, for SCADA systems, it is not so actual. AG> we had development SCADA on MFC. It turned out in general not bad (even it konkurento-is suitable), but very many in library MFC it appeared simply excessive. I would not tell that redundancy of library for some class of tasks does its bad. The main problem MFC (if not to take its irrelevant state), is excessive " nails" to some concepts. For example, the document is rigidly fastened that it will be stored in a file. When it is necessary to make some "abstract" document, "snivels" begin. The frame is fastened on storing "type", which is fastened on displaying "document". All can be bypassed it, but manages not so beautifully. AG> however, all decent modern applications it is normal MDI + Dockable (in respect of GUI). At me on MFC such application, flight normal. Looks it is modern enough. And panels , and ribbon, and the manager of properties. Life is spoiled only by some "dampness" Feature Pack. AG> is more exact - remains only, perhaps, Dialog Based as a variant with a minimum overhead projector I Will disagree. Item 1 sm. - applications-editors are written on MFC conveniently enough. AG> All remaining on a C ++ need to be developed using Qt. Well what for to me QT for development windows-vs-only the editor?

38

Re: Thoughts about MFC

Hello, Went, you wrote: W> I would not tell that redundancy of library for some class of tasks does its bad. The main problem MFC (if not to take its irrelevant state), is excessive " nails" to some concepts. For example, the document is rigidly fastened that it will be stored in a file. When it is necessary to make some "abstract" document, "snivels" begin. The frame is fastened on storing "type", which is fastened on displaying "document". All can be bypassed it, but manages not so beautifully. +100500 it about what there was a speech in initiating my message. Absence of flexibility, at redundancy is that it is possible to name as " nails" to some concepts AG>> However, all decent modern applications is normal MDI + Dockable (in respect of GUI). W> At me on MFC such application, flight normal. Looks it is modern enough. And panels , and ribbon, and the manager of properties. Life is spoiled only by some "dampness" Feature Pack. I also have applications such, with MDI + Dockable with application MFC Feature Pack (earlier known as BCG Library). A question after all at all in it. After all nobody states here that it is not possible However, anybody and is not going to argue, about that that all aforesaid in MFC + (MFC Feature Pack) becomes with the big overhead projector. This overhead projector takes place at level of the codes of the project, instead of at level any additional (technical, autogenerated) files. AG>> is more exact - remains only, perhaps, Dialog Based as a variant with the minimum overhead projector W> I Will disagree. Item 1 sm. - applications-editors are written on MFC conveniently enough. What urgency of the next bicycle of the editor in 2017? Certainly, when MFC appeared, the similar urgency was considerably above. AG>> All remaining on a C ++ need to be developed using Qt. W> Well what for to me QT for development windows-vs-only the editor? Here that's just the point that at level of the codes of the project, even the same editor (for example texts) made on Qt, appears more compact and readable, than its colleague from MFC. Yes, in Qt there will be automatically generated files, but complexities of the project it DOES NOT ADD, as it is separate technical essence which "lives" not in the project codes. To the application programmer this essence does not complicate life, for it it generally practically is not noticeable (it exists somewhere "behind a frame"). P.S. At all I do not want to belittle significance MFC in world IT! By means of MFC good projects are made many. To some of them, I had honor to put brains and hands However, for today MFC does not look such innovative as it was approximately 15 years ago

39

Re: Thoughts about MFC

Hello, AlexGin, you wrote: AG> However, for today MFC does not look such innovative as it approximately was unambiguous 15 years ago. It looks simply archaic, and with Feature Pack - also gljuchno-crude. Dances with MBS vs UNICODE generally touch. But for operation the MFC-like library, thin is necessary to me, transparent, , integrated that "a bang-bang, and in studio all twirled, and on other platforms to spit".

40

Re: Thoughts about MFC

Hello, AlexGin, you wrote: AG> However, for today MFC does not look such innovative as it was approximately 15 years ago It and 15 years ago was not innovative and fresh, now and for a long time. Fresh and innovative was  OWL, in the fourth and fifth studio on MFC without tears it was impossible to look. OWL was born on a rake and jambs  so experience graphic  already was. MS simply rewrote OWL, throwing out in passing poor  container classes, replacing with their, the Table of responses called the Card of events and received the first MFC. If to look, all structures of classes in the first MFC in accuracy repeated structures of just the same classes OWL. Unique advantage MFC, is long support and more and less constant program interface, old and not the greatest projects still somehow it is possible  at new studios whereas Borland hardly moved down from 16 bits and finished the life in VCL

41

Re: Thoughts about MFC

Hello, peterbes, you wrote: P> Hello, AlexGin, you wrote: AG>> However, for today MFC does not look such innovative as it was approximately 15 years ago P> It and 15 years ago was not innovative and fresh, now and for a long time. P> Fresh and innovative was  OWL, in the fourth and fifth studio on MFC without tears it was impossible to look. P> OWL was born on a rake and jambs  so experience graphic  already was. MS simply rewrote OWL, throwing out in passing poor  container classes, replacing with their, the Table of responses called the Card of events and received the first MFC. If to look, all structures of classes in the first MFC in accuracy repeated structures of just the same classes OWL. P> Unique advantage MFC, is long support and more and less constant program interface, old and not the greatest projects still somehow it is possible  at new studios whereas Borland hardly moved down from 16 bits and finished the life in VCL that that with history at you badly From English Wikipedia In the early 1990s, Borland dominated the a C ++ market. In 1991, Borland introduced a Borland C ++ 3.0 which included OWL 1.0. At that time, a C ++ was just beginning to replace a C for development of commercial software, driven by the rising of the Windows platform. During this period, OWL was a popular choice for Windows application development In 1992, Microsoft introduced MFC as part of C/C Microsoft ++ 7.0. As a similar a C ++ application framework for Windows, MFC immediately became OWL's primary competitor in the a C ++ application development market. OWL 1.0 depended on Dynamic Dispatch Virtual Tables (DDVT), a proprietary extension to a C ++ that allowed the programmer to bind Windows messages (events) to functions (event handlers) in a simple manner and with little run-time overhead. MFC, on the other hand, used a solution that did not require a language extension. In 1993, Borland launched a Borland C ++ 2.0 which included OWL 2.0. In this version of OWL, the proprietary DDVT extension was replaced by response tables, a macro-based solution compatible with standard a C ++ and similar to MFC in use. A conversion tool (OWLCVT) was included to migrate code from OWL 1.0 to OWL 2.0. OWL 1 on each new class-window Windows created the new table of the virtual functions, with an amount of functions big, than events in Windows. It guzzled storage as not in itself, but after all it very much on With ++   created for a new class-window there was the small card of events added to a basic card. In  event handlers - not the virtual functions. In  2 (appeared __  1) the virtual functions refused also Borland, making something on motives of macroes . Then generally licensed  for delivery.