Loading a project (.MAK stalls) - help!

[budgie]

When I attempt to load an existing project into the "IDE" (File->OpenProject)
the code window remains blank and the status line states: "Loading and Parsing".
However it stalls at this point. Assuming that there is something errant in
what was most recently saved, how can I determine the cause if I can't see the
project? (Other projects load and run properly - just this particular one has
the problem.)

[Karl E. Peterson]

Post by budgie
When I attempt to load an existing project into the "IDE"
(File->OpenProject) the code window remains blank and the status line
states: "Loading and Parsing". However it stalls at this point.
Assuming that there is something errant in what was most recently
saved, how can I determine the cause if I can't see the project?
(Other projects load and run properly - just this particular one has
the problem.)

MAK files are raw text. Open it in a text editor, and try recreating the
project from scratch, by loading one module at a time until the problem
surfaces. At that point, you'll at least know where the problem lies.

[budgie]

Post by Karl E. Peterson

Post by budgie
When I attempt to load an existing project into the "IDE"
(File->OpenProject) the code window remains blank and the status line
states: "Loading and Parsing". However it stalls at this point.
Assuming that there is something errant in what was most recently
saved, how can I determine the cause if I can't see the project?
(Other projects load and run properly - just this particular one has
the problem.)

MAK files are raw text. Open it in a text editor, and try recreating the
project from scratch, by loading one module at a time until the problem
surfaces. At that point, you'll at least know where the problem lies.

Interestingly, I chose to create the project afresh by loading each of the files
that had formed the problem project. Worked fine, project now back on track.

Which leaves me wondering - if all the .frm and .bas files from the "problem"
project are now able to form a new project (aka .MAK file) then it suggests
*they* weren't the problem. Which leaves .... the original .mak file. Yet (as
you correctly pointed out) a .mak file is only an ascii list of the .frm/.bas
elements, so how can this be?

I think I'll stop pondering - it gives me a sore head.

[Karl E. Peterson]

On Fri, 24 Feb 2006 09:13:02 -0800, "Karl E. Peterson"

Post by Karl E. Peterson

Post by budgie
When I attempt to load an existing project into the "IDE"
(File->OpenProject) the code window remains blank and the status
line states: "Loading and Parsing". However it stalls at this point.
Assuming that there is something errant in what was most recently
saved, how can I determine the cause if I can't see the project?
(Other projects load and run properly - just this particular one has
the problem.)

MAK files are raw text. Open it in a text editor, and try
recreating the project from scratch, by loading one module at a time
until the problem surfaces. At that point, you'll at least know
where the problem lies.

Interestingly, I chose to create the project afresh by loading each
of the files that had formed the problem project. Worked fine,
project now back on track.
Which leaves me wondering - if all the .frm and .bas files from the
"problem" project are now able to form a new project (aka .MAK file)
then it suggests *they* weren't the problem. Which leaves .... the
original .mak file. Yet (as you correctly pointed out) a .mak file
is only an ascii list of the .frm/.bas elements, so how can this be?
I think I'll stop pondering - it gives me a sore head.

Boy, I dunno! Suppose VBDOS is actually demanding a Cntl-Z character at the
EOF?

[budgie]

Post by Karl E. Peterson

On Fri, 24 Feb 2006 09:13:02 -0800, "Karl E. Peterson"

Post by Karl E. Peterson

Post by budgie
When I attempt to load an existing project into the "IDE"
(File->OpenProject) the code window remains blank and the status
line states: "Loading and Parsing". However it stalls at this point.
Assuming that there is something errant in what was most recently
saved, how can I determine the cause if I can't see the project?
(Other projects load and run properly - just this particular one has
the problem.)

MAK files are raw text. Open it in a text editor, and try
recreating the project from scratch, by loading one module at a time
until the problem surfaces. At that point, you'll at least know
where the problem lies.

Interestingly, I chose to create the project afresh by loading each
of the files that had formed the problem project. Worked fine,
project now back on track.
Which leaves me wondering - if all the .frm and .bas files from the
"problem" project are now able to form a new project (aka .MAK file)
then it suggests *they* weren't the problem. Which leaves .... the
original .mak file. Yet (as you correctly pointed out) a .mak file
is only an ascii list of the .frm/.bas elements, so how can this be?
I think I'll stop pondering - it gives me a sore head.

Boy, I dunno! Suppose VBDOS is actually demanding a Cntl-Z character at the
EOF?

