Linking multiple SDI apps from one common app 1

[mwr412]

I'am very new to programming VC++ with MFC's. I am rewritting a very complex and robust DOS based accouting system into windows useing MFC.

There will be multiple modules, i.e. Accounts Receivable, Accounts Payable, General Ldeger etc. Within each module there will obviously be a number of functions including, maintenance forms, reports, setup dialogs and posting options.

I am very, very confused at this point. I can create a maintenance form using an SDI framwork and ODBC--no problme. If I create multiple SDI apps for each of my funcitons, (this allow s me to assigne some of the work to another programmer and then incorporate it into my module), can they latter be tied back into a single framwork (basically a menu app) and executed. If so, how do you do this??? Is this the wrong approach? Should all functions within a module be setup within an SDI framwork or is this an MDI app?

I need guidence as to what to do...

 

[programsecrets]

In my opinion, MDI can often be confusing (more on that later).

A different idea would be to use SDI, but include a set of tabs along the bottom or top of the document (similar to Excel workbooks) showing each application (AP, AR...) or function within a single application (P.O., Invoice...). When the user clicks on the desired tab, the main screen for that application is displayed. If a second application is selected, the first form is "hidden" and the next one is displayed. This allows them to navigate back and forth between desired "areas", but reduces the confusion of having multiple documents floating around or getting hidden accidentally with no easy way to find it other than minimizing each document until the right one is found...

Even so, you'll need to determine how to navigate between sub-functions easily (someone has "drilled deep into" a function and wants to "visit" a screen from another function). You could do this with a tree control on the left side of the screen (like Windows Explorer) and a Back button (like I.E.) with a history list...

I would think it would be good not to have completely separate applications firing up whenever a user wants to switch between AP or AR or whatever. It's better to keep control under one parent application and overlay the current accounting function within the same GUI framework.

You should spend a LOT of time planning the most efficient and best user interface before you ever hire anyone to code it. Good user interface design is what makes or breaks a product!

Regarding your desire to divide the work, that's always a bit tricky with a GUI application. What will help is if you keep the business logic as separate from the user interface as possible. Then, different programmers can work on the GUI (user interface) portions and the back-end non-GUI portions.

Are you sure you want to do everything in VC++/MFC? GUI programming is more work in VC++ (comparatively speaking). Many applications are done in VB for the GUI and VC++ for the non-GUI portions. Unless you're thinking of doing something pretty complicated, you may want to give this some thought.

Another factor is that VB programmers are easier to find and hire than VC++ programmers (at least in our experience). This is a factor to consider both during the development stage, as well as the maintenance phase.

I'm a VC++ programmer and have done some fairly elegant user interface work, but I've seen others "whip out" some pretty nice looking VB front ends much more quickly.

Just some food for thought. Hope it helps.

 

[mwr412]

Yes, you are correct...I do want to control when and where the using can navigate to...in fact I have considered the use of a tab structure as you outlined. I have the entire application designed, (down to the look of each maintenance form) on paper. I have began codeing some of the maintenance forms using a basic SDI interface...but...this does not accomplish what I ultimatly want to happen. If you can bare with me I will describe what I want to happen with the interface and hopfully you can give me a heads-up as to what needs to be done to achieve this goal.

I. Main Application (Icon on the desktop)

When clicked a maximized window/frame will display which contains a number of icons or tabs representing each applicaiton...(as of now there will be 10 different apps... Accounts Receivable, Invnetory, Purchase Order, Sales Order, General Ledger...you get the point).

Now when the user selects on of these tabs I want to paint the client area with the applicaiton main menu. No tabs at this level but a seriers of Icons and descriptions which can be selected. Each selection at this level will invoide yet another sub-menu of fucntions. This will be the bottom level of menus, from here we will invoke specific funcitons such as Add/Change routines, reports, setups etc.

