Loading a project (.MAK stalls) - help!

budgie · Joined: 04 Oct 2007 Posts: 40

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.)

Archived from group: microsoft>public>vb>dos

Karl E. Peterson · Joined: 04 Oct 2007 Posts: 4836

budgie wrote:
> 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.
--
Working without a .NET?
http://classicvb.org/

budgie · Joined: 04 Oct 2007 Posts: 40

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

>budgie wrote:
>> 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 · Joined: 04 Oct 2007 Posts: 4836

budgie wrote:
> On Fri, 24 Feb 2006 09:13:02 -0800, "Karl E. Peterson"
> wrote:
>
>> budgie wrote:
>>> 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?
--
Working without a .NET?
http://classicvb.org/

budgie · Joined: 04 Oct 2007 Posts: 40

On Mon, 27 Feb 2006 11:10:48 -0800, "Karl E. Peterson" wrote:

>budgie wrote:
>> On Fri, 24 Feb 2006 09:13:02 -0800, "Karl E. Peterson"
>> wrote:
>>
>>> budgie wrote:
>>>> 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 · Joined: 04 Oct 2007 Posts: 9

In article , me@privacy.net
says...
> On Mon, 27 Feb 2006 11:10:48 -0800, "Karl E. Peterson" wrote:
>
> >budgie wrote:
> 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

--
Regards, John
news@johnkane.clara.co.uk

Stephen Howe · Joined: 04 Oct 2007 Posts: 59

> 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).

> (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 · Joined: 04 Oct 2007 Posts: 40

On Tue, 28 Feb 2006 13:47:08 -0000, John Kane wrote:

>In article , me@privacy.net
>says...
>> On Mon, 27 Feb 2006 11:10:48 -0800, "Karl E. Peterson" wrote:
>>
>> >budgie wrote:
>> 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.

budgie · Joined: 04 Oct 2007 Posts: 40

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

>> 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.

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

>You want a STATIC COMMON array not a DYNAMIC one, I think

Yes.

>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.

>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 ....

>But you want to place all executable statements _after_

of course.

>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.

>> (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.

ArarghMail603NOSPAM · Joined: 04 Oct 2007 Posts: 11

On Wed, 01 Mar 2006 08:52:41 +0800, budgie wrote:

>On Tue, 28 Feb 2006 13:47:08 -0000, John Kane wrote:
>
>>In article , me@privacy.net
>>says...
>>> On Mon, 27 Feb 2006 11:10:48 -0800, "Karl E. Peterson" wrote:
>>>
>>> >budgie wrote:
>>> 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.
--
ArarghMail603 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

budgie · Joined: 04 Oct 2007 Posts: 40

On Wed, 01 Mar 2006 23:25:30 -0600, ArarghMail603NOSPAM@NOT.AT.Arargh.com wrote:

>On Wed, 01 Mar 2006 08:52:41 +0800, budgie wrote:
>
>>On Tue, 28 Feb 2006 13:47:08 -0000, John Kane wrote:
>>
>>>In article , me@privacy.net
>>>says...
>>>> On Mon, 27 Feb 2006 11:10:48 -0800, "Karl E. Peterson" wrote:
>>>>
>>>> >budgie wrote:
>>>> 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.

>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.

>I wrote BCET, which mostly doesn't care.

John Kane · Joined: 04 Oct 2007 Posts: 9

In article , me@privacy.net
says...
> >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.
>
> >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.
>
>
> >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.

--
Regards, John
news@johnkane.clara.co.uk

budgie · Joined: 04 Oct 2007 Posts: 40

On Thu, 2 Mar 2006 11:54:32 -0000, John Kane wrote:

>In article , me@privacy.net
>says...
>> >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.
>>
>> >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.
>>
>>
>> >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.

>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.

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

buck huffman · Joined: 04 Oct 2007 Posts: 2

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

ArarghMail603NOSPAM · Joined: 04 Oct 2007 Posts: 11

On Mon, 06 Mar 2006 09:28:05 -0500, buck huffman wrote:

>
>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.

That's fine for ONE module (source file)
--
ArarghMail603 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.