No, I even checked character by character and the two .MAK files match.

I've even reinstalled (sic) VBDOS in case it had corrupted.

On another tack, I'm in the process of converting a QB45 legacy app into VBDOS,
and it is *years* since I did any VBDOS so I'm more than a little challenged in
the task. (Before anyone asks, this HAS to be VBDOS as distinct from any
Windoze version, as it has to run on avariety of machines including some 286).

In later versions I can define variables as global, but in VBDOS I can't seem to
find a way to do it. COMMON SHARED simply doesn't cut it. I need an integer
array to be common to all modules. There are currently four forms in use (I
expect about 12 when the project is completed). Most procedures associated with
the controls on those forms live under the corresponding forms, and there is
(currently) one .BAS module that holds a number of common SUBs. So I have SUBs
in several forms and one .BAS module that all need to see common variables.

While I can COMMON SHARED A () AS INTEGER there doesn't appear to be a way to
use DIM A(1234) AS INTEGER without tripping a complaint about executable code
in non-permitted locations. (To save repetition and the risk of getting COMMON
SHARED variable lists out of step, they are in an INCLUDE file.)

Any suggestions as to how to "globalise" my variable list including the integer
array?

[John Kane]

In article <***@4ax.com>, ***@privacy.net
says...

Post by budgie
While I can COMMON SHARED A () AS INTEGER there doesn't appear to be a way to
use DIM A(1234) AS INTEGER without tripping a complaint about executable code
in non-permitted locations. (To save repetition and the risk of getting COMMON
SHARED variable lists out of step, they are in an INCLUDE file.)
Any suggestions as to how to "globalise" my variable list including the integer
array?

I use this format quite a lot...

DIM A(1234) AS INTEGER
COMMON SHARED A() AS INTEGER

[budgie]

Post by John Kane
says...

Post by budgie
While I can COMMON SHARED A () AS INTEGER there doesn't appear to be a way to
use DIM A(1234) AS INTEGER without tripping a complaint about executable code
in non-permitted locations. (To save repetition and the risk of getting COMMON
SHARED variable lists out of step, they are in an INCLUDE file.)
Any suggestions as to how to "globalise" my variable list including the integer
array?

I use this format quite a lot...
DIM A(1234) AS INTEGER
COMMON SHARED A() AS INTEGER

I will certainly try that order. When I use COMMON SHARED and then DIM() ina
module, I don't rip a complaint - but when I do that in an INCLUDe file I do get
the complaint. It appears that VBDOS sees a DIM A() after a COMMON SHARED A()
as executable - re-DIMming maybe? The order may show what's really going on.

Thanks for your input.

[A***@NOT.AT.Arargh.com]

Post by budgie

Post by John Kane
says...

Post by budgie
While I can COMMON SHARED A () AS INTEGER there doesn't appear to be a way to
use DIM A(1234) AS INTEGER without tripping a complaint about executable code
in non-permitted locations. (To save repetition and the risk of getting COMMON
SHARED variable lists out of step, they are in an INCLUDE file.)
Any suggestions as to how to "globalise" my variable list including the integer
array?

I use this format quite a lot...
DIM A(1234) AS INTEGER
COMMON SHARED A() AS INTEGER

I will certainly try that order. When I use COMMON SHARED and then DIM() ina
module, I don't rip a complaint - but when I do that in an INCLUDe file I do get
the complaint. It appears that VBDOS sees a DIM A() after a COMMON SHARED A()
as executable - re-DIMming maybe? The order may show what's really going on.

to use these two, in this order, you need a "REM $STATIC" before

DIM A(1234) AS INTEGER
COMMON SHARED A() AS INTEGER



in this order, you need a "REM $DYNAMIC", in front

COMMON SHARED A() AS INTEGER
DIM A(1234) AS INTEGER


These are the rules that I discovered (if I got them correct) for PDS
7.10, which should apply to VBDOS.


Don't ask me, ask MS, they wrote it.


I wrote BCET, which mostly doesn't care.

[budgie]

Post by A***@NOT.AT.Arargh.com

Post by budgie

Post by John Kane
says...

Post by budgie
While I can COMMON SHARED A () AS INTEGER there doesn't appear to be a way to
use DIM A(1234) AS INTEGER without tripping a complaint about executable code
in non-permitted locations. (To save repetition and the risk of getting COMMON
SHARED variable lists out of step, they are in an INCLUDE file.)
Any suggestions as to how to "globalise" my variable list including the integer
array?

