Large MDI application strategies

[BOB MECHLER]

What are the best practices for multiple programmers to program in a single MDI application?

Should a large project be divided up into multiple MDI programs where only related functionality is in a particular MDI exe?

Should each potential window or formset have only the gui code in the MDI app and the functionality, validation, io etc come from a DLL?

Dumb question. Can there be more than one resource file per exe? I've not seen it so I assumed it was impossible.

What steps do different shops go through to test each part by different programmers without affecting the whole?

I'm trying to take our main application away from 420 small exe's that are tied to one multi-tiered menu. The upside to this approach is that every unique functionality is in one exe, hence all a programmer has to do is check it out and no one else can mess with it until it's finished. We use test areas, and different directories for TEST BAS'S TEST INC'S, the REVIEWED directories, then our stable beta area and finally code repository for what the customer's actually have.

One man shops don't have this problem, but I have to control and simplify the efforts of six programmers with standard includes and wrappers for common functionality that we use through our app.

Also, it's become a management priority to become either MDI or multi-windowed architecture.

I've thought about using #IF %DEF/ENDIF conditional compiles that would allow an INCLUDE FILE TO be run and tested independently.
In other words, if a certain equate is true don't compile repetitive code, but if it's not compile it all.

Something like:
#ID NOT %DEF(%PRG_PROGM1) THEN
FUNCTION PBMAIN AS LONG
#ELSE
FUNCTION PRG_PROGM1(PRM1,PRM2....)
#ENDIF

Also every generalized include for dialog and control creation would have the same conditional compile.

What is the best track for a team of programmers to use with PowerBasic.

Bob Mechler

[Michael Mattias]

Given this...

Also, it's become a management priority to become either MDI or multi-windowed architecture.

.. then child process EXEs are out and DLLs are in.

But I'm not nuts about 420 DLLs (each of which may have its own resources, to kind of address your resources question). There has got to be a better way.

On the testing? I think I'd budget some time to develop a separate, dedicated test program. I did this kind of thing for Milwaukee Insurance (a long long time ago) but I do remember the time spent on it paid for itself many times over since we were able to have mutiple programmers work in parallel on a large project.

And when I was GM of a VAR firm, we did the same thing when we had a major upgrade to do. Curiously enough, that was also a little over 400 separate programs, which had to be brought into a new 'front end menu system.'

Of course (he shamelessly added), you could engage an experienced professional to help you set up your project and software architecture for maximum productivity by your developers.

[jcfuller]

Bob,
I'm not sure if this would be applicable in your situation but
I use a small script engine that displays the window and also handles
basic file menu options with no outside code. But if you need more control
it can be directed to pass all messages to a function in a dll.

In it's present state it is an exe and not much use to you; but if you are
going to build from scratch anyway you could desgin a similar engine in your
main program and be able to use most of your exe code. The displays are shown
using CreateDialogIndirectParam.

Another advantage your programmers do not have to do the screen design work. An intern
or someone from the local pool of temps with some design/layout talent can be used.

You still have your programming granularity with seperate dll's (instead of exe's)

Just a suggestion and food for thought

Here is the script to display the dialog in the link.

James

https://www.jcfuller.com/example.PNG

'RDTSCRIPT
'---------------------------------------------------------------------------

Win.ID=9900	
Win.Width=280
Win.HEIGHT=220

Win.SaveFile=JDCK
Win.Caption=  Data Integrity Check
Win.Left=100
Win.Top=50
Win.Menu = 0
DataInfo.Id=Z01
DataInfo.FileExt=Z01
DataInfo.Desc=Data Integrity Check
DataInfo.HeaderText=JDCK


'Names of the controls.
ADDCONTROLS=Grid1; _
            Label1; _
            Label2; _
            Label3; _
            Label4; _
            Label5; _
            pb2; _
            pb3
     
Controls.Id.Start=704


'Prefix the name to the properties.
'---------------------------------------------------------------------------
'Id = 704
Grid1.Type=SPREAD25
Grid1.Left=-1
Grid1.Top=170
Grid1.Width = 455
Grid1.Height = 124
Grid1.SetupFile=JDCK
'------------------------------------------------------------------------------
'Id 705
Label1.Type=LTEXT
Label1.Left=8
Label1.Top=10
Label1.Width =260
Label1.Height = 27
Label1.ExStyle = 1
Label1.FontName=MS Sans Serif
Label1.FontSize = 8
Label1.FontWeight=700
Label1.Caption = " Member Joint File"
Label1.TextColor=Dark Cyan
Label1.Style = WS_CHILD,WS_VISIBLE
'------------------------------------------------------------------------------
'Id = 706
Label2.Type=LTEXT
Label2.Left=16
Label2.Top=20
Label2.Width =240
Label2.Height = 9
Label2.FontName=MS Sans Serif
Label2.FontSize = 8
Label2.FontWeight=400
Label2.DataType=TEXT
Label2.Style = WS_CHILD,WS_VISIBLE,SS_SUNKEN
'------------------------------------------------------------------------------
'Id 707
Label3.Type=LTEXT
Label3.Left=8
Label3.Top=45
Label3.Width =260
Label3.Height = 27
Label3.ExStyle = 1
Label3.FontName=MS Sans Serif
Label3.FontSize = 8
Label3.FontWeight=700
Label3.Caption = " Loads Joint File"
Label3.TextColor=Dark Cyan
Label3.Style = WS_CHILD,WS_VISIBLE
'------------------------------------------------------------------------------
'Id = 708
Label4.Type=LTEXT
Label4.Left=16
Label4.Top=55
Label4.Width =240
Label4.Height = 9
Label4.FontName=MS Sans Serif
Label4.FontSize = 8
Label4.FontWeight=400
Label4.DataType=TEXT
Label4.Style = WS_CHILD,WS_VISIBLE,SS_SUNKEN
'-----------------------------------------------------------------------------
'Id = 709
Label5.Type=CTEXT
Label5.Left=8
Label5.Top=170
Label5.Width =260
Label5.Height = 40
Label5.ExStyle = 1
Label5.FontName=MS Sans Serif
Label5.FontSize = 8
Label5.FontWeight=700
Label5.Caption = " Calculation Decision"
Label5.TextColor=Dark Cyan
Label5.Style = SS_CENTER,WS_CHILD,WS_VISIBLE
'------------------------------------------------------------------------------
'Id = 710
pb2.Type=ODPUSHBUTTON
pb2.Left = 61
pb2.Top = 185
pb2.Height=20
pb2.Width = 50
pb2.FontName = Tahoma
pb2.FontWeight = 600
pb2.FontSize = 12
pb2.TextColorUp=Dark Blue
pb2.TextColorDn=Dark Blue
'pb2.VSpace = 1
pb2.Caption = "Continue"

'Id = 711
pb3.Type=ODPUSHBUTTON
pb3.Left = 162
pb3.Top = 185
pb3.Height=20
pb3.Width = 50
pb3.FontName = Tahoma
pb3.FontWeight = 600
pb3.FontSize = 12
pb3.TextColorUp=Dark Red
pb3.TextColorDn=Dark Red
'pb3.VSpace=1
pb3.Caption = "Cancel"

[Chris Boss]

If you must build one large application, using multiple executables written by different programmers, there is one approach that might be useful.

Build a core EXE which is the actual main application.
In this app, build a library of reusable code, which all the child apps can access (export the functions). This would be a main API for the entire application and its children, so they can talk to the main app.

Create a specification of how child windows will work in the app (MDI or some other method).

The child apps, will not be EXE's.

They will be DLL's.

The beauty of DLL's in the case are the following:

- The DLL's can be dynamically loaded as needed and unloaded when done. Use the LoadLibraryEx and FreeLibrary functions to do this.
- calls to the DLL, by the main app (EXE), do not have to be hard coded. They can use the GetProcAddress API function can be used to poll the DLL for the any exported function to get the address of it and then you can call functions using the CALL DWORD (PB) command.
- DLL's do not require the .dll file extension. You can change it to anything you want, when dynamically loading DLL's. This allows you to differentiate your special DLL child apps from regular DLL's.
- DLL's can have their own resources to access and they don't need to be in the EXE
- DLL's can call back into the EXE itself. Simply pass the necessary function addresses to a DLL function that will store them for use. Then the DLL can call the EXE using the CALL DWORD command. You can also use explicit includes for exported functions of the EXE if you want.



I currently impliment plugins for my visual designer, using some of the techniques above. The plugins use the file extension .ezp and are loaded dynamically by the main app.

[Chris Boss]

Another approach to this problem could be this:

The child DLL's, need not have any exported functions at all.

The child DLL would simply be code for a unique window class.

This window class, would be automatically registered in LibMain and unregistered when the DLL unloads (also in libmain).

These DLL's could be loaded on demand as noted in my previous post.

The window class name, should be stored as a resource (using the same resource name in all the DLL's).

The main app (EXE) would load the child app DLL's on demand, poll its resources for a specific string resource which would be the class name of the custom window class. The app would then create a window of this class. It could be a top level window, a child window or even a MDI child window.

Communication between the parent EXE and the child DLL apps, would be done using standard window messaging. Simply create a list of user defined messages for the parent apps main dialog and the child DLL apps windows. They can communicate between each other via messages.

The only communication needed would be to use the SendMessage API function. No function calls needed!

This would be a very clean way to accompish what you want. Each mini-child app, would simply be a child window of a unique window class.

This would be very easy to impliment.

As noted above, you can still change the file extension to something other than .dll to make sure the main app never confuses these DLLs with a normal DLL.

Custom window classes, can have other window classes (ie standard controls) as children of themselves.

[BOB MECHLER]

Whoa!! Great ideas.
Small dedicated proof of concept app. Check
Load on need Dll's, that is the Call Dword approach I believe. Check
Keep most of the guts of the exe. Check
Consolidate all includes in the Main App. Check
Window messaging WUSER + 100, 101 ETC. Check
Multiple Windows classes. Check.
Plan, Plan, Plan Check.

I've already encapsulated a great deal of reusable code in INCLUDE files that I place at the top of every EXE created. Works, but incredibly stupid given the other options available that I understand now.

If it were my business I'd hire on contract basis several of you guys to get me through some conceptual stuff and planning but alas, they expect me to do it. I've always been the one say, Yeah it can be done and then I rush back to my browser and start asking questions praying that the forum is still there.

Thanks,

Bob Mechler

[Chris Boss]

Bob,

A few questions:

(1) Are you using DDT or SDK style code ?
(the techniques I mention above could be used with either)

(2) How are you visually designing your interfaces ? (ie. PB Forms)

It is important that the scheme used allow quick development of dialogs, especially for the child apps/windows. The interface of the main app, should allow easy design for both the parent app and the child apps.

[BOB MECHLER]

Chris,

For the last two years,everything new is PowerBasic Forms and SDK. The converted Dos programs are hybridized QuickBasic style code and Windows controls replacing 'Print' with a Label and 'Line input' with a textbox etc. The old Function keys have been replaced with buttons that click or respond to the same function key.

The captions and fields in these converted Dos programs are data statement driven with row,col,length,caption,field input rule (phone,dollar etc)

I'm starting to put every standard, subclassed and superclassed controls in their own function with parameter flags and just call them based on the flags in the data statements as I build the screens, so screen building is pretty fast.

Our programmers can generally fill a custom request in 1 to 5 days using the template application and include files I've built.

I never planned for MDI style though and it's throwing me a curve. The screens have data statements for them. I just need a way build a MDI child with the data statments and control validation and action through a DLL made up of the code in the current EXE. At least that is how I see this moment.

It's decision time on putting the latest Windows look and feel on the application though. Do I continue to use the current program template or start new program by program. The answer is probably both depending on the program or group of programs that share the same purpose.

I'm still in the feasibility study phase right now.

Thanks,

Bob Mechler

[Chris Boss]

Why does the app need to be broken up into so many small individual parts (apps) ?

Do you have any screen shots of the current app and how it looks ?

[Kev Peel]

Bob,

From what you posted I wouldn't even bother with DLLs, just create the basic MDI framework and bolt the required pieces on at a time. You could convert each former separate program to an #INCLUDE file and add it in. Even if you needed to run an additional external EXE you have Shell(), ShellExecute() or CreateProcess().

Using more than a handful of DLLs in a project can create a right mess. Avoid this unless you need to share code with more than one process (EXE) - that is the main goal of a DLL.

[Michael Mattias]

>It's decision time on putting the latest Windows look and feel on the application though

Whoa there, cowboy: Which is it, must be MDI or must have Windows Look and Feel?

"Windows Look and Feel" is an end; MDI is but one means to that end....unless your boss tells you MDI is an end.

I realize of course sometimes management is, shall we say, NOT on the short list for the Nobel Prize in Software Development, but you need to have it clear in your own mind before you start coding work on this project.

MCM

[Edwin Knoppert]

What's the purpose of the mdichild forms?
In VB it was misused but with PowerBASIC you can prepare real childforms.
Unless you really need MDI i would use childforms.

And with DDT you won't need to register windows.
This means each programmer can test his own forms.

[Cliff Nichols]

I have to agree with MCM on

>It's decision time on putting the latest Windows look and feel on the application though

Whoa there, cowboy Which is it, must be MDI or must have Windows Look and Feel?

If I think Bob Mechler is getting at what I THINK he is getting at, then you are in for a DOOZY!!!!

Anyways enough of the bold type.....If I understand Bob correctly, trying to port Quickbasic (predecessors of VB, PB and other basic programs) into a Windows GUI type of program?

Management is more like "I sold this...when can you have it done? I told them 2 weeks, just in case"....when we all know it would take 5 months if we never slept

The other thing that puts a twist is...if you got 6 programmers...are they each programming their own language? and you have to consolidate? or do they all know PB too? (or willing to learn)....TOOOOOO MANY VARIABLES

Excluding the whole SDK vs DDT deal...if I understand correctly you have many "Dialogs" or "Windows" that you wish to have in 1 program (AND look like it), and each capable of communicating or relaying info from one to the other so the user is not confused from all the options?

(Just to save confusion...if you are getting at what I think you are..you meant Multiple Dialog Interface (Each has their own buttons, checkboxes etc) and not Multiple Document Interface (Each being their own Notepad type thing))

As an Ex-VB'er (did I say Ex?) I can fully see Edwins comment of

In VB it was misused but with PowerBASIC you can prepare real childforms.

to quote and emphasize some point that Kev Peel pointed out

From what you posted I wouldn't even bother with DLLs, just create the basic MDI framework and bolt the required pieces on at a time. You could convert each former separate program to an #INCLUDE file and add it in. Even if you needed to run an additional external EXE you have Shell(), ShellExecute() or CreateProcess().

Using more than a handful of DLLs in a project can create a right mess.

so true...I have started going back to make *.INC files because using DLL's for a 1 purpose only idea, eventually becomes...(Ooops I need this option, oops I need that) and somewhere along the line you will use the wrong copy of the same dll (plus or minus functions) that will make your main program you are working on crash for some reason

All in all...if you can post a working example of the original code and what you would like it to do, I am sure its all easily upgrade-able, but without a clear picture, hard to say

[BOB MECHLER]

I need to think through what everyone is saying, decide which way to go, create a workable sample multiwindow program set and then continue the thread. Going any further right now is way premature. Thanks for throwing up the caution flags.

Bob Mechler