Compiler Error

I've compiled my application, and gotten rid of all of the compiler errors
except one. I have a report that uses an external array in the fields, and
the compiler reports "myarray UNDEFINED". I have other forms that use
external arrays, and I simply put an EXTERNAL command in. But I don't know
where I can place an EXTERNAL command in a report so that it doesn't come up
with the compiler error.

The report works just fine, but there is just something about seeing the "0
Errors" at the end of your compilation.

Rick

Dan
Fri Jan 27 15:22:03 CST 2006

Put the EXTERNAL ARRAY command in the code that calls the report.

Dan

Rick Gangwisch wrote:
> I've compiled my application, and gotten rid of all of the compiler
> errors except one. I have a report that uses an external array in
> the fields, and the compiler reports "myarray UNDEFINED". I have
> other forms that use external arrays, and I simply put an EXTERNAL
> command in. But I don't know where I can place an EXTERNAL command
> in a report so that it doesn't come up with the compiler error.
>
> The report works just fine, but there is just something about seeing
> the "0 Errors" at the end of your compilation.
>
> Rick

RickGangwisch
Fri Jan 27 16:22:09 CST 2006

Dan

Thanks for the response.

I already tried that with no luck.

Rick

"Dan Freeman" wrote:

> Put the EXTERNAL ARRAY command in the code that calls the report.
>
> Dan
>
> Rick Gangwisch wrote:
> > I've compiled my application, and gotten rid of all of the compiler
> > errors except one. I have a report that uses an external array in
> > the fields, and the compiler reports "myarray UNDEFINED". I have
> > other forms that use external arrays, and I simply put an EXTERNAL
> > command in. But I don't know where I can place an EXTERNAL command
> > in a report so that it doesn't come up with the compiler error.
> >
> > The report works just fine, but there is just something about seeing
> > the "0 Errors" at the end of your compilation.
> >
> > Rick
>
>
>

Stefan
Fri Jan 27 16:32:23 CST 2006

Rick, you can put it in the report's dataenvironment.Init()


hth
-Stefan



--
|\_/| ------ ProLib - programmers liberty -----------------
(.. ) Our MVPs and MCPs make the Fox run....
- / See us at www.prolib.de or www.AFPages.de
-----------------------------------------------------------

"Rick Gangwisch" <RickGangwisch@discussions.microsoft.com> schrieb im Newsbeitrag
news:7301C3B0-D1D9-451A-9FA9-F4CA8F37DD28@microsoft.com...
> Dan
>
> Thanks for the response.
>
> I already tried that with no luck.
>
> Rick
>
> "Dan Freeman" wrote:
>
>> Put the EXTERNAL ARRAY command in the code that calls the report.
>>
>> Dan
>>
>> Rick Gangwisch wrote:
>> > I've compiled my application, and gotten rid of all of the compiler
>> > errors except one. I have a report that uses an external array in
>> > the fields, and the compiler reports "myarray UNDEFINED". I have
>> > other forms that use external arrays, and I simply put an EXTERNAL
>> > command in. But I don't know where I can place an EXTERNAL command
>> > in a report so that it doesn't come up with the compiler error.
>> >
>> > The report works just fine, but there is just something about seeing
>> > the "0 Errors" at the end of your compilation.
>> >
>> > Rick
>>
>>
>>

Matthew
Fri Jan 27 16:40:18 CST 2006

The EXTERNAL command does not work as advertised. Don't waste your time with
it. This is what we do.

In the startup code of your program:

IF .F.
PUBLIC myarray [1]
ENDIF

Because it's in an IF block that never executes, it doesn't do anything to
the program. All it does is make the <stupid> project manager happy. We have
dozens of these declarations in our app, we have long since given up trying
to get EXTERNAL command to do what it is supposed to do.