I use this format quite a lot...
DIM A(1234) AS INTEGER
COMMON SHARED A() AS INTEGER

I will certainly try that order. When I use COMMON SHARED and then DIM() ina
module, I don't rip a complaint - but when I do that in an INCLUDe file I do get
the complaint. It appears that VBDOS sees a DIM A() after a COMMON SHARED A()
as executable - re-DIMming maybe? The order may show what's really going on.

to use these two, in this order, you need a "REM $STATIC" before
DIM A(1234) AS INTEGER
COMMON SHARED A() AS INTEGER
in this order, you need a "REM $DYNAMIC", in front
COMMON SHARED A() AS INTEGER
DIM A(1234) AS INTEGER

I actually switched to the DIM/COMMON SHARED order as John Kane suggested, and
now there are no more complaints about executable code. This reinforces my view
that a DIM after a C.S. is treated somehow as executable, maybe as a REDIM?

And not a $STATIC or $DYNAMIC declaration anywhere. Maybe not good coding, but
it's so many years since I would ever have claimed to do "good coding" that I
now only care about results.

Certainly though a static array is what I require.

Post by A***@NOT.AT.Arargh.com
These are the rules that I discovered (if I got them correct) for PDS
7.10, which should apply to VBDOS.
Don't ask me, ask MS, they wrote it.

Frankly I don't think they had a clue when they released the product. Nowadays
they would probably deny it ever existed.

Post by A***@NOT.AT.Arargh.com
I wrote BCET, which mostly doesn't care.

[John Kane]

In article <***@4ax.com>, ***@privacy.net
says...

Post by budgie

Post by A***@NOT.AT.Arargh.com
in this order, you need a "REM $DYNAMIC", in front
COMMON SHARED A() AS INTEGER
DIM A(1234) AS INTEGER

I actually switched to the DIM/COMMON SHARED order as John Kane suggested, and
now there are no more complaints about executable code. This reinforces my view
that a DIM after a C.S. is treated somehow as executable, maybe as a REDIM?
And not a $STATIC or $DYNAMIC declaration anywhere. Maybe not good coding, but
it's so many years since I would ever have claimed to do "good coding" that I
now only care about results.
Certainly though a static array is what I require.

Post by A***@NOT.AT.Arargh.com
These are the rules that I discovered (if I got them correct) for PDS
7.10, which should apply to VBDOS.
Don't ask me, ask MS, they wrote it.

Frankly I don't think they had a clue when they released the product. Nowadays
they would probably deny it ever existed.

Post by A***@NOT.AT.Arargh.com
I wrote BCET, which mostly doesn't care.

I never use either of the Metacommands. I think STATIC is by default.
This is from the Help...

=3F For static arrays, dimensions must be set with integer-constant
subscripts in a DIM statement preceding a COMMON statement

=3F For dynamic arrays, dimensions must be set in a later DIM or REDIM
statement

For the latter, all COMMONs must come before the DIMs or REDIMs,
otherwise you get the dreaded '...must precede executable statements'
message.

[budgie]

Post by John Kane
says...

Post by budgie

Post by A***@NOT.AT.Arargh.com
in this order, you need a "REM $DYNAMIC", in front
COMMON SHARED A() AS INTEGER
DIM A(1234) AS INTEGER

I actually switched to the DIM/COMMON SHARED order as John Kane suggested, and
now there are no more complaints about executable code. This reinforces my view
that a DIM after a C.S. is treated somehow as executable, maybe as a REDIM?
And not a $STATIC or $DYNAMIC declaration anywhere. Maybe not good coding, but
it's so many years since I would ever have claimed to do "good coding" that I
now only care about results.
Certainly though a static array is what I require.

Post by A***@NOT.AT.Arargh.com
These are the rules that I discovered (if I got them correct) for PDS
7.10, which should apply to VBDOS.
Don't ask me, ask MS, they wrote it.

Frankly I don't think they had a clue when they released the product. Nowadays
they would probably deny it ever existed.

Post by A***@NOT.AT.Arargh.com
I wrote BCET, which mostly doesn't care.

I never use either of the Metacommands. I think STATIC is by default.

That would explain the observed behaviour.

