MFC SDI Application without a default “New Document” on Startup
in [MFC]
|
From: DanB on 24 Apr 2010 02:53 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.
From: Hector Santos on 24 Apr 2010 22:50 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. -- HLS
From: DanB on 25 Apr 2010 03:25 Joseph M. Newcomer wrote: > 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. Yes, and you can certainly do this with multi SDI. Our 'default' page is an instance of no project view is open. It is an HTML view initially with a default hello there page, our clients never see a blank app. But the client can access our website for whatever at the least. The can surf the web, but not our intention, it just happens to be available. As for knocking out the doc, not at all. I use the doc object at all times, even if it appears almost useless. Our paradigm: The master mainframe. Though the view menu you can access the major views of the app. Each view has its own doc, of course! We do this because it makes no sense to have any of these views available at the same time. Other SDI instances are available according to the state of the master frame. For instance, you can have a project notes frame active no matter what state the master is in. It is always there if you bring it up. If the master is in the report view, you can open as many report doc/view/frames as you would like but if you leave this view, they will close and ask if you want to save, if needed, on the way. I have a doc/view/frame modal wrapper. I only have to derive from the doc to set menus or any other features of this set. The frame/view can be generic snapins, like: void ReportOptions::OnBnClickedRptEditfooter( ) { CFrameDialog dlg( IDR_EDIT_FOOTER, RUNTIME_CLASS( RAFooterDoc ), RUNTIME_CLASS( HERichFrm ), RUNTIME_CLASS( HERichView ), this ); .... There is a lot of potential in what you can do with MFC. SDI does not have to mean you only have one document. It only means you don't have an MDI mainframe. But like I said, you have to implament it. Like I have my own derived doc template and manager for the ifrastructure. All the app frames register with a frame manager. If you alt tab from the app and back to the app, you want all your frames to come to the top in an appropriate order as if the app were a unit, just like MDI. Best, Dan. 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: Hector Santos on 25 Apr 2010 19:07 Hi Joe, "see below" <g> Joseph M. Newcomer wrote: > 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 But you "can't" always do this for commercial software or for software served more than one person. In my experience, a good bit of the time it is spur of the moment thing where one customer is doing something at a particular and RARE moment and says "Geez, wouldn't it be nice..." and makes the suggestion, but then it isn't needed 99% of the time or even ever again. Many times no one follows up. It would be a major mistake to believe silence means agreement. In fact, in many circles silence could mean no interest in the suggestion. -- HLS
From: Jd on 25 Apr 2010 20:50
On Apr 22, 11: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. > joe > > On Thu, 22 Apr 2010 03:27:46 -0700 (PDT), Goran <goran.pu...(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: newco...(a)flounder.com > Web:http://www.flounder.com > MVP Tips:http://www.flounder.com/mvp_tips.htm Dear Joe, Sorry , I was sick and couldn't follow up the thread. My app is almost same as the one you mentioned. A config file to specify the properties of a remote embedded system. ( this part is used rarely, as it is a complex system and configuration changes very rarely) and transfer the config file to the system. And the other part is monitoring the system and the devices attached to the system. Jd |