"Rick Gangwisch" <RickGangwisch@discussions.microsoft.com> wrote in message
news:7301C3B0-D1D9-451A-9FA9-F4CA8F37DD28@microsoft.com...
> Dan
>
> Thanks for the response.
>
> I already tried that with no luck.
>
> Rick
>
> "Dan Freeman" wrote:
>
>> Put the EXTERNAL ARRAY command in the code that calls the report.
>>
>> Dan
>>
>> Rick Gangwisch wrote:
>> > I've compiled my application, and gotten rid of all of the compiler
>> > errors except one. I have a report that uses an external array in
>> > the fields, and the compiler reports "myarray UNDEFINED". I have
>> > other forms that use external arrays, and I simply put an EXTERNAL
>> > command in. But I don't know where I can place an EXTERNAL command
>> > in a report so that it doesn't come up with the compiler error.
>> >
>> > The report works just fine, but there is just something about seeing
>> > the "0 Errors" at the end of your compilation.
>> >
>> > Rick
>>
>>
>>

Stefan
Fri Jan 27 16:55:51 CST 2006


"Matthew L Reed" <nousenetspam at dead ice dot us> schrieb im Newsbeitrag
news:ugBSxK5IGHA.2696@TK2MSFTNGP14.phx.gbl...
> The EXTERNAL command does not work as advertised. Don't waste your time with it.
> This is what we do.

Maybe time for a new attempt? "External Array" works just fine
(while "External Procedure" actually does not).


-Stefan



--
|\_/| ------ ProLib - programmers liberty -----------------
(.. ) Our MVPs and MCPs make the Fox run....
- / See us at www.prolib.de or www.AFPages.de
-----------------------------------------------------------

RickGangwisch
Fri Jan 27 20:58:27 CST 2006

Matthew

That worked great! Now I don't have to pepper all of my forms with EXTERNAL
commands. Thanks for the help!

Rick

"Matthew L Reed" wrote:

> The EXTERNAL command does not work as advertised. Don't waste your time with
> it. This is what we do.
>
> In the startup code of your program:
>
> IF .F.
> PUBLIC myarray [1]
> ENDIF
>
> Because it's in an IF block that never executes, it doesn't do anything to
> the program. All it does is make the <stupid> project manager happy. We have
> dozens of these declarations in our app, we have long since given up trying
> to get EXTERNAL command to do what it is supposed to do.
>
> "Rick Gangwisch" <RickGangwisch@discussions.microsoft.com> wrote in message
> news:7301C3B0-D1D9-451A-9FA9-F4CA8F37DD28@microsoft.com...
> > Dan
> >
> > Thanks for the response.
> >
> > I already tried that with no luck.
> >
> > Rick
> >
> > "Dan Freeman" wrote:
> >
> >> Put the EXTERNAL ARRAY command in the code that calls the report.
> >>
> >> Dan
> >>
> >> Rick Gangwisch wrote:
> >> > I've compiled my application, and gotten rid of all of the compiler
> >> > errors except one. I have a report that uses an external array in
> >> > the fields, and the compiler reports "myarray UNDEFINED". I have
> >> > other forms that use external arrays, and I simply put an EXTERNAL
> >> > command in. But I don't know where I can place an EXTERNAL command
> >> > in a report so that it doesn't come up with the compiler error.
> >> >
> >> > The report works just fine, but there is just something about seeing
> >> > the "0 Errors" at the end of your compilation.
> >> >
> >> > Rick
> >>
> >>
> >>
>
>
>

Olaf
Sat Jan 28 12:43:08 CST 2006

> IF .F.
> PUBLIC myarray [1]
> ENDIF
1. see Stafans remark.

2. use this instead
#IF .F.
PUBLIC myarray[1]
#ENDIF

Then this will even not check if .F. is .T.
at runtime.

Bernhard
Sun Jan 29 07:38:20 CST 2006

Hi Olaf

> 2. use this instead
> #IF .F.
> PUBLIC myarray[1]
> #ENDIF
>
> Then this will even not check if .F. is .T.
> at runtime.
I did not test it, but i guess, since #if is a compiler directive, the compiler
does not look at the line PUBLIC myarray(1), so you still get the error message
about missing array.

The definition is only needed at compile time, not at run time. To avoid
executing IF .F. it is ok if the dummy stuff follows the last RETURN of the main
program. Formally, the code after a RETURN belongs to the same procedure, even
if it is never executed:

* main prog
....
RETURN

PUBLIC myarray(1)

Regards
Bernhard Sander

Olaf
Mon Jan 30 04:24:20 CST 2006