Post by John Kane
This is from the Help...
=3F For static arrays, dimensions must be set with integer-constant
subscripts in a DIM statement preceding a COMMON statement
=3F For dynamic arrays, dimensions must be set in a later DIM or REDIM
statement

Aaaahhh - if only (famous last words?) I had actually looked under STATIC and
DYNAMIC. Sometimes their HELP system is useful and well-indexed. VBDOS is
certainly not in that category.

Post by John Kane
For the latter, all COMMONs must come before the DIMs or REDIMs,
otherwise you get the dreaded '...must precede executable statements'
message.

[buck huffman]

I seem to remember running into the exact same brick wall about 12 or 13 years
ago. as I recall, "DIM SHARED" was the easiest way out that I found. like this:

DIM SHARED a(1234) AS INTEGER

but that was a long time ago, may just be the altzheimers talking.

buck

[A***@NOT.AT.Arargh.com]

Post by buck huffman
I seem to remember running into the exact same brick wall about 12 or 13 years
DIM SHARED a(1234) AS INTEGER
but that was a long time ago, may just be the altzheimers talking.

That's fine for ONE module (source file)

[buck huffman]

Post by A***@NOT.AT.Arargh.com
That's fine for ONE module (source file)

I wrote a test program to verify your statement and you
are absolutely correct(I apologize for giving erroneous
information :( ). but in my research to write that test
program i ran across a vague remark in the reference manual
which states "The REDIM statement is often used in the
initial Form_Load event procedure to define the dimensions
of an array shared between modules."(page 337 under Redim
Statement - remarks). This statement comes with no further
explanations or examples leaving you to guess as to what it
means, in terms of actual implementation, on your own.

