You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
Is there any folder in which one may put .INC files so they can
be included in a .BAS file when it is compiled, irrespective of
which folder it may be in?
Brian.
Power Basic for Dos (3.2 and 3.5, anyhow) had such a directory, but as far as I can see PBDLL60 does'nt.
You can place them in the directory where the .BAS file resides. If you have common .INC files (to use for more applications) then you may locate them in the Winapi-directory.
An alternate way is to use a full path name with the metastatement #INCLUDE.
Egbert Zijlema, journalist and programmer (zijlema at basicguru dot eu) http://zijlema.basicguru.eu *** Opinions expressed here are not necessarily untrue ***
Originally posted by Brian Reynolds: Is there any folder in which one may put .INC files so they can
be included in a .BAS file when it is compiled, irrespective of
which folder it may be in?
Brian.
Any folder you like, Brian. You just need to specify that directory with the switch /I
Here's a quote from the PB/CC helpfile, Chapter "Running PB/CC"
Run PBCC.EXE from the DOS prompt using a command line with the following syntax:
PBCC [/Ipath] [/L] [/Q] FileName
where FileName is the name of the source file to compile. If you just type PBCC (omitting FileName), you'll get a dialog box asking for the name of the file to compile.
If FileName does not have an extension, PB/CC assumes .BAS. If you don't want the file you're compiling to have an extension, you must append a period (.) to the end of FileName.
The PB/CC compiler is a 16-bit Windows application. Your source code files can not use long filenames, nor can you use long filenames when specifying a path. For example, if your source is located in “C:\Program Files\MyProject\myfile.bas”, you must specify the path as “c:\progra~1\myproj~1\myfile.bas” (case is not significant).
It is important to note that programs you compile are true 32-bit Windows applications and will support long filenames. All Basic language statements that use filenames (OPEN, DIR$, NAME, KILL, etc…) will support long filenames. Only meta-statements such as #INCLUDE and #RESOURCE do not support long filenames as these are interpreted at compile time.
Include
The /I command line option provides the compiler with a search path when looking for #INCLUDE and #RESOURCE files. See #INCLUDE and #RESOURCE for more details.
Log
The /L command line option causes the compiler to generate a log file with all of the compile results, including error code and error line number if an error occurs during compile time.
Quiet
The /Q command line option causes the compiler to not display a message box when compiling is finished. This should only be used with the /L option.
By starting the folder list with a period instructs the compiler to search in the current folder before looking in the other paths. This gives you the ability to use a 'local' copy of an INC file that is also present in one of the other folders - the compiler will use the first matching file it encounters. Without the period at the start of the list, the folders in the list are searched *before* the current folder.
Egbert Zijlema, journalist and programmer (zijlema at basicguru dot eu) http://zijlema.basicguru.eu *** Opinions expressed here are not necessarily untrue ***
Not mentioned in the help file. Thanks for letting us know, Lance.
Hm, does the same apply to the "Options" dialog in PBedit?
Another thing: Help file states "[/Ipath]", but there should be a
space inserted between I and Path there, "[/I path]", otherwise it
will fail. At least it did for me when I wrote the command line
for my own editor..
I stand corrected. Yes, *with* space it failed, without it worked.
Need to upgrade my memory chips. 4 KB between the ears obviously
isn't enough for today's needs..
What I have been doing was to set up a new folder for each new
programme and I found I had to put all my .INC files into that
folder. As you may imagine, I have the same .INC files in a large
number of folders on my computer, having to copy the .INC files
into a folder everytime I start a new programme.
I tried out what Lance advised, using a folder called INCfiles
in which to put my .INC files and, on a desktop shortcut, put:
"C:\PBDLL60\Bin\Pbedit.exe /I.;C:\INCfiles"
but this didn't work so I entered another part of Lance's
recommendation, putting all my .INC files into the winapi folder:
"C:\PBDLL60\Bin\Pbedit.exe /I.;C:\PBDLL60\WINAPI"
and this works perfectly. There are no .INC files in the folder I
opened to use for my new code.
Thanks to everyone. I can now eliminate a large number of
duplicated .INC files from my computer.
PBedit? Guess a typo - should be PBDLL.EXE, since that is compiler's
name.
Another thing: Looking back at the code I wrote for own editor, I see
one thing with the way log files list errors in code. The code file
may have a long file name, but PBDLL only uses short names, so the
log file will list error in file with short name.
Kind of confusing, especially in cases where you have several files
with similar names in same folder. Example: let's say you have two
files in same folder, "This is test1.bas" and "This is test2.bas".
Now, if you compile "This is test2.bas" first, eventual error message
will tell you an error occurred in "THISIS~1.BAS" and its log file
will be named "THISIS~1.LOG".
If you compile "This is test1.bas" after that, ev. error message will
tell you an error occurred in "THISIS~2.BAS", etc. I know this behaviour
is caused by extremely idiotic MS way to handle long/short file names,
but work-arounds can be done even in 16-bit app's, and PBedit definitely
could fix this after compile is done - at least when it comes to showing
correct long name in result. At least that's what I have done in my own code..
Guess it won't matter in next version if new compiler becomes 32-bit
all the way. Then again, who knows when new version will be released,
so maybe worth to fix and release a minor update of editor after all?
I mean, the list of things that could need a minor fix must be pretty
long by now and still, since most is simple things, it shouldn't take
more than a day or two to fix them all..
PBEDIT.EXE is the IDE (editor and debugger), PBDLL.EXE is the actual compiler. Internally, PBEDIT.EXE uses SHELL to launch PBDLL.EXE to perform compilation of a file.
PBEDIT.EXE does not accept the command-line switches we have discussed above (/I, etc). PBEDIT.EXE does accept a command-line parameter that specifies a source code file to open, for example, 'PBEDIT.EXE myapp.bas'.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Comment