> I did not test it, but i guess, since #if is a compiler directive, the compiler does not look at the line PUBLIC myarray(1), so
> you still get the error message about missing array.
You are right.

> * main prog
> ....
> RETURN
>
> PUBLIC myarray(1)
That is a nice solution. Never executed, but still convincing
the compiler, that there is no problem.

Bye, Olaf.

Andrew
Mon Jan 30 05:11:46 CST 2006

"Matthew L Reed" <nousenetspam at dead ice dot us> wrote in message
news:ugBSxK5IGHA.2696@TK2MSFTNGP14.phx.gbl...
> The EXTERNAL command does not work as advertised. Don't waste your time
> with it. This is what we do.
>
> In the startup code of your program:
>
> IF .F.
> PUBLIC myarray [1]
> ENDIF

Gregory Adam (or Kurt Wood) told me a neater kludge:


FUNCTION myarray
* dummy function so project manager stops whinging
* about array of this name used in report

--
HTH
Andrew Howell

Matthew
Tue Jan 31 16:27:43 CST 2006


"Stefan Wuebbe" <stefan.wuebbe@gmx.de> wrote in message
news:%23zptmT5IGHA.3020@TK2MSFTNGP10.phx.gbl...
>
> "Matthew L Reed" <nousenetspam at dead ice dot us> schrieb im Newsbeitrag
> news:ugBSxK5IGHA.2696@TK2MSFTNGP14.phx.gbl...
>> The EXTERNAL command does not work as advertised. Don't waste your time
>> with it. This is what we do.
>
> Maybe time for a new attempt? "External Array" works just fine
> (while "External Procedure" actually does not).
>

EXTERNAL ARRAY has been broken for years - actually, I don't believe it ever
worked 100%. In small simple apps it works as advertised. In moderate size
apps it might work. In my case, we have about a half million lines of code,
plus a couple hundred reports, over 200 class libraries, and about 450
forms. In a project like this, EXTERNAL ARRAY does not work as advertised in
many cases. We have long since given up trying to get it to work, and
instead stick a couple dozen dummy array references in a dummy routine.

Fortunately, this is not a VFP issue, this is a project manager issue. The
project manager is broken, and always has been. We did this in FPD and FPW,
and in VFP9 we *still* have to do it.

Matthew
Tue Jan 31 16:19:37 CST 2006

Yes, that is another advantage - no EXTERNALs all over the place, and you
have all of your dummy PUBLIC statements in one place. It's not right, but
it works and works well - I've done this for many years.


"Rick Gangwisch" <RickGangwisch@discussions.microsoft.com> wrote in message
news:928BEC67-4BD9-4466-A2F1-89087C661345@microsoft.com...
> Matthew
>
> That worked great! Now I don't have to pepper all of my forms with
> EXTERNAL
> commands. Thanks for the help!
>
> Rick
>
> "Matthew L Reed" wrote:
>
>> The EXTERNAL command does not work as advertised. Don't waste your time
>> with
>> it. This is what we do.
>>
>> In the startup code of your program:
>>
>> IF .F.
>> PUBLIC myarray [1]
>> ENDIF
>>
>> Because it's in an IF block that never executes, it doesn't do anything
>> to
>> the program. All it does is make the <stupid> project manager happy. We
>> have
>> dozens of these declarations in our app, we have long since given up
>> trying
>> to get EXTERNAL command to do what it is supposed to do.
>>
>> "Rick Gangwisch" <RickGangwisch@discussions.microsoft.com> wrote in
>> message
>> news:7301C3B0-D1D9-451A-9FA9-F4CA8F37DD28@microsoft.com...
>> > Dan
>> >
>> > Thanks for the response.
>> >
>> > I already tried that with no luck.
>> >
>> > Rick
>> >
>> > "Dan Freeman" wrote:
>> >
>> >> Put the EXTERNAL ARRAY command in the code that calls the report.
>> >>
>> >> Dan
>> >>
>> >> Rick Gangwisch wrote:
>> >> > I've compiled my application, and gotten rid of all of the compiler
>> >> > errors except one. I have a report that uses an external array in
>> >> > the fields, and the compiler reports "myarray UNDEFINED". I have
>> >> > other forms that use external arrays, and I simply put an EXTERNAL
>> >> > command in. But I don't know where I can place an EXTERNAL command
>> >> > in a report so that it doesn't come up with the compiler error.
>> >> >
>> >> > The report works just fine, but there is just something about seeing
>> >> > the "0 Errors" at the end of your compilation.
>> >> >
>> >> > Rick
>> >>
>> >>
>> >>
>>
>>
>>