Also in my research, I looked up my old code that I spoke
of before and found that I abandoned the attempt at using
global arrays and just shared the info through a temporary
file, what a miserable compromise :( . I am amazed that I
was able to find that code after all these years. Should
have deleted it long ago (hide the evidence, you know).
Anyway, I'm going to fiddle with the redim statement now
and I'll post here if it produces anything useful.

buck

[A***@NOT.AT.Arargh.com]

Post by buck huffman

Post by A***@NOT.AT.Arargh.com
That's fine for ONE module (source file)

I wrote a test program to verify your statement and you
are absolutely correct(I apologize for giving erroneous
information :( ). but in my research to write that test
program i ran across a vague remark in the reference manual
which states "The REDIM statement is often used in the
initial Form_Load event procedure to define the dimensions
of an array shared between modules."(page 337 under Redim
Statement - remarks). This statement comes with no further
explanations or examples leaving you to guess as to what it
means, in terms of actual implementation, on your own.

VBDOS 1.0 of VB 1.0? I don't remember any books for VBDOS. Oh, wait,
there they are, sitting on the shelf where I put them 10 or 15 years
ago. Three of them.

Anyway, I think that some of the rules may change for VBDOS. I have
never really used it. I only ever got it because it supposedly had
support for 386 instructions. But, that support was limited, it
doesn't have near strings, or protected mode . . . The IDE kinda
sucks, except that it does support the "_" (underline) char in
variable names, and the long line support is somewhat better.

I do use common shared dynamic arrays in PDS 7.1.

Part of an include file from a multi source file project:
...
COMMON SHARED LinkPtr()
REDIM SHARED LinkPtr(MaxKey)
...

The include file is in every source, however, the REDIM only gets
executed in the main module. (Works the same way in BCET)
There is no REM $STATIC or REM $DYNAMIC in the program.
"MaxKey" is a CONST, since I don't like 'magic' numbers.

Post by buck huffman
Also in my research, I looked up my old code that I spoke
of before and found that I abandoned the attempt at using
global arrays and just shared the info through a temporary
file, what a miserable compromise :( . I am amazed that I
was able to find that code after all these years. Should
have deleted it long ago (hide the evidence, you know).
Anyway, I'm going to fiddle with the redim statement now
and I'll post here if it produces anything useful.

The other way is to stick everything in a large TYPE, DIM it once as
common shared, and just reference it. Assumming you have the memory.

[Stephen Howe]

Post by A***@NOT.AT.Arargh.com
Anyway, I think that some of the rules may change for VBDOS.

None that I know of.

Post by A***@NOT.AT.Arargh.com
I only ever got it because it supposedly had support for 386 instructions.

I have never really studied the difference between /G2 and /G3.
Any 386 instructions are unlikely to be invoving 32-bit registers but
instead be whatever Intel did in adding new opcodes for 16-bit instructions.
Branch jumps of more than 128 bytes and a 3rd form of IMUL springs to mind.

Post by A***@NOT.AT.Arargh.com
But, that support was limited, it
doesn't have near strings, or protected mode . . . The IDE kinda
sucks, except that it does support the "_" (underline) char in
variable names, and the long line support is somewhat better.

It also allows FUNCTIONs to return TYPE...END TYPES. That was not present in
PDS 7.1

Stephen Howe

[A***@NOT.AT.Arargh.com]

On Wed, 8 Mar 2006 12:09:15 -0000, "Stephen Howe"

Post by Stephen Howe

Post by A***@NOT.AT.Arargh.com
Anyway, I think that some of the rules may change for VBDOS.

None that I know of.

Post by A***@NOT.AT.Arargh.com
I only ever got it because it supposedly had support for 386 instructions.

I have never really studied the difference between /G2 and /G3.
Any 386 instructions are unlikely to be invoving 32-bit registers but
instead be whatever Intel did in adding new opcodes for 16-bit instructions.
Branch jumps of more than 128 bytes and a 3rd form of IMUL springs to mind.

I never really did, either. I have a very vauge impression that about
the only thing that /G3 did was use 32 bit regs for some operations on
LONGs. Functions returning LONG still return it in dx:ax. There is
no 386 library support.

Post by Stephen Howe

Post by A***@NOT.AT.Arargh.com
But, that support was limited, it
doesn't have near strings, or protected mode . . . The IDE kinda
sucks, except that it does support the "_" (underline) char in
variable names, and the long line support is somewhat better.

It also allows FUNCTIONs to return TYPE...END TYPES. That was not present in
PDS 7.1

Oh?

TYPE RECT_Type
Left AS LONG
Top AS LONG
Right AS LONG
Bottom AS LONG
END TYPE

FUNCTION CheckModifyState (BYVAL hWin) as RECT_Type

(this is in a boring little box when I try to run it)
Expected: INTEGER or LONG or SINGLE or DOUBLE or CURRENCY or STRING
+------+ +------+
¦ OK ¦ ¦ Help ¦
+------+ +------+
END FUNCTION


And I have the Professional Edition.

[Stephen Howe]

Post by A***@NOT.AT.Arargh.com
FUNCTION CheckModifyState (BYVAL hWin) as RECT_Type
(this is in a boring little box when I try to run it)
Expected: INTEGER or LONG or SINGLE or DOUBLE or CURRENCY or STRING
+------+ +------+
Š OK Š Š Help Š
+------+ +------+
END FUNCTION

Did you have the matching DECLARE FUNCTION?
There is no forward declaration in BASIC for these things.

Stephen Howe

[A***@NOT.AT.Arargh.com]

On Wed, 8 Mar 2006 20:47:02 -0000, "Stephen Howe"

Post by Stephen Howe

Post by A***@NOT.AT.Arargh.com
FUNCTION CheckModifyState (BYVAL hWin) as RECT_Type
(this is in a boring little box when I try to run it)
Expected: INTEGER or LONG or SINGLE or DOUBLE or CURRENCY or STRING
+------+ +------+
¦ OK ¦ ¦ Help ¦
+------+ +------+
END FUNCTION

Did you have the matching DECLARE FUNCTION?
There is no forward declaration in BASIC for these things.

No, but:

<begin program>

TYPE RECT_Type
Left AS LONG
Top AS LONG
Right AS LONG
Bottom AS LONG
END TYPE

declare FUNCTION CheckModifyState (BYVAL hWin) as RECT_Type

FUNCTION CheckModifyState (BYVAL hWin) as RECT_Type

end function

<end program>

Gets the error on the declare.


There was a declare, without the as clause. A mismatched Declare and
Function should give a different error message: "Duplicate definition"

<begin program>
DECLARE FUNCTION CheckModifyState (BYVAL hWin) AS INTEGER

FUNCTION CheckModifyState (BYVAL hWin) AS LONG

END FUNCTION
<end program>


From VBDOS help screen for "function":

AS type Keyword used when declaring the data type of the value
returned by FUNCTION; may be INTEGER, LONG, SINGLE,
DOUBLE, CURRENCY, or STRING

[Stephen Howe]

Post by budgie
In later versions I can define variables as global, but in VBDOS I can't seem to
find a way to do it. COMMON SHARED simply doesn't cut it.

COMMON SHARED _DOES_ cut it.
What matters is where the corresponding DIM statement is, before or after.
You want a STATIC COMMON array not a DYNAMIC one, I think
It also matters if you are using RTM or libraries, named common blocks or
blank common blocks.

You have run into something I don't like about BASIC for DOS.
It is never clear where the first executable statement begins.
But you want to place all executable statements _after_
You also do not want _ANY_ executable statements in your include file
(because they are dead wood in secondary modules, they will never be
executed).

Post by budgie
(To save repetition and the risk of getting COMMON
SHARED variable lists out of step, they are in an INCLUDE file.)

Good. That is best practice.

Stephen Howe

[budgie]

On Tue, 28 Feb 2006 15:17:42 -0000, "Stephen Howe"

Post by budgie

Post by budgie
In later versions I can define variables as global, but in VBDOS I can't

seem to

Post by budgie
find a way to do it. COMMON SHARED simply doesn't cut it.

COMMON SHARED _DOES_ cut it.
What matters is where the corresponding DIM statement is, before or after.

See my reply to John Kane. Certainly the help files don't help with the order.

Post by budgie
You want a STATIC COMMON array not a DYNAMIC one, I think

Yes.

Post by budgie
It also matters if you are using RTM or libraries, named common blocks or
blank common blocks.

No named common blocks. Eventually will be compiled as a standalone. VBDOS
libraries are not expected to figure in the final mix.

Post by budgie
You have run into something I don't like about BASIC for DOS.
It is never clear where the first executable statement begins.

or whether a DIM A() after a COMMON SHARED A() is considered executable ....

Post by budgie
But you want to place all executable statements _after_

of course.

Post by budgie
You also do not want _ANY_ executable statements in your include file
(because they are dead wood in secondary modules, they will never be
executed).

That is the problem - the DIM after COMMON seems to be treated as executable
when in an INCLUDE file. Hey, maybe it is considered "executable" always - it
won't show as a problem in a module.

Post by budgie

Post by budgie
(To save repetition and the risk of getting COMMON
SHARED variable lists out of step, they are in an INCLUDE file.)

Good. That is best practice.

When I started migrating the project from QB45, I began looking for a GLOBAL
declaration capability for common/shared/whatever variables and arrays. Because
of the way this grew, each time I had to add another variable to the COMMON
SHARED declarations it was no real drama with just the first two modules - the
startup form and the following main menu/despatch form ("Ops Central"). As I
progressively added a couple more modules, the maintenance overhead encouraged
the transition to an INCLUDE file, but that's when the DIM problem reared its
head.

Thanks also for your input.

[Ileana Garza Tovar]

Post by budgie
When I attempt to load an existing project into the "IDE"
(File->OpenProject)
the code window remains blank and the status line states: "Loading and Parsing".
However it stalls at this point. Assuming that there is something errant in
what was most recently saved, how can I determine the cause if I can't see the
project? (Other projects load and run properly - just this particular one has
the problem.)

Normally, all the files in the project are stored in a "tokenized" format
that can cause some problems when the tokens are affected one way or
another. This tokenized format has some advantages: 1) Loads quicker, 2)
Makes easier to the environment to find references, 3) Needs little space in
disk and memory. The problem is that is very easy to load the code
incorrectly, to get problems with code or to have a mess.

