Page 1 of 3
Program Layout
Posted: Tue Jun 09, 2009 4:54 am
by Hot Pockets
Does anyone have a program layout. Like where do you place the Constants, Declare statements & or procedures.Do all the Declare statements go before the procedures. I wrote a program which shows a BMP file and another having a Menu. When I ran them only the BMP was displayed. If I remarked out the BMP program then the menu would work. Why did I have to remark out 1 of them to get the other to work?
Posted: Tue Jun 09, 2009 7:04 am
by rrpl
You'll find it easier to get help to solve your problem if you post the portion of your code that you are having problems with.
Generally PB can handle things laid out all over the place (I'm guilty!!), but its best generally to declare things up front.
From the PB help file:
Syntax
Declare[.<type>] name(<variable1[.<type>]> [, <variable2[.<type>]>, ...])
Description
Sometimes a procedure need to call another procedure which isn't declared before its definition. This is annoying because the compiler will complain 'Procedure <name> not found'. Declare can help in this particular case by declaring only the header of the procedure. Nevertheless, the Declare and real Procedure declaration must be identical (including the correct type).
Probably a good idea to download this beginners guide from the link underneath to begin with.
http://www.purebasic.fr/english/viewtopic.php?t=37059
Posted: Tue Jun 09, 2009 7:49 am
by pdwyer
Like a skeleton app you mean?
Posted: Tue Jun 09, 2009 8:35 am
by Trond
I don't use Declare unless it's absolutely necessary. Placing the procedures in the correct order is usually sufficient.
I think it's common to organize the program something like this:
1. Enumerations and constants
2. Structures
3. Global variable declarations
4. Procedures
5. Main program code (or code to call procedure with program code)
6. DataSections
Posted: Tue Jun 09, 2009 8:52 am
by pdwyer
Trond wrote:I don't use Declare unless it's absolutely necessary. Placing the procedures in the correct order is usually sufficient.
Why? Is there some problem with having unnecessarily declares?
I always have declares for all procs, helps me structure the code like a little contents section. Also, I've noticed (and it was discussed once) that the position of a proc in the source can effect it's performance surprisingly enough so you may want to take advantage of that.
Is there some benefit to playing with proc order for dependancy purpose?
Posted: Tue Jun 09, 2009 9:10 am
by Trond
pdwyer wrote:Trond wrote:I don't use Declare unless it's absolutely necessary. Placing the procedures in the correct order is usually sufficient.
Why? Is there some problem with having unnecessarily declares?
Yes, they're boring to write.
Posted: Tue Jun 09, 2009 9:30 am
by idle
what Trond says is right, I can't be arsed declaring statement either but then I'm a lazy git!
Posted: Tue Jun 09, 2009 10:36 am
by PB
> Placing the procedures in the correct order is usually sufficient
Usually is the right word. Sometimes that's just impossible, when procedures
rely on other procedures and one simply can't go before another.
Posted: Tue Jun 09, 2009 10:46 am
by pdwyer
aren't you guys part of the pro enable explicit lobby though?
Posted: Tue Jun 09, 2009 11:07 am
by Kale
I never use declare either and never had any procedure order issues.
Posted: Tue Jun 09, 2009 12:22 pm
by pdwyer
Are we using the same compiler?
Posted: Tue Jun 09, 2009 12:28 pm
by Trond
PB wrote:> Placing the procedures in the correct order is usually sufficient
Usually is the right word. Sometimes that's just impossible, when procedures
rely on other procedures and one simply can't go before another.
I know, then I use declares. And sometimes the procedure order becomes very illogical without declares, so then I may use declare as well.
Kale, here is a (bad) example where you have to use declare:
Code: Select all
Declare Odd(Num.i)
Procedure Even(Num.i)
If Num = 0
ProcedureReturn 1
Else
ProcedureReturn Odd(Num-1)
EndIf
EndProcedure
Procedure Odd(Num.i)
If Num = 0
ProcedureReturn 0
Else
ProcedureReturn Even(Num-1)
EndIf
EndProcedure
Debug Even(0)
Debug Even(1)
Debug Even(2)
Debug Even(3)
Debug "--"
Debug Odd(0)
Debug Odd(1)
Debug Odd(2)
Debug Odd(3)
Re: Program Layout
Posted: Tue Jun 09, 2009 12:37 pm
by Kaeru Gaman
Hot Pockets wrote:I wrote a program which shows a BMP file and another having a Menu. When I ran them only the BMP was displayed. If I remarked out the BMP program then the menu would work. Why did I have to remark out 1 of them to get the other to work?
you wrote TWO programs? why?
perhaps you're misinterpreting the nature of procedural programming?
all I can say so far is
for more analysis, we need more information.
Program Layout
Posted: Tue Jun 09, 2009 4:17 pm
by Hot Pockets
Kaeru:
Why Indeed? I should of said when I combined them into 1 program only 1 ran.
Trend:
Thanks for answering my questionvery well and to the point. May I have a little more advice. Would it work as well if I reversed the order of items 4 and 5. (Just an idea.)
Others:
I downloaded that most excellent book awhile back and have printed all 336 pages into 2 volumes. I will look thru that again to see if there is something like Trend's accurate synopsis. It may take me several days to do it tho!
ALL:
Thank you for your efforts!
Posted: Tue Jun 09, 2009 4:34 pm
by Kaeru Gaman
Hot Pockets wrote:Kaeru:
Why Indeed? I should of said when I combined them into 1 program only 1 ran.
did you say this?
problem is, when you don't say something, the others can't know something.
I could be guessing around and presume, because you said "two programs"
you also wrote two eventloops instead of one...
sounds like "misinterpreting the nature of procedural programming"
whatever it was, it clearly was "ur doin it wrong"....
the others gave you some good overview answering to your general question...
but it wasn't any solution to your problem "bmp shows, menu doesn't show".
why?
surely because you didn't give the least hint what caused the problem.
also mind this:
rrpl wrote:You'll find it easier to get help to solve your problem if you post the portion of your code that you are having problems with.