Stefan
Wed Feb 01 01:39:51 CST 2006


"Matthew L Reed" <nousenetspam at dead ice dot us> schrieb im Newsbeitrag
news:%23k5DuZrJGHA.516@TK2MSFTNGP15.phx.gbl...
>
> In my case, we have about a half million lines of code, plus a couple hundred reports,
> over 200 class libraries, and about 450 forms. In a project like this, EXTERNAL ARRAY
> does not work as advertised in many cases.

So it's probably not easy to list some repro steps for the Fox
team to get it fixed, right?


-Stefan



--
|\_/| ------ ProLib - programmers liberty -----------------
(.. ) Our MVPs and MCPs make the Fox run....
- / See us at www.prolib.de or www.AFPages.de
-----------------------------------------------------------

Andrew
Wed Feb 01 02:10:30 CST 2006

"Stefan Wuebbe" <stefan.wuebbe@gmx.de> wrote in message
news:e3Be4LwJGHA.3144@TK2MSFTNGP11.phx.gbl...
>
> "Matthew L Reed" <nousenetspam at dead ice dot us> schrieb im Newsbeitrag
> news:%23k5DuZrJGHA.516@TK2MSFTNGP15.phx.gbl...
>>
>> In my case, we have about a half million lines of code, plus a couple
>> hundred reports, over 200 class libraries, and about 450 forms. In a
>> project like this, EXTERNAL ARRAY does not work as advertised in many
>> cases.
>
> So it's probably not easy to list some repro steps for the Fox
> team to get it fixed, right?

Maybe it got better in later versions than FPW? Here's a picture.
http://www.rowan.nildram.co.uk/tmp/externalarray.png

--
Regards
Andrew Howell

Stefan
Sun Feb 05 15:43:04 CST 2006


"Andrew Howell" <ajh@work> schrieb im Newsbeitrag
news:%23zhVVcwJGHA.3904@TK2MSFTNGP10.phx.gbl...
>
> Maybe it got better in later versions than FPW? Here's a picture.
> http://www.rowan.nildram.co.uk/tmp/externalarray.png


With that sequence, you'd get the same compiler warning in VFP,
the External line does not work when you put it where the array is
created.
But in VFP you can right-click the report's DataEnvironment, choose
Properties and put the "External ..." in one of its events, like Init() etc.


Regards
-Stefan



--
|\_/| ------ ProLib - programmers liberty -----------------
(.. ) Our MVPs and MCPs make the Fox run....
- / See us at www.prolib.de or www.AFPages.de
-----------------------------------------------------------

Matthew
Mon Feb 06 16:14:18 CST 2006


"Stefan Wuebbe" <stefan.wuebbe@gmx.de> wrote in message
news:e3Be4LwJGHA.3144@TK2MSFTNGP11.phx.gbl...
>
> "Matthew L Reed" <nousenetspam at dead ice dot us> schrieb im Newsbeitrag
> news:%23k5DuZrJGHA.516@TK2MSFTNGP15.phx.gbl...
>>
>> In my case, we have about a half million lines of code, plus a couple
>> hundred reports, over 200 class libraries, and about 450 forms. In a
>> project like this, EXTERNAL ARRAY does not work as advertised in many
>> cases.
>
> So it's probably not easy to list some repro steps for the Fox
> team to get it fixed, right?
>

LOL, it's hell to duplicate some of the things we have seen! Often
impossible, frequently time consuming, and I've seen some of the darnedest
bugs. Error trapping in dbc procedures, weird menu generator issues, all
kinds of strange stuff that can be very difficult to duplicate. Usually we
give up and just code around it. Sometimes I can duplicate it, and there are
a couple of fixes in VFP9 from stuff I've found.