The solution is to BE SURE to ALWAYS save your code in Text (ASCII) format.
In the Save File As window, be sure to select the "Text - Readable by other
programs" option. You can do this automatically if left selected this
option, so each file will be saved as Text. Your code will need some more
space (ridiculous in modern huge hard disks spaces: is the same to save an
1K file than a 512K file, both will get the same space in the hard disk).

¡Saludos!

Ileana Garza Tovar

[A***@NOT.AT.Arargh.com]

On Thu, 13 Apr 2006 09:14:00 -0500, "Ileana Garza Tovar"
<snip>

Post by Ileana Garza Tovar
Normally, all the files in the project are stored in a "tokenized" format
that can cause some problems when the tokens are affected one way or
1) Loads quicker,

Maybe, but on any system in the last 5 or 10 years, the difference
won't be really noticeable.

Post by Ileana Garza Tovar
2) Makes easier to the environment to find references,

No, that sort of thing is done after the load for either format.
Loading the text format tokenizes while loading.

Post by Ileana Garza Tovar
3) Needs little space in disk and memory.

Space in memory should be the same for either. As a test, I took a
217k basic prog (saved as text), and resaved it as binary. The new
size was 373k. Reloaded that (which was only slightly faster, if at
all), resaved as text, went back to 217k.

Post by Ileana Garza Tovar
The problem is that is very easy to load the code
incorrectly, to get problems with code or to have a mess.
The solution is to BE SURE to ALWAYS save your code in Text (ASCII) format.

