MFC SDI Application without a default �New Document� on Startup
in [MFC]
|
Prev: Derived Class at Design Time
Next: Control color skin
From: Joseph M. Newcomer on 21 Apr 2010 10:56 What the OP is asking is how to have an app that allows for either of two types of documents to be created, at the user's request, instead of creating only one type of document by default. The techniques discussed earlier are what are required. joe On Wed, 21 Apr 2010 03:08:04 -0700 (PDT), Goran <goran.pusic(a)gmail.com> wrote: >On Apr 21, 2:39�am, Jd <j.durgapra...(a)gmail.com> wrote: >> Why I chose this "No document on startup" idea, is that my app has >> some more features, which doesn't depend on the document. >> User can use the same application for creating a configuration file or >> can use it for status monitoring. > >Ok, but what's wrong with creating your file while you have e.g. an >empty new document open? I don't see the relation between the two. I >don't quite understand what you mean by "status monitoring", but >again, isn't this also orthogonal to the doc? I have a similar app >(speaks to embedded devices over a proprietary protocol over a serial/ >TAPI/TCP connection), and that indeed is orthogonal to the document in >our case. > >Goran. 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 22 Apr 2010 10:14 Actually, I did this some years ago. The "config" file was an external file that specified the properties of a remote embedded system. The other type of documeht actually communicated to a remote embedded system. joe On Thu, 22 Apr 2010 03:27:46 -0700 (PDT), Goran <goran.pusic(a)gmail.com> wrote: >On Apr 21, 4:56�pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote: >> What the OP is asking is how to have an app that allows for either of two types of >> documents to be created, at the user's request, instead of creating only one type of >> document by default. �The techniques discussed earlier are what are required. >> � � � � � � � � � � � � � � � � � � � � joe > >Well, it doesn't seem so. � understood it as needing to modify a >config file for the whole app (some kind of "options" command an such) >- happens all the time. It's an overkill to introduce another doc type >for that. > >Goran. 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 23 Apr 2010 23:59 My bias is that I do not ever use SDI (I find it largely useless, and every time I did an SDI app, the customer ended up with an MDI need and I had to convert it, so I never even *think* of SDI as a viable model any longe). joe On Fri, 23 Apr 2010 04:24:23 -0700 (PDT), Goran <goran.pusic(a)gmail.com> wrote: >On Apr 22, 4:14�pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote: >> Actually, I did this some years ago. �The "config" file was an external file that >> specified the properties of a remote embedded system. �The other type of documeht actually >> communicated to a remote embedded system. > >Well, for an SDI application, it's either one doc type open, or the >other. I still think it's an overkill. > >One can just "edit" the "config" file from "options" dialog or some >such, without reaching for a second DocTemplate. > >Goran. 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 24 Apr 2010 18:42 My client needs have always turned out to be 1. We need to work on more than one thing at a time 2. We need to see more than one view at a time on a thing 3. We need to work on zero or more things at once Note that 3 is a generalization of 1: it allows zero things to be active. So it isn't just working on 1 or 2 or 3 or 4 things, but the possibility that all things will be closed and no thing will be currently active. And a 'thing' is usually represented as a 'document' (there is a horrible failure to communicate what a 'document' means; I've seen cases where they "get rid of all that useless document code" because "we aren't writing to a file", and they've expended WEEKS of effort to no value whatsoever; I point out a 'document' is an interface to some persistent state, and in their case, the 'persistent state' is in the embedded controller at the end of a wire, so the document is a 'virtual document' and provides the interface to the device, at which point they say "You mean ALL THAT WORK we expended to eliminate the unnecessary document code was wasted?" usually followed by "and you mean ALL THAT WORK we expended so one view could talk to another so the view could control the device was wasted?" and the answer is always "Yes, you wasted a lot of effort and gained nothing". Sadly, they thought it was meaningful to eliminate the "wasted code", and I asked them to compare the code-with-derived-CDocument to the code-without-derived-CDocument and the difference is always minute: for example, 4K out of 280K (in one memoarable case) "So you thought was worth six weeks of your programmer's time to save about 1% of the code space, or 4K out of 2GB virtual space, or you have saved 0.0002% of your virtual address space. Was this REALLY cost-effective?" and they say "Well, we didn't want code bloat" which shows how truly incompetent most companies are in evaluating what they are doing internally. I wonder sometimes how anyone could be this stupid. But back in school, some programmer who learned how to program on a 64K PDP-11 told them that You Must Make Your Code As Small As Possible, and they never outgrew that bad advice. joe On Fri, 23 Apr 2010 23:53:41 -0700, DanB <abc(a)some.net> wrote: >Joseph M. Newcomer wrote: >> My bias is that I do not ever use SDI (I find it largely useless, and every time I did an >> SDI app, the customer ended up with an MDI need and I had to convert it, so I never even >> *think* of SDI as a viable model any longe). > >Here I sincerely agree the way SDI was implemented out of the box. > >But that is just what I have done for our product. And it is a real >success. I certainly did not use Microsoft's model as a bases. But if >you create your own system it can be as good, and I think better than MDI. > ><http://reserveanalyst.com/images/content/First.jpg> > >I did not show the task bar, but like sea monkey, or the likes, you have >multiple accesses to running 'children'. For instance, we can run the >'Stock database', looks like an independent app, but is a delayed loaded >dll. And looks like it living so on the task bar. The client can alt tab >through several of our 'lives' and use them as they need. > >I guess it depends on the needs of the app. Multi sdi does not work as >shipped in 7.1. But because I evolved it on my own I can't say what 9.0 >really looks like. > >SDI can work like MDI, but IMHO, even better because of the multi app >feel. Just because Microsoft doesn't deliver does not mean you can't do it. > >Best, Dan. 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 25 Apr 2010 16:55
Probably 80% of the apps I write are dialog-based apps. There are small and subtle differences between an dialog-based app and an SDI app with a CFormView; for example, the SDI app has a status bar while the dialog-based app normally doesn't (but it can be added). But overall most of the people don't seem to care about the distinctions. I did one app that I thought "should" have been a dialog-based app, but I did it as MDI mostly because we wanted multiple views/ Turns out we needed to handle multiple devices, so when the client called and asked for it, all I did was disable the code that allowed only one document at a time to open. Took maybe 2 minutes. I emailed the solution 20 minutes later (I did a little testing) I also suggest that for learning MFC, dialog-based apps are often a better choice for a beginner. joe On Sat, 24 Apr 2010 22:50:03 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >Joseph M. Newcomer wrote: > >> My bias is that I do not ever use SDI (I find it largely useless, and every time I did an >> SDI app, the customer ended up with an MDI need and I had to convert it, so I never even >> *think* of SDI as a viable model any longe). >> joe > >I think you all have good points. > >We have several applets that are SDI but only that it allowed it to >get a quick mainframe and view window with all the menu, command line, >toolbar, etc, especially getting all the overriding classes necessary >already provided to you. > >Sure, all could of been done starting as simple dialog, and many new >applets begin this way too and add controls as required, but the >initial SDI layout was the design intent. We needed more than a DIALOG >and less than a MDI. > >But I also see Joe's point for one of applets. One applet is a >RADIUS server. It is a SDI with a CVIEW that has a few splitters. This >is a product for thousands of customers. If they have multiple RADIUS >servers, they start multiple EXEs. We had a few customers that >wanted or rather "wished for" to have one EXE for all of them, for >machine monitoring. If it was MDI ready, then it would be a piece of >cake. It was never done and they accepted as it was. If we had maybe > a louder cry for it, then the effort would of done to change it to MDI. > >I guess Joe's point if it was done as a MDI to begin with, then it >would of been a moot point. > >Very true, but it doesn't take into account the performance issues >with having a single EXE with multiple threaded RADIUS servers, one >with their own view. That is why them wish list item remained a wish >list item, also, in our case, a majority of the time, wish items like >this are a spur of the moment thing. The operator is currently >monitor and says "Wouldn't it be nice if I can just view everything >with one exe." Sometimes we come back and say, "Ok, that would be >nice, but its only useful when you are setting on the computer most of >the time watching this stuff. Wouldn't it be better to tell us what >signals or events you are looking for to display them? That way you >don't have to sit there and watch for it?" and the discussing normally >subsides :) But thats our application. Others want multiple views >for good reasons. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |