How to - SDI
in [MFC]
|
Prev: Recommendation needed for embedded scripting solution
Next: Error C2440 cannot convert from void
From: Hector Santos on 21 Jan 2010 03:22 Why would a teacher restrict the mindset of students with such a highly subjective opinion, which is highly isolated to one own experiences and to many, not really true in the market place? There are untold thousands of SDI applications. Its unconceivable to even notice that it might even be a rarity. Its not. SDI has its place as well as MDI and they offer two different set of design needs. We use a MDI for our embedded p-code language/compiler IDE. We use SDI for monitors, configuration tools, etc. This isn't an oddity or exception. Very odd statement. -- Joseph M. Newcomer wrote: > The only time I have ever built an SDI app is when I teach the MFC course and one of the > exercises is an SDI app. I tell my students that SDI apps are exceptionally rare, usually > useless, and inevitably the client will decide that what was really wanted was MDI, so the > simplest solution is to always start with MDI. > joe > > On Wed, 20 Jan 2010 13:14:03 -0800, "Tom Serface" <tom(a)camaswood.com> wrote: > >> I see many have responded to your question, but I wanted to just put in that >> I always build new applications as MDI even if I only plan to have one >> document and/or one view. It's simple to change the menus and make the >> child window fill out the whole mainframe and then if you ever want to >> convert in the future (which you likely will) you can easily add the new >> functionality. >> >> That's the same reason I never use dialog applications. It is just as easy >> to create a formview based MDI app and build from that. >> >> Tom >> >> "rockdale" <rockdale.green(a)gmail.com> wrote in message >> news:9f08bb0a-ec24-4b33-bea4-2a35be301c99(a)a32g2000yqm.googlegroups.com... >>> Hi, all: >>> >>> All my experience on MFC is dialog based application. And now I try to >>> learn the SDI and MDI based application. I create a sample SDI >>> application, but then I have no idea what is the next step I need to >>> do. Like if I want use can enter some data in a CEdit control, how >>> should I do that. Do I need to create a CDialog and then load it into >>> the main frame, how to load a CDialog/CView into a main frame, all the >>> examples on the internet are showing an empty childview, how can I >>> make the childview doing something? >>> >>> Thanks in advance. >>> -Rockdale > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm -- HLS
From: Tom Serface on 21 Jan 2010 10:17 I can't speak for Joe or his teaching style, but for me it's just espousing an opinion. I would never tell anyone 'not' to do it or that it was illegal, just that I think building apps the other way is a better idea. I had a few bad SDI experiences years ago. That said, my favorite applications are those like the Office apps where they are really tied together, but each doc appears in a separate mainframe so looks like it's on SDI. Tom "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:uh38XLnmKHA.1212(a)TK2MSFTNGP04.phx.gbl... > Why would a teacher restrict the mindset of students with such a highly > subjective opinion, which is highly isolated to one own experiences and to > many, not really true in the market place? There are untold thousands of > SDI applications. Its unconceivable to even notice that it might even be a > rarity. Its not. SDI has its place as well as MDI and they offer two > different set of design needs. We use a MDI for our embedded p-code > language/compiler IDE. We use SDI for monitors, configuration tools, etc. > This isn't an oddity or exception. > > Very odd statement. > > -- > > Joseph M. Newcomer wrote: > >> The only time I have ever built an SDI app is when I teach the MFC course >> and one of the >> exercises is an SDI app. I tell my students that SDI apps are >> exceptionally rare, usually >> useless, and inevitably the client will decide that what was really >> wanted was MDI, so the >> simplest solution is to always start with MDI. >> joe >> >> On Wed, 20 Jan 2010 13:14:03 -0800, "Tom Serface" <tom(a)camaswood.com> >> wrote: >> >>> I see many have responded to your question, but I wanted to just put in >>> that I always build new applications as MDI even if I only plan to have >>> one document and/or one view. It's simple to change the menus and make >>> the child window fill out the whole mainframe and then if you ever want >>> to convert in the future (which you likely will) you can easily add the >>> new functionality. >>> >>> That's the same reason I never use dialog applications. It is just as >>> easy to create a formview based MDI app and build from that. >>> >>> Tom >>> >>> "rockdale" <rockdale.green(a)gmail.com> wrote in message >>> news:9f08bb0a-ec24-4b33-bea4-2a35be301c99(a)a32g2000yqm.googlegroups.com... >>>> Hi, all: >>>> >>>> All my experience on MFC is dialog based application. And now I try to >>>> learn the SDI and MDI based application. I create a sample SDI >>>> application, but then I have no idea what is the next step I need to >>>> do. Like if I want use can enter some data in a CEdit control, how >>>> should I do that. Do I need to create a CDialog and then load it into >>>> the main frame, how to load a CDialog/CView into a main frame, all the >>>> examples on the internet are showing an empty childview, how can I >>>> make the childview doing something? >>>> >>>> Thanks in advance. >>>> -Rockdale >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm > > > > -- > HLS
From: Joseph M. Newcomer on 21 Jan 2010 11:04 Perhaps because the students have zero years of experience and the teacher has 15 years experience dealing with the reality of MFC applications? Maybe what I do for a living carries some weight for people who have never done it? I have yet to find a situation in which someone asked for an SDI app and did NOT change their mind and want MDI. Sometimes they come to me and say "We started this as an SDI app, now we want MDI, can you fix it for us? The guy who did it is long gone." In the first few years, I got good at this conversion, because they always asked for SDI but ended up wanting MDI. And "untold thousands" does not suggest that those apps always make sense. I once bought an app that was SDI, while its predecessor had been a DOS version of an MDI app...seriously, I could have multiple files open in the MS-DOS version. In the Windows version, only one, and the "clipboard" still used the "internal" mechanism from the MS-DOS version so I could not copy objects from one file into another file! Or, to use another quote I am fond of "Just because it is possible doesn't mean it makes sense". My job is to teach people the reality of building apps, not some hypothetical model that someone at Microsoft thought of in the early 1990s. Reality for me has consistently been that anyone who asks for SDI does so out of ignorance. As soon as they see the product, or as soon as their customers see it, they want MDI. You sound like a very special case. The embedded compiler system I did over ten years ago was required by the client to be MDI (they got that part right). Since it cost nothing to make it MDI instead of SDI, it was the obvious choice. joe On Thu, 21 Jan 2010 03:22:16 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >Why would a teacher restrict the mindset of students with such a >highly subjective opinion, which is highly isolated to one own >experiences and to many, not really true in the market place? There >are untold thousands of SDI applications. Its unconceivable to even >notice that it might even be a rarity. Its not. SDI has its place as >well as MDI and they offer two different set of design needs. We use >a MDI for our embedded p-code language/compiler IDE. We use SDI for >monitors, configuration tools, etc. This isn't an oddity or exception. > >Very odd statement. > >-- > >Joseph M. Newcomer wrote: > >> The only time I have ever built an SDI app is when I teach the MFC course and one of the >> exercises is an SDI app. I tell my students that SDI apps are exceptionally rare, usually >> useless, and inevitably the client will decide that what was really wanted was MDI, so the >> simplest solution is to always start with MDI. >> joe >> >> On Wed, 20 Jan 2010 13:14:03 -0800, "Tom Serface" <tom(a)camaswood.com> wrote: >> >>> I see many have responded to your question, but I wanted to just put in that >>> I always build new applications as MDI even if I only plan to have one >>> document and/or one view. It's simple to change the menus and make the >>> child window fill out the whole mainframe and then if you ever want to >>> convert in the future (which you likely will) you can easily add the new >>> functionality. >>> >>> That's the same reason I never use dialog applications. It is just as easy >>> to create a formview based MDI app and build from that. >>> >>> Tom >>> >>> "rockdale" <rockdale.green(a)gmail.com> wrote in message >>> news:9f08bb0a-ec24-4b33-bea4-2a35be301c99(a)a32g2000yqm.googlegroups.com... >>>> Hi, all: >>>> >>>> All my experience on MFC is dialog based application. And now I try to >>>> learn the SDI and MDI based application. I create a sample SDI >>>> application, but then I have no idea what is the next step I need to >>>> do. Like if I want use can enter some data in a CEdit control, how >>>> should I do that. Do I need to create a CDialog and then load it into >>>> the main frame, how to load a CDialog/CView into a main frame, all the >>>> examples on the internet are showing an empty childview, how can I >>>> make the childview doing something? >>>> >>>> Thanks in advance. >>>> -Rockdale >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 21 Jan 2010 11:17 One of the interesting issues that arose when I did the Win32 book was someone who emailed me and said "There are too many opinions in this book. Opinions have no place in a technical reference manual". My response was "The only value-added is the opinions. If you want the facts, read the MSDN documentation. If you want to know the reality of practical usage, you have to listen to the people who do this for a living. Our opinions are what make us different from those who have never done it, or the all-the-facts-but-none-of-the-truth documentation". As an educator, it is my *responsibility* to help mold the mindset of students. Otherwise, we get the kinds of programs where everything is extern, all methods are public, every module does a #include of every other header file, casts on AfxGetApp() appear everywhere, and pretty soon somebody posts a question of the form "I want to refactor my application into an app and a DLL, but the DLL needs to share 400 global variables with the executable. What's the right thing to do?" and my opinion is "you have 400 too many global variables. Get rid of all of them, rewrite the app so it looks like it was coded by someone who understood how to design software, and THEN refactor it!" What happened was some previous instructor taught his students what was *possible*, not what made sense. He never attempted to restrict their mindset to what was sensible. He had no opinions, quite possibly because he actually didn't write code for a living, just taught it. At Carnegie Mellon, the professors are practitioners. I was taught by people who wrote compilers and operating systems, and I valued their opinions. When they said "This is wrong", it was reflecting a decade or two more experience than I, and my fellow classmates, had. I've been making a living as a programmer for 45 years, been programming for 46. Along the way, I've learned what works and what doesn't. What is llikely to happen and what is unlikely to happen. I've been doing MFC for 15 years. If I can't pass on what I've learned in that time, I should retire. joe On Thu, 21 Jan 2010 07:17:38 -0800, "Tom Serface" <tom(a)camaswood.com> wrote: >I can't speak for Joe or his teaching style, but for me it's just espousing >an opinion. I would never tell anyone 'not' to do it or that it was >illegal, just that I think building apps the other way is a better idea. I >had a few bad SDI experiences years ago. > >That said, my favorite applications are those like the Office apps where >they are really tied together, but each doc appears in a separate mainframe >so looks like it's on SDI. > >Tom > >"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message >news:uh38XLnmKHA.1212(a)TK2MSFTNGP04.phx.gbl... >> Why would a teacher restrict the mindset of students with such a highly >> subjective opinion, which is highly isolated to one own experiences and to >> many, not really true in the market place? There are untold thousands of >> SDI applications. Its unconceivable to even notice that it might even be a >> rarity. Its not. SDI has its place as well as MDI and they offer two >> different set of design needs. We use a MDI for our embedded p-code >> language/compiler IDE. We use SDI for monitors, configuration tools, etc. >> This isn't an oddity or exception. >> >> Very odd statement. >> >> -- >> >> Joseph M. Newcomer wrote: >> >>> The only time I have ever built an SDI app is when I teach the MFC course >>> and one of the >>> exercises is an SDI app. I tell my students that SDI apps are >>> exceptionally rare, usually >>> useless, and inevitably the client will decide that what was really >>> wanted was MDI, so the >>> simplest solution is to always start with MDI. >>> joe >>> >>> On Wed, 20 Jan 2010 13:14:03 -0800, "Tom Serface" <tom(a)camaswood.com> >>> wrote: >>> >>>> I see many have responded to your question, but I wanted to just put in >>>> that I always build new applications as MDI even if I only plan to have >>>> one document and/or one view. It's simple to change the menus and make >>>> the child window fill out the whole mainframe and then if you ever want >>>> to convert in the future (which you likely will) you can easily add the >>>> new functionality. >>>> >>>> That's the same reason I never use dialog applications. It is just as >>>> easy to create a formview based MDI app and build from that. >>>> >>>> Tom >>>> >>>> "rockdale" <rockdale.green(a)gmail.com> wrote in message >>>> news:9f08bb0a-ec24-4b33-bea4-2a35be301c99(a)a32g2000yqm.googlegroups.com... >>>>> Hi, all: >>>>> >>>>> All my experience on MFC is dialog based application. And now I try to >>>>> learn the SDI and MDI based application. I create a sample SDI >>>>> application, but then I have no idea what is the next step I need to >>>>> do. Like if I want use can enter some data in a CEdit control, how >>>>> should I do that. Do I need to create a CDialog and then load it into >>>>> the main frame, how to load a CDialog/CView into a main frame, all the >>>>> examples on the internet are showing an empty childview, how can I >>>>> make the childview doing something? >>>>> >>>>> Thanks in advance. >>>>> -Rockdale >>> Joseph M. Newcomer [MVP] >>> email: newcomer(a)flounder.com >>> Web: http://www.flounder.com >>> MVP Tips: http://www.flounder.com/mvp_tips.htm >> >> >> >> -- >> HLS Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: David Ching on 21 Jan 2010 14:11
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:n7ugl5lr9n6k3kl6p59bli04uktm2vup5v(a)4ax.com... > Perhaps because the students have zero years of experience and the teacher > has 15 years > experience dealing with the reality of MFC applications? Maybe what I do > for a living > carries some weight for people who have never done it? I have yet to find > a situation in > which someone asked for an SDI app and did NOT change their mind and want > MDI. Sometimes > they come to me and say "We started this as an SDI app, now we want MDI, > can you fix it > for us? The guy who did it is long gone." In the first few years, I got > good at this > conversion, because they always asked for SDI but ended up wanting MDI. > And "untold > thousands" does not suggest that those apps always make sense. I once > bought an app that > was SDI, while its predecessor had been a DOS version of an MDI > app...seriously, I could > have multiple files open in the MS-DOS version. In the Windows version, > only one, and the > "clipboard" still used the "internal" mechanism from the MS-DOS version so > I could not > copy objects from one file into another file! > > Or, to use another quote I am fond of "Just because it is possible doesn't > mean it makes > sense". My job is to teach people the reality of building apps, not some > hypothetical > model that someone at Microsoft thought of in the early 1990s. Reality > for me has > consistently been that anyone who asks for SDI does so out of ignorance. > As soon as they > see the product, or as soon as their customers see it, they want MDI. > Universal use of MDI over SDI is an opinion. Just like avoiding UpdateData(). There may well be reasons to do so, but those reasons are not universal. Myself, I have used both SDI and MDI successfully and would not say one is universally better. The fact that with some shenanigans you can dumb down MDI to look and feel like SDI is certainly a plug to use it, but as I haven't memorized exactly those shenanigans, perhaps I don't want to deal with it when I'm just starting my app, which for the foreseeable future need only be SDI. Indeed, MDI is harder for people to use. Windows are easily lost behind others, etc. Why do you think MS made Office SDI and recommended people stay away from MDI in general? -- David |