If the user has selected AR, then File Maintenance, then Add/Change Customers, (the customer add/change form is dispaly and active)...and he then wants to jump over to Inventory and add a product...I want to happen is to basically switch view and documents(databases). First he would select the Invnetory tab to get the Inventory Main Menu, (the document and view for the Add/Change Customer must be preserved and hiden behine the new selection). He then then select down to Add/Change products and add a new product to the invnetory database. That done he can click back on A/R and restore the Add/change customer form just were he left it, while the Inventory Add/change remains hiden. My design calls for the user to do this with any and all of the apps. In other words, he could have navigated to any point within any app and get back there simply by clicking on the tab for that app. If he wants to exist I will provide both an exit to main buttom and possible a 'back' button to navigate back one level at a time.

Question 1 - am I correct in that I am dealing with a single SDI app or 10 different SDI apps connected by a SDI app which acts as a menu or 'loader'????? Do you see any reason that I sould be using MDI at all?

Question 2 - I do not think that all 10 of these apps can be coded into one giant program, to much code, the executable would be huge. In addition, a user might only purchase selected apps so they need to be packaged seperatly. On that basis I think that the low level functions must be stored in DLL's then invoked from the master app. Am I correct in my thinking here? Is there antoher way, a better way?

A little background...I started designing these apps about 2 years ago, before I even looked at VC++ or any other windows based development package. I did this on purpsoe. I wanted to design an interface based on my experience with using the apps and not have coding considerations decide what was best or easiest...I have the entire project designed on paper I just can't figure out out to conect the dots. My knowledge of VC++/MFC has been aquired in the past 6 months. (i have used C for years but not in a GUI enviroment).

mwr

 

[programsecrets]

Before answering, let me just say that I'm not God's gift to GUI programming and I am just expressing my opinion based on the experience I've had. I'm sure there are others who would have other opinions (but that *is* the nature of an "opinion", isn't it? s-)

Question 1 - am I correct in that I am dealing with a single SDI app or 10 different SDI apps connected by a SDI app which acts as a menu or 'loader'????? Do you see any reason that I sould be using MDI at all?

Um, it sounds like a single SDI app would be best, partly because separate apps have to either include or load all of the MFC (or other) libraries and memory requirements and/or loading delays could be a problem (or irritation) with all those functions in separate apps.

As long as the user doesn't need to see more than one thing *simultanously*, MDI is not necessary. It sounds like you and I have the same type of design in mind, where the user is able to navigate back and forth, but only one app displays at a time. Even if there is a need to show multiple things at once, I prefer using a splitter window to show them (but that may not always be practical, depending upon how much screen real-estate you have).

Question 2 - I do not think that all 10 of these apps can be coded into one giant program, to much code, the executable would be huge. In addition, a user might only purchase selected apps so they need to be packaged seperately. On that basis I think that the low level functions must be stored in DLL's then invoked from the master app. Am I correct in my thinking here? Is there antoher way, a better way?

Yes, the low level functions should be packaged as standard DLL's or even as COM objects (depending on the experience of your programmers) and loaded/invoked only as necessary, or as your licensing permits. You also have the option of providing basic functionality for each application and if they purchase the "deluxe" license, giving them the app with all the extra "bells and whistles".

I wanted to design an interface based on my experience with using the apps and not have coding considerations decide what was best or easiest...

That's excellent! Designing an interface that allows a smooth work flow (based on your actual experience) is extremely important to your success. Most issues can be worked out, although compromises are always required (given your time to market, etc.) But, leave your options open, get "release one" done and out the door, then work to add more functionality and to improve those things that can be expanded or where you've gotten user feedback. There are always "dots to connect" between the analysis and design phases and even at the coding phase.

Be sure to limit the scope of the first release to "required" functionality and include only the most important extras. Most projects fail when "feature creep" sets in.

 

[programsecrets]

The last comment in my previous post made me think of this:

You might want to read (or at least look through), "Pitfalls of Object Oriented Programming", by Bruce F. Webster (M&T books, ISBN 1-55851-397-3) It contains a lot of insight about what to do (and what to avoid) so your project has every chance of being successful.