How to - SDI
in [MFC]
|
Prev: Recommendation needed for embedded scripting solution
Next: Error C2440 cannot convert from void
From: Joseph M. Newcomer on 22 Jan 2010 16:57 See below... On Thu, 21 Jan 2010 20:37:45 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >Joe, > >Please note I am no way suggesting a lack of well founded experience. > Certainly, you are highly experienced and your shoulders raise above >many. You can't be all bad if you from Pittsburgh. :-) I lived 10 >years in Irwin and worked for Westinghouse for much of those years, >the latter years as an consultant. I had many contacts with CMU, SEI >and the many of the business development, VC (venture capitalist) in >the area. :) > >I'm just saying that as a teacher, I would naturally expect more >openness in ideas, especially in the computer world. There was once >famous Pittsburgh person "Dr. Debug" (CMU Graduate) who was prominent >in the early cyberspace days (which I am an early pioneer in), with a >famous quote: > > "There is no such thing as a bad language, just bad programmers." > >Of course, you can substitute language for anything, and the converse >axiom can also be used." > > "There is no such thing as a bad CUI, just bad CUI programmers." **** Professor Mary Shaw, from CMU, has a famous aphorism: "It is possible to write a bad FORTRAN program in any language" **** > >But then again, it depends on what is your goal. > >For example, a course titled "Applied Software Engineering" may be >different than just "[Principles of] Software Engineering." or maybe >more specific, "Applied CUI" vs "Principles of CUI". **** The course is titled "MFC Programming", and its goal is to teach people who may not know C++ and usually don't know MFC how to quickly become effective programmers. I have five days to teach them the basics of C++ and MFC. Inevitably, there are those who learned how to write bad C code 20 years ago, or were taught bad C progrmaming 10 years ago by people who were bad programmers, and they try to force C++ to look like C. They don't understand those complicated "classes", they have ideas like "I want to change the functionality of this control, but I don't want to create a subclass", they write bad Petzold code in MFC (they write everything as a switch statement by overriding the OnWndMsg or PreTranslateMessage handlers, because "That's how Windows works". It is my JOB to restrict their mindsets! **** > >I guess, the idea about using MDI as a starting point is not an odd >thing, but to add more "color" that isn't necessary simply because it >is will be easy to argue against. SDI is not "exceptionally rare." > >I was also going to add but didn't and I'm happy to read David alluded >to it that once a upon a time, the recommendation was not to do MDI >any more and I seen to recall, that MS realized quickly they had to >continue to support it because people wanted it and it was really >inconceivable that it can be eliminated. **** One of the reasons most of my clients won't use C#, WPF, etc. is that it doesn't support MDI, and therefore does not support what they need to do. It was a design blunder to not continue this important paradigm into the modern world. **** > >Personally, without the help of the smarter IDE holding the hands of >programmers, using MDI in C/C++ was very complex framework to follow >and require a high degree of understanding. Never mind the fact that >it added a higher overhead. **** I always get suspicious when someone says "higher overhead". I have no idea what this means. Sometimes, it means "it executes a few thousand instructions extra while processing a mouse click" as if that statement has any meaning whatsoever. Particularly if you are trying to compare MDI to SDI, where they essentially have the same performance. **** > >I just had to make a comment mostly because I noticed a propensity >from your post lately that many methods that have many years of >precedence is deemed by you as wrong and/or incorrect. The Exports >thread was one of them. I suddenly felt "Am I stupid?" because we use >WINAPI in our prototyping and DEF files for our WIN32 SDK? **** WINAPI is a bad choice, for the reasons I outlined. I see nothing that suggests it was ever a good choice. If you want to use __stdcall, either invent your own macro for your application suite, or use __stdcall directly, but don't use a Microsoft word that means "the standard linking into the kernel" because that means changes in that interface can render your code nonfunctional, because you have based your interface on something subject to change. ..DEF files have their uses, but sometimes they are clumsy. They are not always the first and best choice for exporting symbols these days, and unless you are using features such as export renaming, numeric entry point mapping, and other DEF-file features, they don't represent the ideal selection. **** >both, where it applies, when we want to expose C/C++ classes, then we >use the dllexport/dllimport declarations. When we want to expose pure >pascal based stack proloque/epilogues we used the traditional WIN32 **** You are programming in Delphi? THat's the only thing I know that has a pascal based stack prolog/epilog. In a pascal calling convention, arguments are pushed left-to-right. I'm sure that is not what you intend, so either you are using __cdecl or __stdcall. The word "pascal" as used in WIn16 disappeared from programmers' vocabulary when Win32 was released, and it is a failure of Microsoft to have not removed that obsolete keyword from every header file in existence. Note that in Win16, the "pascal" convention really did push parameters left to right instead of the right-to-left used by __cdecl or __stdcall. It is reasonably important to not tie modern programming to quaint and obsolete, and in fact, irrelevant, concepts like "pascal". **** >WINAPI because that is how WIN32 works and it is the method most >explicit traditional binding is done in the API world. For use, this >important because we have a 250 function WIN32 API/SDK for all the >major languages, including p-code languages: **** You are confusing abstraction and implementation. If you want the implementation of __stdcall, you can either use it explicitly, or create your own macro, but relying on someone else's definition does not seem a good choice. The point is you need to understand what Microsoft owns and what you own. You own the linkages to your library, so using a keyword that Microsoft owns seems inappropriate. joe **** > > C/C++ > Delphi (from 3.0 up) **** Delphi presumably calls external functions using __stdcall, because it would not be safe to assume a C/C++ calling convention for non-Pascal code. But I suspect it does not use WINAPI, it uses __stdcall. This week, in Win32 (only), __stdcall and WINAPI are the same. **** > VB (classic) > Java > PHP > COM > .NET > >We have a mixed world here. I will say, today, if you allow the IDE to >create the initial source code and framework, that it helps in the >area of not needing to pay special attention. However, personally, >over the years, when I want clarity or have issues with multi-language >API imports, by far, using the MS dllimport/dllexport has been more >problematic and generally will revert to the basic methods. **** For multi-language API imports, you have to choose a calling convention supported by all the languages. The last I looked, it was formally __stdcall for Win32. Not WINAPI. **** > >Anyway, as David suggested, its about wisdom and generally, with age >comes wisdom and openness to understand: > > "There is no such thing as bad ideas, just bad implementations." > >SDI and MDI has its place in the CUI arena. > >I don't think you want anyone telling you this. I wouldn't, but I am >also not the type to tell anyone that is good or bad. I might suggest >there an an optimal way to do something, but I am strong believer of >people learning thru trial and error and fault. I guess today, that >is rare and IMHO the "IDE" help contribute to people needed more help >not less because almost inevitably most programmers, some day will >need to understand how things actually work not depend on higher layer >frameworks holding their holds. I will be interested to know the >statistics how many programmers don't use the IDE for development or >don't depend on it or get solve issues when the IDE is not there for >them. :) **** "Good judgment comes from experience. Experience comes from bad judgment" My goal is to help my students AVOID making the mistakes I have seen, and most especially avoid making the mistakes I have made. In my early years of MFC programming, I would propose SDI apps to clients. Or accept their specification of SDI. Inevitably, it became evident that MDI was what was desired. So why should I tell people that SDI is a good idea, when in EVERY case I have created an SDI app, the client ultimately wanted MDI? That clients who had SDI apps came to me and said "convert this to MDI, PLEASE!" When you start seeing patterns like this, it is important to pass this information on. I do not use the VS IDE for editing, because the editor is somewhere out of the Dark Ages, sort of glorified keypunch. I know what a program editor is supposed to do; The VS editor doesn't do it, and can't be made to do what I need. Intellinonsense doesn't work right (gives A or W suffix APIs, not the abstract API), and to use it, I still need to bring up the documentation. So, it is nearly useless nearly all the time for me. I either have the API memorized and don't need it, or I need the COMPLETE documentation on it so I know what flags that UINT or DWORD use, or what should-have-been-enum-but-is-a-#define constant I should use. Sadly, the API isn't even defined wll in C, let alone C++, and I might was well lhave a decent editor. Now, perhaps you are confusing "IDE" with what we thought of as "wizards". Frankly, the view that these are a handicap is nonsensical. They are very important, particularly for beginners, because you can build WORKING code with a minimum of effort, and learn the details at your leisure. Doing it by hand means you have to know EVERYTHING before you can even start, an extremely poor approach to building cost-effective systems. I was delivering MFC solutions for two years before I fully understood command routing. It did the right thing, and I didn't have to care why. The only reason I don't use the wizard-style interfaces was that due to serious design and implementation failures, Microsoft rendered it almost but not quite totally unusable. But by this time, I don't need it, I can simulate it as fast as I can type. But I would not recommend this approach to someone learning MFC. [When Add Variable takes over a minute to bring up a dialog, and along the way, every time I want to add a variable I hear it spin up the disk in my CD-ROM drive, even though the drive does not appear in any path anywhere, I know that someone who was totally clueless did the implementation. An "add variable" dialog that can only add one variable, and takes anything over 100ms to come up, represents a failed design. But it was designed by people who obviously never actually wrote a line of code in their lives, and did not understand workflow of software development. And to the lame excuse that "it's good for C#", it sucks for C#, too] Most people have never seen a decent editor, and don't know what they are missing using the primitive editor we get in VS. **** > >This is all of course, ONE MAN's OPINION :) > >Ciao > > > > >Joseph M. Newcomer wrote: > >> 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 [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 22 Jan 2010 22:52 Joseph M. Newcomer wrote: > It is my JOB to restrict their mindsets! I see!! I see!! You must be a republican! -- HLS
From: Hector Santos on 23 Jan 2010 00:36 Joseph M. Newcomer wrote: > Professor Mary Shaw, from CMU, has a famous aphorism: > > "It is possible to write a bad FORTRAN program in any language" I actually like this one. Mary probably has to deal with many Westinghouse engineers to get grants. :) If Mary dealt with old Mobil Oil Engineers, she could of come up with: "APL programmers really CAN program the world in one line!" Its a JOKE JOEY! > those complicated "classes", they have ideas like "I want to change the functionality of > this control, but I don't want to create a subclass", they write bad Petzold code in MFC Pertzold! Arggggggh, sucker took my DOS TREE program submitted to PC Magazine, got the $50.00, and he rewrote it in ASM for the next month publication! I actually got my behind slapped by Westinghouse chief council for doing this. > **** > One of the reasons most of my clients won't use C#, WPF, etc. is that it > doesn't support MDI, and therefore does not support what they > need to do. It was a design blunder to not continue this > important paradigm into the modern world. +1 from the standpoint of not restricting the mind. > I always get suspicious when someone says "higher overhead". I have no > idea what this means. Then you shouldn't question it against people who do. You do have an idea, you just wish to be argumentative about it. > Sometimes, it means "it executes a few thousand instructions > extra while processing a mouse click" as if that statement has > any meaning whatsoever. Particularly if you are trying to > compare MDI to SDI, where they essentially have the same > performance. It could also mean - programming overhead, - more entry points for failure, - higher learning curve, - pressure points in flexibility, etc, etc, etc. > WINAPI is a bad choice, for the reasons I outlined. "There is no such thing as a bad choice, just bad choosers!" > I see nothing that suggests it was ever a good choice. hmmmm, millions of successful applications in the market place? > If you want to use __stdcall, either invent your own macro for your > application suite, or use __stdcall directly, but don't use a Microsoft word that means > "the standard linking into the kernel" because that means changes in that interface can > render your code nonfunctional, because you have based your interface on something subject > to change. That what is wrong was your IMPLEMENTATION. A good design usually have their own wrappers, like for use, we have WCAPI which provides a pascal based stack calling prologue and epilog conventation > .DEF files have their uses, but sometimes they are clumsy. "There is no such thing as a BAD choice, just bad choosers!" > They are not always the first and best choice for exporting symbols these days, I am going to take a wild guess that you are stuck using an IDE these days. > You are programming in Delphi? I was once a turbo programmer, until delphi 3.0. But I sincerely hope you didn't think that is related to the two basic CPU stack pushing/popping conventions. > THat's the only thing I know that has a pascal based stack > prolog/epilog. No, stdcall is a pascal based stack calling convention!!! You can't change the RULES of the game! > **** >> WINAPI because that is how WIN32 works and it is the method most >> explicit traditional binding is done in the API world. For use, this >> important because we have a 250 function WIN32 API/SDK for all the >> major languages, including p-code languages: > **** > You are confusing abstraction and implementation. If you want the implementation of > __stdcall, you can either use it explicitly, or create your own macro, but relying on > someone else's definition does not seem a good choice. No, people use the STANDARD definition! What other DEFINITION is there? Yours? > The point is you need to understand what Microsoft owns and what > you own. You own the linkages to your library, so using a > keyword that Microsoft owns seems inappropriate. I really really hope people take your advice with a grain of salt. IMO, you create more CONFUSION than not, and it has very little practical implication. It defies logic the comments I read here. To you, you probably wonder why the WORLD got to this point when it was DONE all wrong! -- HLS
From: David Ching on 23 Jan 2010 00:54 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:#dMbF4#mKHA.5692(a)TK2MSFTNGP04.phx.gbl... > I really really hope people take your advice with a grain of salt. IMO, > you create more CONFUSION than not, and it has very little practical > implication. It defies logic the comments I read here. To you, you > probably wonder why the WORLD got to this point when it was DONE all > wrong! Easy Hector, you're hot and with good reason. Joe is just being Joe. He's actually gotten more mellow since I got here many years ago. While his signal is very high, his noise tends to drift high too, and that's what you're reacting to. Just remember why we're here: to help each other and enrich the community with our experience. The effective way of doing that is not to play Joe's game. It is to play your game. And from what I've seen, your posts offer much good in them. Keep it up! :-) -- David
From: Tom Serface on 23 Jan 2010 02:37
Hi Joe, I'm sure you always teach them about the benefits of using GetDlgItem() to access controls... :o) I'm actually surprised that doc/view hasn't show up as a paradigm in C# yet (at least that I've seen). Most of what I do is just WebForm or WinForm based and they are mostly glorified dialog apps. The interface for creating them is much nicer in the IDE than the MFC resource editor, but it's sort of like and expansion on the VB metaphor from just about forever ago. Tom "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:ve4kl5lmqhh6hs3tjo7cvd78nbs49e7d7u(a)4ax.com... > The course is titled "MFC Programming", and its goal is to teach people > who may not know > C++ and usually don't know MFC how to quickly become effective > programmers. I have five > days to teach them the basics of C++ and MFC. Inevitably, there are those > who learned how > to write bad C code 20 years ago, or were taught bad C progrmaming 10 > years ago by people > who were bad programmers, and they try to force C++ to look like C. They > don't understand > those complicated "classes", they have ideas like "I want to change the > functionality of > this control, but I don't want to create a subclass", they write bad > Petzold code in MFC > (they write everything as a switch statement by overriding the OnWndMsg or > PreTranslateMessage handlers, because "That's how Windows works". It is > my JOB to > restrict their mindsets! > One of the reasons most of my clients won't use C#, WPF, etc. is that it > doesn't support > MDI, and therefore does not support what they need to do. It was a design > blunder to not > continue this important paradigm into the modern world. > **** >> >>Personally, without the help of the smarter IDE holding the hands of >>programmers, using MDI in C/C++ was very complex framework to follow >>and require a high degree of understanding. Never mind the fact that >>it added a higher overhead. > **** > I always get suspicious when someone says "higher overhead". I have no > idea what this > means. Sometimes, it means "it executes a few thousand instructions extra > while > processing a mouse click" as if that statement has any meaning whatsoever. > Particularly > if you are trying to compare MDI to SDI, where they essentially have the > same performance. > **** >> >>I just had to make a comment mostly because I noticed a propensity >>from your post lately that many methods that have many years of >>precedence is deemed by you as wrong and/or incorrect. The Exports >>thread was one of them. I suddenly felt "Am I stupid?" because we use >>WINAPI in our prototyping and DEF files for our WIN32 SDK? > **** > WINAPI is a bad choice, for the reasons I outlined. I see nothing that > suggests it was > ever a good choice. If you want to use __stdcall, either invent your own > macro for your > application suite, or use __stdcall directly, but don't use a Microsoft > word that means > "the standard linking into the kernel" because that means changes in that > interface can > render your code nonfunctional, because you have based your interface on > something subject > to change. > > .DEF files have their uses, but sometimes they are clumsy. They are not > always the first > and best choice for exporting symbols these days, and unless you are using > features such > as export renaming, numeric entry point mapping, and other DEF-file > features, they don't > represent the ideal selection. > **** >>both, where it applies, when we want to expose C/C++ classes, then we >>use the dllexport/dllimport declarations. When we want to expose pure >>pascal based stack proloque/epilogues we used the traditional WIN32 > **** > You are programming in Delphi? THat's the only thing I know that has a > pascal based stack > prolog/epilog. In a pascal calling convention, arguments are pushed > left-to-right. I'm > sure that is not what you intend, so either you are using __cdecl or > __stdcall. The word > "pascal" as used in WIn16 disappeared from programmers' vocabulary when > Win32 was > released, and it is a failure of Microsoft to have not removed that > obsolete keyword from > every header file in existence. Note that in Win16, the "pascal" > convention really did > push parameters left to right instead of the right-to-left used by __cdecl > or __stdcall. > It is reasonably important to not tie modern programming to quaint and > obsolete, and in > fact, irrelevant, concepts like "pascal". > **** >>WINAPI because that is how WIN32 works and it is the method most >>explicit traditional binding is done in the API world. For use, this >>important because we have a 250 function WIN32 API/SDK for all the >>major languages, including p-code languages: > **** > You are confusing abstraction and implementation. If you want the > implementation of > __stdcall, you can either use it explicitly, or create your own macro, but > relying on > someone else's definition does not seem a good choice. > > The point is you need to understand what Microsoft owns and what you own. > You own the > linkages to your library, so using a keyword that Microsoft owns seems > inappropriate. > joe > **** >> >> C/C++ >> Delphi (from 3.0 up) > **** > Delphi presumably calls external functions using __stdcall, because it > would not be safe > to assume a C/C++ calling convention for non-Pascal code. But I suspect > it does not use > WINAPI, it uses __stdcall. This week, in Win32 (only), __stdcall and > WINAPI are the same. > **** >> VB (classic) >> Java >> PHP >> COM >> .NET >> >>We have a mixed world here. I will say, today, if you allow the IDE to >>create the initial source code and framework, that it helps in the >>area of not needing to pay special attention. However, personally, >>over the years, when I want clarity or have issues with multi-language >>API imports, by far, using the MS dllimport/dllexport has been more >>problematic and generally will revert to the basic methods. > **** > For multi-language API imports, you have to choose a calling convention > supported by all > the languages. The last I looked, it was formally __stdcall for Win32. > Not WINAPI. > **** >> >>Anyway, as David suggested, its about wisdom and generally, with age >>comes wisdom and openness to understand: >> >> "There is no such thing as bad ideas, just bad implementations." >> >>SDI and MDI has its place in the CUI arena. >> >>I don't think you want anyone telling you this. I wouldn't, but I am >>also not the type to tell anyone that is good or bad. I might suggest >>there an an optimal way to do something, but I am strong believer of >>people learning thru trial and error and fault. I guess today, that >>is rare and IMHO the "IDE" help contribute to people needed more help >>not less because almost inevitably most programmers, some day will >>need to understand how things actually work not depend on higher layer >>frameworks holding their holds. I will be interested to know the >>statistics how many programmers don't use the IDE for development or >>don't depend on it or get solve issues when the IDE is not there for >>them. :) > **** > "Good judgment comes from experience. Experience comes from bad judgment" > > My goal is to help my students AVOID making the mistakes I have seen, and > most especially > avoid making the mistakes I have made. In my early years of MFC > programming, I would > propose SDI apps to clients. Or accept their specification of SDI. > Inevitably, it became > evident that MDI was what was desired. So why should I tell people that > SDI is a good > idea, when in EVERY case I have created an SDI app, the client ultimately > wanted MDI? That > clients who had SDI apps came to me and said "convert this to MDI, > PLEASE!" When you > start seeing patterns like this, it is important to pass this information > on. > > I do not use the VS IDE for editing, because the editor is somewhere out > of the Dark Ages, > sort of glorified keypunch. I know what a program editor is supposed to > do; The VS editor > doesn't do it, and can't be made to do what I need. Intellinonsense > doesn't work right > (gives A or W suffix APIs, not the abstract API), and to use it, I still > need to bring up > the documentation. So, it is nearly useless nearly all the time for me. > I either have > the API memorized and don't need it, or I need the COMPLETE documentation > on it so I know > what flags that UINT or DWORD use, or what > should-have-been-enum-but-is-a-#define constant > I should use. Sadly, the API isn't even defined wll in C, let alone C++, > and I might was > well lhave a decent editor. > > Now, perhaps you are confusing "IDE" with what we thought of as "wizards". > Frankly, the > view that these are a handicap is nonsensical. They are very important, > particularly for > beginners, because you can build WORKING code with a minimum of effort, > and learn the > details at your leisure. Doing it by hand means you have to know > EVERYTHING before you > can even start, an extremely poor approach to building cost-effective > systems. I was > delivering MFC solutions for two years before I fully understood command > routing. It did > the right thing, and I didn't have to care why. > > The only reason I don't use the wizard-style interfaces was that due to > serious design and > implementation failures, Microsoft rendered it almost but not quite > totally unusable. But > by this time, I don't need it, I can simulate it as fast as I can type. > But I would not > recommend this approach to someone learning MFC. [When Add Variable takes > over a minute > to bring up a dialog, and along the way, every time I want to add a > variable I hear it > spin up the disk in my CD-ROM drive, even though the drive does not appear > in any path > anywhere, I know that someone who was totally clueless did the > implementation. An "add > variable" dialog that can only add one variable, and takes anything over > 100ms to come up, > represents a failed design. But it was designed by people who obviously > never actually > wrote a line of code in their lives, and did not understand workflow of > software > development. And to the lame excuse that "it's good for C#", it sucks for > C#, too] > > Most people have never seen a decent editor, and don't know what they are > missing using > the primitive editor we get in VS. > **** >> >>This is all of course, ONE MAN's OPINION :) >> >>Ciao >> >> >> >> >>Joseph M. Newcomer wrote: >> >>> 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 [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm |