Best Practice for starting Powerbasic Win Project

[Eric Folbrecht]

I am new to PowerBASIC and want to start out correctly. I am working on a new program that has two programmers coding different sections of the program. I have created the menu system (using Forms), but now need to know how to best structure the program so that each programmer can be coding on their respective areas and yet be linked to a common menu system. Is that possible, or does everything get coded in one .bas to create one .exe? Do I use .dll for things that are not common functions but rather large programming operations? Is there a way for individual .bas files to be made into individual .exe files that are called, or grouped at compile time for one .exe? If so, what about variables, especially globals?

Your help in steering me in the right direction is very appreciated!

Eric

[Jeff Blakeney]

To answer your specific questions. It is possible to have two programmers using one source code for one main dialog with a menu (it might require some manual cutting and pasting after each person submits their code). You can create a project all in one source file or you can split it up into one .bas file and one or more .inc files. You can use DLLs if you want but it isn't necessary. You can create a main program that shells to other .exe files to do things if you want but it isn't very elegant. Passing variables to other .exe files can be done on the command line but I think the only way to get them back is either through STDOUT or redirecting the output of the called program to a file and reading the file (by the way PBWin doesn't have direct support for STDIN and STDOUT so you have to write it yourself or use PBCC).

However, you have tons of options to do what you want. If the menu system you have is a menu bar on a dialog and you want the other programmers to create code to do something when a menu is selected, you can always keep your menu code and the main dialog in one source file and have each of the other programmers create an include file and assign them each their respective menus that they need to code for. The only changes they should need to make to the main source file with your menu is to put a call to the routine for handling a menu (or control or whatever) in the SELECT CASE Msg of the dialog procedure for the appropriate message and menu item.

I wrote a program once that was made up of multiple modal dialog boxes so I wrote each dialog as a separate program and I used the PBMAIN routine to create and test that dialog. I put the PBMAIN in a compiler conditional (ie #IF NOT %DEF(%BIGCOMPILE) / my PBMAIN code / #ENDIF) so that it would be included if I compiled and executed just that source file. The main code defined the equate %BIGCOMPILE and included the source code for each of my dialog boxes that I had tested and debugged already so the PBMAIN code in each of those included files was not added to the final executable. You could do something like this as well if needed.

Another option is to use subversioning. My brother and I use a service called XP-Dev and a Windows subversion client called TortoiseSVN. A free account on XP-Dev gives you up to 200 MB of storage and allows you to have 2 private projects and an unlimited number of open source projects. It even has project management tools so you can create tasks that need to be done and assign them to different people. TortoiseSVN is used to get a copy of the version on XP-Dev that you want (usually the latest version), you make changes where you need to and then use TortoiseSVN to check those changes back in creating a new version of the source. XP-Dev keeps each version that is checked in so if things start going in the wrong direction you can always go back to an earlier version and start a new branch. If more than one person changes something, the second person is notified and they should fix the conflict but this shouldn't happen too often.

I'm sure there are lots of other methods too so use your imagination.

[Chris Holbrook]

You want to go where? Oh, I wouldn't be starting from here, sir!

Try advertising on the 3rd party forum.

[Michael Mattias]

>Your help in steering me in the right direction is very appreciated

First step: Stop Now!

This should have been planned before the first programmer wrote the first line of code.

Here's some more bad news: There are no silver bullets; each project is different.

Here's some GOOD news: the start of a plan.

Start by creating the list of procedures you are going to need, and set those up to use no GLOBAL variables. Now programmers create PROCEDUREs rather than FILEs, and you can always put those together with #INCLUDE.

'MASTER.BAS
FUNCTION WinMAin(...

   CALL BobsProcedure (params) 

   CALL MarysProcedure (params) 

END FUNCTION
#INCLUDE "BobsProcedure.INC" 
#INCLUDE "MarysProcedure.INC" 
#INCLUDE "SharedProcedures.INC"    ' <<< someone does this one FIRST. 

' *** END OF FILE ***