Breaking up is hard to do... Calling finicky Subs

[Doug Ingram]

Any hints on breaking up a huge program into 'includes' to make it easier to manage? (8000 lines is getting ridiculous).

When I move a (working) SUB to an included file, I'm getting duplicate definitions even though I've tried using the Declare in the main, include, both???

Maybe I'm missing something and I've read it through fairly well.

Does any sub the sub might call need to also be in the include?

Just wondering from some of you 'big' coders.

Thanks for looking!

[keith shelton]

If you are using pbcc5.0 you can use the #include once command.
KS

[Brian Chirgwin]

Without seeing code it is difficult to say what is going on. Attached is a simple example. Maybe it will shed some light on your issue.
If not if you could post code I'm sure someone here could help figure it out.

[Michael Mattias]

You should only be getting duplicate definition errors if a procedure appears twice after all #INCLUDEd files have been expanded, or if the DECLARE does not match the procedure header, or if you #INCLUDE the same things twice.

In the help file there is a tip to find these things:

Make the first line of your "main" program the procedure/UDT/Equate or whatever which is causing you problems; now when you compile, the error will occur on the first "actual" definition of same. That should make it somewhat easier to find the duplicates.

[Jeff Blakeney]

Personally, I only use DECLARE statements to declare procedures that are in DLLs. I never use them to DECLARE procedures that are in my current source file or any of the files it includes. Even before PB added forward referencing like it has now, I'd simply move my procedure to a location before it was referenced rather than write a DECLARE for it.

In your case, I'd simply put whatever SUB/FUNCTIONS you want into as many include files as you want and add one or more INCLUDE statements to the beginning of your main source file to include those files and not worry about it. No need to DECLARE any of the procedures that are in your main source or the include files.

[Chris Holbrook]

I'd simply move my procedure to a location before it was referenced rather than write a DECLARE for it.

Glad to hear someone else does that too! Former Pascal programmer perchance?

I'd simply put..No need to DECLARE any of the procedures that are in your main source or the include files.

Agree 100%

[Michael Mattias]

No need to DECLARE any of the procedures that are in your main source or the include files

No, no need to, but I like to.....

...especially for procedures not in the "main" source file. That way I can find the correct call syntax without switching which file is the current file in the IDE... and because all the DECLAREs are together near the top, I can 'bookmark' that section and get there quickly.

MCM

[Chris Holbrook]

No, no need to, but I like to.....

...especially for procedures not in the "main" source file. That way I can find the correct call syntax without switching which file is the current file in the IDE... and because all the DECLAREs are together near the top, I can 'bookmark' that section and get there quickly.

MCM

Another reason to write F2plus, showing the whole of the function header as mentioned here, would give the laziest programmer (myself) the same info on a keypress, without creating a Declare.

[Michael Mattias]

> Another reason to write F2plus, showing the whole of the function header...

Why not simply a context menu on the listview item of the "F2" screen....

----------------------------
  Copy function header  
  Copy function header as DECLARE 
  Copy entire function  
  ----------------------------

???

[Chris Holbrook]

> Another reason to write F2plus, showing the whole of the function header...

Why not simply a context menu on the listview item of the "F2" screen....

----------------------------
  Copy function header  
  Copy function header as DECLARE 
  Copy entire function  
  ----------------------------

???

Not a bad plan. I also thought about using a tooltip but that would not serve for functions of any length. Also to be able to see all the code is nice. Keyword coloring to match the PB conventions is also necessary - my proto does not do this: http://www.powerbasic.com/support/pb...213#post323213

[Michael Mattias]

What I've never seen any IDE do well is "get me the comments" ; when I'm looking to call a procedure what I really want is the function header with an explanation of the parameters.... as in ...

