PARAMETERS() bogusly returns 0 in some cases... 
Author Message
 PARAMETERS() bogusly returns 0 in some cases...

I have a .prg that uses the PARAMETERS() function to tell the number of
paramters that were sent in.  In some cases, PARAMETERS() returns 0,
even though the parameters have values.  I have the PARAMETERS() call
right under my LPARAM line.  

Does anybody know of a way where this is possible?  Is it some sort of
call stack limit??

Jason Triplat
Penchant



Sun, 27 Aug 2000 03:00:00 GMT  
 PARAMETERS() bogusly returns 0 in some cases...

USE PCOUNT() it works more of the time than parameters()
--
Tony Miller

thwart Unwanted Spam)

Send me no Spam, lest you wish your spirit to ROT IN HELL...



Quote:
> I have a .prg that uses the PARAMETERS() function to tell the number of
> paramters that were sent in.  In some cases, PARAMETERS() returns 0,
> even though the parameters have values.  I have the PARAMETERS() call
> right under my LPARAM line.  

> Does anybody know of a way where this is possible?  Is it some sort of
> call stack limit??

> Jason Triplat
> Penchant




Sun, 27 Aug 2000 03:00:00 GMT  
 PARAMETERS() bogusly returns 0 in some cases...

Have you tried using PCOUNT() instead ?

--

Matt McQueen
Matt McQueen Software Ltd.
http://www.netcomuk.co.uk/~mmcqueen/

Quote:

>I have a .prg that uses the PARAMETERS() function to tell the number of
>paramters that were sent in.  In some cases, PARAMETERS() returns 0,
>even though the parameters have values.  I have the PARAMETERS() call
>right under my LPARAM line.

>Does anybody know of a way where this is possible?  Is it some sort of
>call stack limit??

>Jason Triplat
>Penchant




Sun, 27 Aug 2000 03:00:00 GMT  
 PARAMETERS() bogusly returns 0 in some cases...

Jason,

PARAMETERS() is about the most useless function in xBase. It returns the number of
arguments sent to the last executed user defined function call made, which includes things
like ON KEY Labels, Timer interrupts etc. So it is possible that VFP has run an
asynchronous task between the LPARAMETERS and the PARAMETERS() call that will change the
value returned.

Use PCOUNT() instead it will ALWAYS tell you the number of arguments sent to the routine
where pcount() is called.

activate window "debug output"
debugout test( 1, 2 )

function test( arg1, arg2, arg3 )

debugout parameters() && 2
debugout pcount() && 2
test2( arg1, arg2, arg3 )
debugout parameters() && 3
debugout pcount() && 2
test3( arg1 )
debugout parameters() && 1
debugout pcount() && 2

return ""

function test2( arg1, arg2, arg3 )
debugout parameters() && 3
debugout pcount() && 3
return

function test3( arg1, arg2, arg3 )
debugout parameters() && 1
debugout pcount() && 1
debugout type( "arg1" )
return

df    - (Microsoft FoxPro MVP) http://www.geocities.com/ResearchTriangle/9834/

Quote:

>I have a .prg that uses the PARAMETERS() function to tell the number of
>paramters that were sent in.  In some cases, PARAMETERS() returns 0,
>even though the parameters have values.  I have the PARAMETERS() call
>right under my LPARAM line.

>Does anybody know of a way where this is possible?  Is it some sort of
>call stack limit??



Sun, 27 Aug 2000 03:00:00 GMT  
 PARAMETERS() bogusly returns 0 in some cases...

Quote:

>I have a .prg that uses the PARAMETERS() function to tell the number of
>paramters that were sent in.  In some cases, PARAMETERS() returns 0,
>even though the parameters have values.  I have the PARAMETERS() call
>right under my LPARAM line.  

>Does anybody know of a way where this is possible?  Is it some sort of
>call stack limit??

     parameters() is effectively broken.  The VFP On-line Docs says
this about parameters():
Returns the number of parameters passed to the most recently called
program, procedure, or user-defined function.

     If you have an on key label activate, this would become the most
recently blah, blah.

     The solution is to use pcount().

Sincerely,

Gene Wirchenko

C Pronunciation Guide:
     y=x++;     "wye equals ex plus plus semicolon"
     x=x++;     "ex equals ex doublecross semicolon"



Mon, 28 Aug 2000 03:00:00 GMT  
 PARAMETERS() bogusly returns 0 in some cases...

Quote:

>David,

