Author |
Message |
Jason Tripla #1 / 16
|
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 |
|
|
Tony Miller, PT #2 / 16
|
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 |
|
|
Matt McQuee #3 / 16
|
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 |
|
|
David Frankenbac #4 / 16
|
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 |
|
|
Gene Wirchen #5 / 16
|
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 |
|
|
Gene Wirchen #6 / 16
|
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 |
|
|
Jim Nelso #7 / 16
|
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 |
|
|
David Frankenbac #8 / 16
|
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 |
|
|
Gene Wirchen #9 / 16
|
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 |
|
|
Gene Wirchen #10 / 16
|
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 |
|
|
David Frankenbac #11 / 16
|
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 |
|
|
Vincent Mill #12 / 16
|
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 |
|
|
Anders Altber #13 / 16
|
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 |
|
|
Lisa Slater Nicholl #14 / 16
|
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 |
|
|