Hello:
I am using VFP 9, but this may apply to many versions.
I am testing a new printing subsystem. This will require
testing each report with a valid configuration and an invalid
configuration. I wrote a short, standalone program that tweaks the
configuration either way. It is run with
<vfp>
do tmpprint with <number>
</vfp>
I also wanted to check the parameters. If I do not specify a
parameter, that is an error and one easily caught with pcount().
However, if there are more parameters than expected, an error
94 (Must specify additional parameters.) is thrown on the lparameters
statement. How do I catch this error considering that nothing gets
executed before the lparameters statement is looked at?
It gets odder. Supposedly lparameters takes up to 26
parameters. I am now up to 40, and they all get assigned their
specified values. Specifying a 41st parameter in the invocation
throws an error 94. Where does it end?
Sincerely,
Gene Wirchenko
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/ff296fa918679310a96a96bd9230c36d@mtlp000084
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
At 10:34 2016-11-22, Gene Wirchenko <genew@telus.net> wrote:
>Hello:
>
> I am using VFP 9, but this may apply to many versions.
>
> I am testing a new printing subsystem. This will require
> testing each report with a valid configuration and an invalid
> configuration. I wrote a short, standalone program that tweaks the
> configuration either way. It is run with
><vfp>
> do tmpprint with <number>
></vfp>
>
> I also wanted to check the parameters. If I do not specify a
> parameter, that is an error and one easily caught with pcount().
>
> However, if there are more parameters than expected, an error
> 94 (Must specify additional parameters.) is thrown on the
> lparameters statement. How do I catch this error considering that
> nothing gets executed before the lparameters statement is looked at?
>
> It gets odder. Supposedly lparameters takes up to 26
> parameters. I am now up to 40, and they all get assigned their
> specified values. Specifying a 41st parameter in the invocation
> throws an error 94. Where does it end?
Addendum: In this case, I could break the program up into two
programs: one the sets the valid configuration and one that sets an
invalid configuration. Neither would require parameters. However,
if a parameter is specified to a program without a [l]parameters
statement, an error 1234 (No PARAMETER statement is found.) is
thrown. (I note the typo in the error message: "PARAMETER" should be
"PARAMETERS".)
Sincerely,
Gene Wirchenko
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/2f0dc8d5bcb03cd1588629e590c60f83@mtlp000086
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
VFP, unlike some languages, is intolerant of excess parameters. To catch this:
1. Use error handling in the CALLING program, not the CALLED program
with the Parameters statement, or
2. Write a very tolerant program that accepts all of the parameters
you can throw at it (varies by version) and throws an error after
testing them with PCOUNT().
(At one point, I know the number of parameters was 26, since that's
the number of red playing cards in a standard deck. But I think that
limit was raised in the most recent version, as your testing
indicates.)
On Tue, Nov 22, 2016 at 2:36 PM, Gene Wirchenko <genew@telus.net> wrote:
> At 10:34 2016-11-22, Gene Wirchenko <genew@telus.net> wrote:
>>
>> Hello:
>>
>> I am using VFP 9, but this may apply to many versions.
>>
>> I am testing a new printing subsystem. This will require testing
>> each report with a valid configuration and an invalid configuration. I
>> wrote a short, standalone program that tweaks the configuration either way.
>> It is run with
>> <vfp>
>> do tmpprint with <number>
>> </vfp>
>>
>> I also wanted to check the parameters. If I do not specify a
>> parameter, that is an error and one easily caught with pcount().
>>
>> However, if there are more parameters than expected, an error 94
>> (Must specify additional parameters.) is thrown on the lparameters
>> statement. How do I catch this error considering that nothing gets executed
>> before the lparameters statement is looked at?
>>
>> It gets odder. Supposedly lparameters takes up to 26 parameters. I
>> am now up to 40, and they all get assigned their specified values.
>> Specifying a 41st parameter in the invocation throws an error 94. Where
>> does it end?
>
>
> Addendum: In this case, I could break the program up into two programs:
> one the sets the valid configuration and one that sets an invalid
> configuration. Neither would require parameters. However, if a parameter
> is specified to a program without a [l]parameters statement, an error 1234
> (No PARAMETER statement is found.) is thrown. (I note the typo in the error
> message: "PARAMETER" should be "PARAMETERS".)
>
> Sincerely,
>
> Gene Wirchenko
>
>
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/CACW6n4vvBXeNVpjXtRJsx-aZPwVAu+O-vBvXi6+pznb6dVjdKA@mail.gmail.com
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Have you thought about passing your parameters in a single array, Gene?
That way you can test to see if you have received the correct number of
parameters using alen() and empty().
PROCEDURE TmpPrint
PARAMETERS laParams
liArray_Len = alen(laParams)
IF liArray_Len < min_param
* Too few parameters
ENDIF
IF liArray_Len > max_param
FOR i = max_param + 1 TO liArray_Len
IF !empty(laParams[i])
* Too many parameters
ENDIF
NEXT
* Just right!
This also circumvents the limit on the number of parameters that can be
passed.
Mike
-----Original Message-----
From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ted
Roche
Sent: Tuesday, November 22, 2016 12:57 PM
To: profoxtech@leafe.com
Subject: Re: Dealing with Extraneous Parameters
VFP, unlike some languages, is intolerant of excess parameters. To catch
this:
1. Use error handling in the CALLING program, not the CALLED program with
the Parameters statement, or
2. Write a very tolerant program that accepts all of the parameters you can
throw at it (varies by version) and throws an error after testing them with
PCOUNT().
(At one point, I know the number of parameters was 26, since that's the
number of red playing cards in a standard deck. But I think that limit was
raised in the most recent version, as your testing
indicates.)
On Tue, Nov 22, 2016 at 2:36 PM, Gene Wirchenko <genew@telus.net> wrote:
> At 10:34 2016-11-22, Gene Wirchenko <genew@telus.net> wrote:
>>
>> Hello:
>>
>> I am using VFP 9, but this may apply to many versions.
>>
>> I am testing a new printing subsystem. This will require
>> testing each report with a valid configuration and an invalid
>> configuration. I wrote a short, standalone program that tweaks the
configuration either way.
>> It is run with
>> <vfp>
>> do tmpprint with <number>
>> </vfp>
>>
>> I also wanted to check the parameters. If I do not specify a
>> parameter, that is an error and one easily caught with pcount().
>>
>> However, if there are more parameters than expected, an error 94
>> (Must specify additional parameters.) is thrown on the lparameters
>> statement. How do I catch this error considering that nothing gets
>> executed before the lparameters statement is looked at?
>>
>> It gets odder. Supposedly lparameters takes up to 26
>> parameters. I am now up to 40, and they all get assigned their specified
values.
>> Specifying a 41st parameter in the invocation throws an error 94.
>> Where does it end?
>
>
> Addendum: In this case, I could break the program up into two
programs:
> one the sets the valid configuration and one that sets an invalid
> configuration. Neither would require parameters. However, if a
> parameter is specified to a program without a [l]parameters statement,
> an error 1234 (No PARAMETER statement is found.) is thrown. (I note
> the typo in the error
> message: "PARAMETER" should be "PARAMETERS".)
>
> Sincerely,
>
> Gene Wirchenko
>
>
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/054401d244ff$e3d85300$ab88f900$@PioneerDrama.com
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
At 11:56 2016-11-22, Ted Roche <tedroche@gmail.com> wrote:
>VFP, unlike some languages, is intolerant of excess parameters. To catch this:
>
>1. Use error handling in the CALLING program, not the CALLED program
>with the Parameters statement, or
>
>2. Write a very tolerant program that accepts all of the parameters
>you can throw at it (varies by version) and throws an error after
>testing them with PCOUNT().
>
>(At one point, I know the number of parameters was 26, since that's
>the number of red playing cards in a standard deck. But I think that
>limit was raised in the most recent version, as your testing
>indicates.)
Point 1: this will not work for me since it is a *standalone* program.
As to point 2, the parameter limit is rather high. On my
system, it was 152! Above 40, I kept getting spurious "Source is out
of date" messages and had to explicitly compile my test
programs. This odd behaviour was consistent. I also had one case
where VFP insisted on holding onto the program, and I could not
delete it, even after clear program.
VFP is not perfect, but this one is embarrassing.
[snipped previous]
Sincerely,
Gene Wirchenko
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/a5a681ba8cac81472d7481770737a854@mtlp000086
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
At 12:34 2016-11-22, "Michael Glassman" <MHGlassman@PioneerDrama.com> wrote:
>Have you thought about passing your parameters in a single array, Gene?
>That way you can test to see if you have received the correct number of
>parameters using alen() and empty().
It was a *standalone* program. The idea was to invoke it
easily, such as in one line. It took only one parameter. I just
wanted to detect if too many parameters were passed to it. As far as
I can see, VFP does not allow this sort of checking in a general way.
The number of parameters is limited, but it seems it is way
more than 26. On my system, it is 152. Yes, each parameter got its
correct value.
[snip]
Sincerely,
Gene Wirchenko
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/28c396f71e5a5aa0fb2fbea51e014fd6@mtlp000083
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Duplicate of https://stackoverflow.com/questions/27003126/variadic-functions-in-visual-foxpro
WONTFIX
On Tue, Nov 22, 2016 at 4:07 PM, Gene Wirchenko <genew@telus.net> wrote:
> At 12:34 2016-11-22, "Michael Glassman" <MHGlassman@PioneerDrama.com> wrote:
>>
>> Have you thought about passing your parameters in a single array, Gene?
>> That way you can test to see if you have received the correct number of
>> parameters using alen() and empty().
>
>
> It was a *standalone* program. The idea was to invoke it easily, such
> as in one line. It took only one parameter. I just wanted to detect if too
> many parameters were passed to it. As far as I can see, VFP does not allow
> this sort of checking in a general way.
>
> The number of parameters is limited, but it seems it is way more than
> 26. On my system, it is 152. Yes, each parameter got its correct value.
>
> [snip]
>
> Sincerely,
>
> Gene Wirchenko
>
>
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/CACW6n4uyheu6z0hfw7OR59meuSStZqWX44QnZTQ7RBMyqTb8gw@mail.gmail.com
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Gene,
Am I missing something here or couldn't you pass a Parameter Object in which all your parameters become properties? This would allow you a limitless number of parameters and also be interface independent.
Dave
-----Original Message-----
From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Gene Wirchenko
Sent: 22 November 2016 18:34
To: ProFox Email List <profox@leafe.com>
Subject: Dealing with Extraneous Parameters
Hello:
I am using VFP 9, but this may apply to many versions.
I am testing a new printing subsystem. This will require testing each report with a valid configuration and an invalid configuration. I wrote a short, standalone program that tweaks the configuration either way. It is run with <vfp>
do tmpprint with <number>
</vfp>
I also wanted to check the parameters. If I do not specify a parameter, that is an error and one easily caught with pcount().
However, if there are more parameters than expected, an error
94 (Must specify additional parameters.) is thrown on the lparameters statement. How do I catch this error considering that nothing gets executed before the lparameters statement is looked at?
It gets odder. Supposedly lparameters takes up to 26 parameters. I am now up to 40, and they all get assigned their specified values. Specifying a 41st parameter in the invocation throws an error 94. Where does it end?
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/18725B8CD2D5D247873A2BAF401D4AB2A43BDC88@EX2010-A-FPL.FPL.LOCAL
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
On 23/11/2016 08:34, Dave Crozier wrote:
> Gene,
> Am I missing something here or couldn't you pass a Parameter Object in which all your parameters become properties? This would allow you a limitless number of parameters and also be interface independent.
>
> Dave
>
I do the same with say a print/mailing object:
Private oPrint
oPrint = CREATEOBJECT('custom')
DO setoprint
oPrint.e_tolist = 'someemail@somewhere.com'
etc..
* Call some program where oPrint will be visible and you don't have to
pass any parameters. E.g.
sendemail()
FUNCTION setoPrint
oPrint.addproperty('cOption','') && P=Print E=Email V=View D=PDF
G=Prog X=excel T=Text
oPrint.addproperty('p_printer','')
oPrint.addproperty('p_orient',0)
oPrint.addproperty('p_location','')
oPrint.addproperty('p_copies',1)
oPrint.addproperty('e_tolist','')
oPrint.addproperty('e_cclist','')
oPrint.addproperty('e_bcclist','')
oPrint.addproperty('e_subject','')
oPrint.addproperty('e_body','')
oPrint.addproperty('e_attach','')
etc....
This communication is intended for the person or organisation to whom it is addressed. The contents are confidential and may be protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email.
www.whisperingsmith.com
Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3 1RR.
Tel:0161 831 3700
Fax:0161 831 3715
London Office:17-19 Foley Street, London W1W 6DW Tel:0207 299 7960
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/bd4b2da5-e958-893f-343a-886028f7a386@whisperingsmith.com
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
+1
John Weller
01380 723235
07976 393631
> -----Original Message-----
> From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of
> Peter Cushing
> Sent: 23 November 2016 08:53
> To: profoxtech@leafe.com
> Subject: Re: Dealing with Extraneous Parameters
>
> On 23/11/2016 08:34, Dave Crozier wrote:
> > Gene,
> > Am I missing something here or couldn't you pass a Parameter Object in
> which all your parameters become properties? This would allow you a
> limitless number of parameters and also be interface independent.
> >
> > Dave
> >
> I do the same with say a print/mailing object:
>
> Private oPrint
> oPrint = CREATEOBJECT('custom')
> DO setoprint
>
> oPrint.e_tolist = 'someemail@somewhere.com'
> etc..
>
> * Call some program where oPrint will be visible and you don't have to
pass
> any parameters. E.g.
> sendemail()
>
>
>
> FUNCTION setoPrint
> oPrint.addproperty('cOption','') && P=Print E=Email V=View D=PDF
> G=Prog X=excel T=Text
> oPrint.addproperty('p_printer','')
> oPrint.addproperty('p_orient',0)
> oPrint.addproperty('p_location','')
> oPrint.addproperty('p_copies',1)
> oPrint.addproperty('e_tolist','')
> oPrint.addproperty('e_cclist','')
> oPrint.addproperty('e_bcclist','')
> oPrint.addproperty('e_subject','')
> oPrint.addproperty('e_body','')
> oPrint.addproperty('e_attach','')
> etc....
>
>
>
>
> This communication is intended for the person or organisation to whom it
is
> addressed. The contents are confidential and may be protected in law.
> Unauthorised use, copying or disclosure of any of it may be unlawful. If
you
> have received this message in error, please notify us immediately by
> telephone or email.
>
> www.whisperingsmith.com
>
> Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3
> 1RR.
> Tel:0161 831 3700
> Fax:0161 831 3715
>
> London Office:17-19 Foley Street, London W1W 6DW Tel:0207 299 7960
>
>
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/002701d2456d$44c579f0$ce506dd0$@johnweller.co.uk
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.