>I have read similarly before.

>BUT I just came from reading VFP 5.0a Help on *both* PARAMETERS() and
>PCOUNT() and the Help looks identical to me!

>So what is the source of this "variance"? In particular, *BOTH* state that
>value will be for LAST function/proc/OKL executed is what is returned.

     RTFM again.  Here are the appropriate quotes from the VFP5
On-Line Docs:

parameters():
Returns the number of parameters passed to the most recently called
program, procedure, or user-defined function.

pcount():
Returns the number of parameters passed to the current program,
procedure, or user-defined function.

     Note that parameters() says "most recently called" and pcount()
say "current".  If an OKL is activated after the procedure is started
and before your parameters() call, the OKL will be the most recently
called entity and parameters() will report on the OKL not the
procedure.  pcount() reports on the current procedure whether or not
it has been interrupted by an OKL.

[snipped previous]

Sincerely,

Gene Wirchenko

C Pronunciation Guide:
     y=x++;     "wye equals ex plus plus semicolon"
     x=x++;     "ex equals ex doublecross semicolon"



Mon, 28 Aug 2000 03:00:00 GMT  
 PARAMETERS() bogusly returns 0 in some cases...

Gene,

I see. . . I need to "bring my lawyer" when I read VFP docs!

With such an important difference I would have thought that more than "most
recently" versus "current" would have been EXPLAINED. It isn't very hard
for my mind to make them the same thing!

Thanks, nevertheless, for pointing it out.

Cheers,
Jim N



Quote:

> >David,

> >I have read similarly before.

> >BUT I just came from reading VFP 5.0a Help on *both* PARAMETERS() and
> >PCOUNT() and the Help looks identical to me!

> >So what is the source of this "variance"? In particular, *BOTH* state
that
> >value will be for LAST function/proc/OKL executed is what is returned.

>      RTFM again.  Here are the appropriate quotes from the VFP5
> On-Line Docs:

> parameters():
> Returns the number of parameters passed to the most recently called
> program, procedure, or user-defined function.

> pcount():
> Returns the number of parameters passed to the current program,
> procedure, or user-defined function.

>      Note that parameters() says "most recently called" and pcount()
> say "current".  If an OKL is activated after the procedure is started
> and before your parameters() call, the OKL will be the most recently
> called entity and parameters() will report on the OKL not the
> procedure.  pcount() reports on the current procedure whether or not
> it has been interrupted by an OKL.

> [snipped previous]

> Sincerely,

> Gene Wirchenko

> C Pronunciation Guide:
>      y=x++;     "wye equals ex plus plus semicolon"
>      x=x++;     "ex equals ex doublecross semicolon"



Mon, 28 Aug 2000 03:00:00 GMT  
 PARAMETERS() bogusly returns 0 in some cases...

Jim,

I see Gene's got you on the straight and narrow here, we've had pcount() since one of the
2.6 releases I think it was added for dBASE compatibility and unfortunately was always
relegated to that section of the help file instead of being clearly documented/referenced
in the parameters() help. But I can't come up with a good reason why anyone would use
parameters() instead of pcount().

df    - (Microsoft FoxPro MVP) http://www.geocities.com/ResearchTriangle/9834/

Quote:

>BUT I just came from reading VFP 5.0a Help on *both* PARAMETERS() and
>PCOUNT() and the Help looks identical to me!

>So what is the source of this "variance"? In particular, *BOTH* state that
>value will be for LAST function/proc/OKL executed is what is returned.



Mon, 28 Aug 2000 03:00:00 GMT  
 PARAMETERS() bogusly returns 0 in some cases...

Quote:

>Gene,

>I see. . . I need to "bring my lawyer" when I read VFP docs!

     It seems like it sometimes.

Quote:
>With such an important difference I would have thought that more than "most
>recently" versus "current" would have been EXPLAINED. It isn't very hard
>for my mind to make them the same thing!

     Well, the problem with the docs is that they often don't explain
how the pieces fit together.  I originally found out about the
difference between p********s() and pcount() in
          "Hacker's Guide to Visual FoxPro 3.0"
          Tamar E. Granor and Ted Roche
          Addison-Wesley Publishing Company
          0-201-48379-3
It is an excellent book and covers (among other things) many VFP
gotchas.  Despite the title, it is highly useful with 5.

Quote:
>Thanks, nevertheless, for pointing it out.

     You're welcome.

[snipped previous]

Sincerely,