Yes.

Post by Ileana Garza Tovar
In the Save File As window, be sure to select the "Text - Readable by other
programs" option. You can do this automatically if left selected this
option, so each file will be saved as Text. Your code will need some more
space (ridiculous in modern huge hard disks spaces: is the same to save an
1K file than a 512K file, both will get the same space in the hard disk).
¡Saludos!
Ileana Garza Tovar

[Ileana Garza Tovar]

Post by A***@NOT.AT.Arargh.com
On Thu, 13 Apr 2006 09:14:00 -0500, "Ileana Garza Tovar"

Post by Ileana Garza Tovar
1) Loads quicker,

Maybe, but on any system in the last 5 or 10 years, the difference
won't be really noticeable.

Yes, that's a note I forgot to point. Given the sizes of the codes for DOS,
is really unnoticeable the differences when saving in binary mode versus
text mode. The binary mode has demonstrated to yield to many unconquerable
problems in the code (same problems in QuickBASIC, and VB from versions 1 to
3). So historically, I detest the binary mode.

Post by A***@NOT.AT.Arargh.com

Post by Ileana Garza Tovar
2) Makes easier to the environment to find references,

No, that sort of thing is done after the load for either format.
Loading the text format tokenizes while loading.

Well, that doesn't change what I wrote previously. Although the token is
done while loading, when in binary mode all the tokenized references are
done and just jotted down by the environment. Nevertheless, there are some
situations when tokens went out of control and problems arise. So is better
to let the IDE to do all the tokenize work while loading.

Post by A***@NOT.AT.Arargh.com

Post by Ileana Garza Tovar
3) Needs little space in disk and memory.

Space in memory should be the same for either. As a test, I took a
217k basic prog (saved as text), and resaved it as binary. The new
size was 373k. Reloaded that (which was only slightly faster, if at
all), resaved as text, went back to 217k.

Interesting... I will do the same test and share the results.

¡Saludos!

Ileana Garza Tovar

[budgie]

On Thu, 13 Apr 2006 09:14:00 -0500, "Ileana Garza Tovar"

Post by Ileana Garza Tovar
Normally, all the files in the project are stored in a "tokenized" format
that can cause some problems when the tokens are affected one way or
another.

(snip)

Post by Ileana Garza Tovar
The solution is to BE SURE to ALWAYS save your code in Text (ASCII) format.

In this particular project, the problem was apparently corruption in the
tokenised saved project. When loaded, saved as ascii and then compiled from the
IDE it all worked. Resaved as tokenised and it all worked still.

But yes I have made sure it all happens in ascii format now.

[A. David Garza Marín]

Post by budgie
In this particular project, the problem was apparently corruption in the
tokenised saved project. When loaded, saved as ascii and then compiled from the
IDE it all worked. Resaved as tokenised and it all worked still.
But yes I have made sure it all happens in ascii format now.

You don't need to resave as tokenised because it brings more problemas than
solutions. With as low as a 80386 based computer, the binary format isn't
needed anymore, even with the low size of the resulting files. This is
specially true when you use Forms in your project. Back in years, using
QuickBASIC 4.5, I was usually confronting serious problems with the Binary
format. Back on those years I decided to let go the binary format and stick
to the text format.

[budgie]

On Mon, 17 Apr 2006 18:24:12 -0500, "A. David Garza Marín"

Post by A. David Garza Marín

Post by budgie
In this particular project, the problem was apparently corruption in the
tokenised saved project. When loaded, saved as ascii and then compiled from the
IDE it all worked. Resaved as tokenised and it all worked still.
But yes I have made sure it all happens in ascii format now.

You don't need to resave as tokenised because it brings more problemas than
solutions.

I appreciate that. It was done as part of the exercise in working out why the
original compile failure occurred. The re-save confirmed that a compile from
binary source works fine, and that it was (logically) a corrupted save in the
first place.