HUGE program for 8.04 WORKS GREAT!

[Mark Strickland]

If you have any doubt about the size program PBWin can handle look at the compile log file below. This is from a very large FireFly project that has hundreds of screen controls.

PowerBASIC for Windows
PB/Win  Version 8.04 
Copyright (c) 1996-2007 PowerBasic Inc.
Venice, Florida USA
All Rights Reserved

Primary source:  C:\ApotheSoft\RX\PPS32W\CODEGEN_RX32W_MAIN.bas   {335512 total lines}
Target compilation:  C:\ApotheSoft\RX\PPS32W\Rx32W.exe
Compile time:  58.9 seconds, at 341777 lines/minute

3046484 bytes compiled code, 55457 bytes RTLibrary,
84620 bytes string literals, and 121952 bytes dgroup.
Executable stack size:  1048576 bytes.
Disk image: 3678720 bytes   Memory image: 262029 bytes.

Component Files:
  (removed to shorten the message but there are 86 of them!)

An impressive job for any compiler but PB just hums through the process

Pretty good for FireFly to generate this size project too

[Steve Hutchesson]

Just to confirm Mark's results I did a test piece for a technique that I have wanted to use with PB for a long time but could not due to the 16 bit memory limitation.

I converted the old win32.hlp file to DB format, a source file of 44 megabytes, then built the following test piece. results are below the source code.

' «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
'
'                             PB Main Template
'
    DECLARE FUNCTION Read_2626A7A() as STRING

' «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

FUNCTION PBmain as LONG

    Open "win32.hlp" for Output as #1
      Print #1, Read_2626A7A
    Close #1

End FUNCTION

' «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

#include "pbbig.bas"

======================================================================

PowerBASIC for Windows
PB/Win  Version 8.04
Copyright (c) 1996-2007 PowerBasic Inc.
Venice, Florida USA
All Rights Reserved

Primary source:  H:\BASICS\pbbig\bigtst.bas   {788022 total lines}
Target compilation:  bigtst.exe
Compile time:  11.8 seconds, at 4006891 lines/minute

12607796 bytes compiled code, 5288 bytes RTLibrary,
16 bytes string literals, and 1380 bytes dgroup.
Executable stack size:  1048576 bytes.
Disk image: 12616192 bytes   Memory image: 6684 bytes.

Component Files:
----------------
H:\BASICS\PBBIG\BIGTST.BAS
PBBIG.BAS

10/17/2007  07:50p          44,096,973 pbbig.bas
10/17/2007  07:38p                 498 bigtst.bas
10/17/2007  07:51p          12,616,192 bigtst.exe
10/17/2007  07:51p                 569 bigtst.log

======================================================================

[Michael Mattias]

Sheesh, I ain't seen single programs that large since I worked on Big Iron.

FWIW, there is this cool new thing called the "Dynamic Link Library" which might cut down a tad on the 'download/install overhead' when updates are required.

Then again, this may not be a consideration in your application. (Conditions not shown).

[Mark Strickland]

Sheesh is right

Michael,

I love those DLL's too but this program has such tight integration of data among the various sections of the program it cannot easily be moduralized without a negative impact on the user interface. The program has two layers of tabed screens (tabs on tabs) that total 28 tabs. I think that the TextBox control count is over 800. This is a pharmacy system and the insurance processing screens alone account for probably 250 of the TextBoxes. I don't see how these poor independent pharmacists ever make any money. The typical prescription profit is about $5 regardless of the price thanks to the way insurance works.

You can move from tab to tab and the user interface is seamless. Load a prescription and then click the patient, doctor, or drug tabs and the info is just there. Click the patient profile tab and you can instantly see every prescription they ever had filled and easily scroll around to look at them. If you want to refill one from the list just double click and you will instantly change to the RX screen with all of the data filled in and now the other tabs (doctor and drug) will have the info for that prescription. Very tight integration.

This thing has a few thousand man hours invested.

Being able to actually maintain this in FireFly is the good news but FireFly probably contributes some overhead to the number of lines of code.

If I was to re-write the whole thing from scratch I probably could create an architecture that would help minimize the size of each module. Because of the amount of data that is shared among the various forms I would have to create a memory mapped file arrangement or other architecture otherwise the user friendly nature of the program would be effected. Since this would add some complexity it would be a trade off.

Mark

PS -- I enjoy reading your forum comments on lots of topics.

[Michael Mattias]

Because of the amount of data that is shared among the various forms ..

I have thirty-seven cents says it's not the amount of data but how it's shared which makes modularization difficult.

MCM

[Cliff Nichols]

I have thirty-seven cents says it's not the amount of data but how it's shared which makes modularization difficult.

I will up it to $0.52 that you are right
(not to one up ya, but I figure a Nickel and a Dime is not a bad price to pay when the point is "TMI" to the user at one time) unless I am mistaken on how it is displayed.

I am guilty of this myself so don't feel bad...I am just learning to go back re-read what I wrote before, and seek what is common vs what the "Twist" factor is depending on what I am looking for

Unfortunately (or Fortunately) one point MCM points out is what I need to learn myself.."1 function...1 purpose"

simple example: Main data is name, addr, symptom and lets say all three are in one function
original code:

• Look up name
• Look up Addr
• Look up Symptom
• Base code from there

As "scope-creep" comes in...add options etc, etc over time and next thing you know

• Look up name
• Look up Addr
• Look up Symptom
• Look up Symptom that was a "Sub-Symptom" of the first
• Base code from there

well I got the first 3, but now a twist to the original intent when I coded it

later I get another that I must now check who the doctor is?and next thing you know

• Look up name
• Look up Addr
• Look up Symptom
• Look up Symptom that was a "Sub-Symptom" of the first
• Now look up who the doctor is
• Base code from there

and it keeps growing..when the 1st 3 were the original intent, some you care about, some you don't depending on what you are looking up
and now we got 3 functions all doing the same thing, just with minor twists

I will be the 1st to admit that I break all rules I am preaching (I am learning, but it takes time to remember to do it)

now for whatever reason I want name and doctor's name only...(now I have to write yet ANOTHER routine to parse the routines I already wrote to handle the other situations

it all snowballs from there (and I only used 3 possible scenarios), so I hate to say it (cause I need to admit it to myself)...time to look at what you wrote before, vs what being asked and how you can modularize common points that you are after

(Take it from me...something I wrote 5 years ago, I now am finding I need to revamp for situations that I NEVER even conceived of when I first wrote the routine)