Gene Wirchenko

C Pronunciation Guide:
     y=x++;     "wye equals ex plus plus semicolon"
     x=x++;     "ex equals ex doublecross semicolon"



Mon, 28 Aug 2000 03:00:00 GMT  
 PARAMETERS() bogusly returns 0 in some cases...

Quote:

>I see Gene's got you on the straight and narrow here, we've had pcount() since one of the
>2.6 releases I think it was added for dBASE compatibility and unfortunately was always
>relegated to that section of the help file instead of being clearly documented/referenced
>in the parameters() help. But I can't come up with a good reason why anyone would use
>parameters() instead of pcount().

     If all of your OKLs have a different number of parameters than
all of your procedures, you could use p********s() to detect if an OKL
was activated during the current procedure and you wouldn't need a
global variable to do it!

     Yes, I'm reaching, but I couldn't resist.

Sincerely,

Gene Wirchenko

C Pronunciation Guide:
     y=x++;     "wye equals ex plus plus semicolon"
     x=x++;     "ex equals ex doublecross semicolon"



Mon, 28 Aug 2000 03:00:00 GMT  
 PARAMETERS() bogusly returns 0 in some cases...

Gene,

*LOL* and I need one like that on this Friday the 13th.

df    - (Microsoft FoxPro MVP) http://www.geocities.com/ResearchTriangle/9834/

Quote:

>     If all of your OKLs have a different number of parameters than
>all of your procedures, you could use p********s() to detect if an OKL
>was activated during the current procedure and you wouldn't need a
>global variable to do it!

>     Yes, I'm reaching, but I couldn't resist.



Tue, 29 Aug 2000 03:00:00 GMT  
 PARAMETERS() bogusly returns 0 in some cases...


writes:

Quote:

>I have a .prg that uses the PARAMETERS() function to tell the number
of
>paramters that were sent in.  In some cases, PARAMETERS() returns 0,
>even though the parameters have values.  I have the PARAMETERS() call
>right under my LPARAM line.  

>Does anybody know of a way where this is possible?  Is it some sort of
>call stack limit??

>Jason Triplat
>Penchant


Jason -- I haven't heard of this problem, but you can see whether
PCOUNT() has the same problem.  For various reasons, I use it more
often than Parameters() anyway.

-- Vin Miller



Wed, 30 Aug 2000 03:00:00 GMT  
 PARAMETERS() bogusly returns 0 in some cases...

And TAGNO(). Old MS antagnoism.
-A


Quote:
>There are a couple of other little gems that date from this exercise.
>TAGCOUNT(), I believe, is one of them.  I cannot believe that the docs read
>"for compatibility with dbase" with no other explanation.

>>L<



Thu, 07 Sep 2000 03:00:00 GMT  
 PARAMETERS() bogusly returns 0 in some cases...

Quote:
>     Well, the problem with the docs is that they often don't explain
>how the pieces fit together.  I originally found out about the
>difference between p********s() and pcount() in

The problem with the docs, in this case, is that they are *embarrassed* <g>.

PARAMETERS() has always been said to work the way it does "by design".  We
got PCOUNT() officially for Dbase V compatibility when they made that big
marketing push to win over Dbase people. IOW the same operation that brought
you the useless CATMAN, yes, gave us this wonderful little gem.

My private theory is that they made up the whole Dbase compatibility thing
just to to avoid admitting that PARAMETERS() is stoopid <g> -- or that, if
this were the case, it would have been worth it just to get PCOUNT(). <g>

There are a couple of other little gems that date from this exercise.
TAGCOUNT(), I believe, is one of them.  I cannot believe that the docs read
"for compatibility with dbase" with no other explanation.

Quote:
>L<



Fri, 08 Sep 2000 03:00:00 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. BUG: Using Return in Do Case causes odd behaviour

2. Returning a parameter from an object

3. Returning parameters from a form

4. mixed case (case-insensitive) searching with FoxPro ODBC MS drivers

5. procedure return value not numeric if procedure not include return command

6. How to return return copyright info in form

7. fgets() returns a carriage return!

8. Return TO returns to wrong procedure

9. Difference between Return myVar and Return (myVar)

10. Difference between return myVar and return (myVar)

11. Remove two carriage return and replace with only 1 carriage return

12. MSCOMM32.OCX serious problems, HyperAccess won't integrate with VFP due to SELECT CASE difference with VFP CASE

 

 
Powered by phpBB® Forum Software