' -------------------------------------------
' ADOExecuteSelectonConn
' -------------------------------------------
'  oConn [in]    Open Connection object. Not modified here.
'                (Can use function ADOConnectToDb ConnectToDb to get the object and open it
'  szSQL [in]  = Statement to be executed. Not modified here
'  sRow() [i-o] on success, contains array of (col,row) with column names in row zero
'               and data in coumns 1-n (i.e column zero is never used)
'  sErrMsg (out] If not success, contains error text
#IF %PB_EXE
  FUNCTION ADOExecuteSelectOnConn (oConn AS INT__Connection , szSQL AS ASCIIZ, _
                           sRow() AS STRING, sErrMsg AS STRING) PRIVATE AS LONG
#ELSE
  FUNCTION ADOExecuteSelectonConn ALIAS "ADOExecuteSelectOnConn"  (oconn AS INT__Connection, szSQL AS ASCIIZ, _
                           sRow() AS STRING, sErrMsg AS STRING) EXPORT AS LONG
#ENDIF
...

END FUNCTION

I pretty much always end up doing a "Go to" the function of interest and scrolling up to see what the heck I am supposed to be passing it and what it returns

MCM

[Chris Holbrook]

Good point. I had considered that too but it must have been abandoned en route. Assuming that the function is well and truly over when the END FUNCTION/END SUB arrives. Nobody would be so perverse as to post comments after a function, now would they? A feature for Version 2.

[Michael Mattias]

After Futher Review....

Borje Hagsten brought along comments - defined as "all comment lines IMMEDIATELY preceding the procedure header" - in his "copycat" utility.

That utility does not do a "go to" but it does do a "copy procedure from file 1 to file 2"

MCM

[Jeff Blakeney]

Glad to hear someone else does that too! Former Pascal programmer perchance?

No. I've barely touched Pascal. In high school, the first language I learned was Waterloo Structured BASIC that I used on a Commodore PET and went on from there to use the BASIC on a TRS-80 model I. Then we got a TRS-80 Colour Computer at home and I used the BASIC on it. Then went on to use the BASIC on Commodore CBM 8032 machines at my second high school (I was a military brat) and ended up getting an Apple IIe so learned Applesoft BASIC and then 6502 assembly. In college I was taught 8086 assembly before they taught us C because assembly was easier to learn and then learned 6809 assembly in a later semester. This was an Electronics Technology course. I learned 65816 assembly when I upgraded my Apple IIe to an Apple IIgs. I've fiddled with other languages like pascal, C, perl, VB and a few others.

I've worked with my brother on and off doing software development for years and he had PB/DOS, then went to PB/DLL and then to PB/WIN and helping he is when I fell in love with this language. That's why I finally had to buy my own copy of PB. My brother hasn't upgrade since version 7 I believe and I wanted to be able to code for myself rather than just for him.

It was my working with my brother on earlier versions of PB that got me moving functions before they were referenced so I didn't need to write a DECLARE.

[Guy Dombrowski]

Comodore Pet ......

Does that means that you are pretty old ???

[Tom Hanlin]

I believe the word is "venerable". I go back a ways, myself, but I only know of Waterloo BASIC by hearsay.

Don't call my baby a Trash-80.

[Brice Manuel]

Don't call my baby a Trash-80.

Amen

[Jeff Blakeney]

Does that means that you are pretty old ???

That depends on whether you think 42 is old.

Personally, I think it is kind of neat that I am currently the answer to life, the universe and everything. (That's a Douglas Adams' Hitchhiker's Guide to the Galaxy reference.)

[Guy Dombrowski]

Not old at all

Well Jeff,

42 is very young as my next birthday will put me with the 70 old geezers.
But not to worry, in my family, nobody dies before 94 so I intend to stick around a while yet.

[Doug Ingram]

Just an update...

Turns out my main issue was leaving the type identifier off my variables.
While that worked fine in the single file, the includes needed to have the "% # &" added to each variable name.

That was absolutely the issue here. My duplicate definitions were not a result of declaring the sub, but not having the variables in the sub named as passed.

No more laziness for me. I'm adding the identifiers.