hi

If i start it with "TEST.EXE a b c d e"

PROCEDURE MAIN(cFile)   only 1 parameter
LOCAL i, iMax, nZahl := 0

   CLS
   iMax := PCOUNT()
   ? iMax                                 Cl*pper -> 1 / Xbase -> 5

   IF iMax > 0
      FOR i = 1 TO iMax
          ? PValue(i)                   Cl*pper does not have PValue()
          nZahl := nZahl + LEN(PValue(i))
      NEXT
   ENDIF

   ? nZahl
   INKEY(0)
RETURN

Cl*pper will give me PCOUNT() -> 1 but Xbase++ say 5 ?!

i LIKE this "enhancement" but it shoud be "documented"

greetings by OHR
Jimmy

Hallo Jimmy,

> i LIKE this "enhancement" but it shoud be "documented"
>

If this is true: I do not like this enhancement for in some programs I ask
how many parameters are handed over (?). And than the number of parameters
is important for me. Porting this programs to Xbase++ would destroy the
logic of this verification.

Jan

Jan,

>> i LIKE this "enhancement" but it shoud be "documented"
>>
> 
> If this is true: I do not like this enhancement for in some programs I ask
> how many parameters are handed over (?). And than the number of parameters
> is important for me. Porting this programs to Xbase++ would destroy the
> logic of this verification.

Well, if you have a formal parameter list, then you know how many
parameters there are and code explicitely for them.  The PCount()/PValue()
pair allow for dynamic parameter lists of undetermined length. Consider
this:

#xcommand PRINT <x0> [,<x1>] => MyPrint(<x0>[,<x1>])

Function MyPrint()
   local i
   
   for i := 1 to PCount()
      qout( Var2Char( PValue(i) ) )
   next
   return PCount()

You just can't do this in Clipper.  You would have to redefine the command
thus:

#xcommand PRINT <x0> [,<x1>] => MyPrint(<x0>) [; MyPrint(<x1>)]

Function MyPrint( x )
   qout( x )
   return 1

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

If I appoint someone as my consort, I will not subsequently inform her that
she is being replaced by a younger, more attractive woman.
          [Things I'd do as an Evil Overlord]

Phil and Jan,

I do not see this as an enhancement of PCount() as much as a difference in parsing the command line.  The command line is a single 
string parameter to the application from the OS point of view.  How the application interprets the command line is its perogative.

Obviously, Clipper and Xbase++ have a difference of opinion regarding how to deal with PCount() from the command line.  My guess is 
since you could not access actual parameters without a formal parameter in clipper (long way to say no PValue() function), Clipper 
stopped parsing the command line once the formal parameter list was satisfied.

If PCount() matters from the command line code that is dual compiled, I would just apply a max() function to PCount() to limit it to 
the count of your formal parameters -OR- test for (PCount() >= YourParamCount).

If you need to go deeper with the command line (like non-positional parameters), don't forget DosParam() and Token() from 
CATools/Xbtools

Rodd

"Phil Ide" <phil@idep.org.uk> wrote in message news:3ocx9r5hzn9s$.dlg@idep.org.uk...
> Jan,
>
>>> i LIKE this "enhancement" but it shoud be "documented"
>>>
>>
>> If this is true: I do not like this enhancement for in some programs I ask
>> how many parameters are handed over (?). And than the number of parameters
>> is important for me. Porting this programs to Xbase++ would destroy the
>> logic of this verification.
>
> Well, if you have a formal parameter list, then you know how many
> parameters there are and code explicitely for them.  The PCount()/PValue()
> pair allow for dynamic parameter lists of undetermined length. Consider
> this:
>
> #xcommand PRINT <x0> [,<x1>] => MyPrint(<x0>[,<x1>])
>
> Function MyPrint()
>   local i
>
>   for i := 1 to PCount()
>      qout( Var2Char( PValue(i) ) )
>   next
>   return PCount()
>
> You just can't do this in Clipper.  You would have to redefine the command
> thus:
>
> #xcommand PRINT <x0> [,<x1>] => MyPrint(<x0>) [; MyPrint(<x1>)]
>
> Function MyPrint( x )
>   qout( x )
>   return 1
>
> Regards,
> -- 
> Phil Ide
>
> ***************************************
> * Xbase++ FAQ, Libraries and Sources: *
> * goto: http://www.idep.org.uk/xbase  *
> ***************************************
>
> If I appoint someone as my consort, I will not subsequently inform her that
> she is being replaced by a younger, more attractive woman.
>          [Things I'd do as an Evil Overlord]

Rodd,

> Obviously, Clipper and Xbase++ have a difference of opinion regarding how to deal with PCount() from the command line.  My guess is 
> since you could not access actual parameters without a formal parameter in clipper (long way to say no PValue() function), Clipper 
> stopped parsing the command line once the formal parameter list was satisfied.

Yes, I see that as the reason as well.

> If PCount() matters from the command line code that is dual compiled, I would just apply a max() function to PCount() to limit it to 
> the count of your formal parameters -OR- test for (PCount() >= YourParamCount).

Yup.

> If you need to go deeper with the command line (like non-positional parameters), don't forget DosParam() and Token() from 
> CATools/Xbtools

Excellent point!  I like informal parameter lists, and have started using
them more and more. It never occurred to me to do it with the command line
(because you cannot pre-process the it).

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

My Legions of Terror will be trained in basic marksmanship. Any who cannot
learn to hit a man-sized target at 10 meters will be used for target
practice.
          [Things I'd do as an Evil Overlord]

Phil,

> I like informal parameter lists, and have started using
> them more and more. It never occurred to me to do it with the command line
> (because you cannot pre-process the it).

Not only can you do it, but I use a standardized command line parser (and hence a conforming syntax) to match command line 
parameters to the Xbase++ action.  I process left to right and use the syntax /Action(Param1,Param2) where the parameter list and 
parenthesis are optional and quoting can be used to force a parameter together that has embedded commas.  The init process of the 
application allows linked modules to present available command line actions to the central command line processor.  REQUEST is a 
command in my vocabulary.

Any remaining non-slash parameters are provided in order to AppMain().  I use a standardized Main() function to control psuedo-init 
procedure startup sequences with a fully initialized database (DbeSys), user interface (AppSys), and error system (ErrorSys).  This 
forced me to create an alternate entry point for the application which I selected AppMain().  Unfortunately, I do not have Eka's 
Insider tools yet, so I had to pass a limited number of residual parameters with extras being nil.

Are your 'informal parameter lists' named versus positional parameters?  If so, what is your implementation mechanism?

I have contemplated doing this with #xtranslate, but the clause syntax in the context of an expression feels disagreeable.  As I am 
working towards fully parsed, cataloged, and cross-indexed source code, I suffer with the parsing of clauses at the expression 
level.  I am wondering if you have a syntax that is compatible with expression parsing.

Rodd

"Phil Ide" <phil@idep.org.uk> wrote in message news:tv44697j0n5f.dlg@idep.org.uk...
> Rodd,
>
>> Obviously, Clipper and Xbase++ have a difference of opinion regarding how to deal with PCount() from the command line.  My guess 
>> is
>> since you could not access actual parameters without a formal parameter in clipper (long way to say no PValue() function), 
>> Clipper
>> stopped parsing the command line once the formal parameter list was satisfied.
>
> Yes, I see that as the reason as well.
>
>> If PCount() matters from the command line code that is dual compiled, I would just apply a max() function to PCount() to limit it 
>> to
>> the count of your formal parameters -OR- test for (PCount() >= YourParamCount).
>
> Yup.
>
>> If you need to go deeper with the command line (like non-positional parameters), don't forget DosParam() and Token() from
>> CATools/Xbtools
>
> Excellent point!  I like informal parameter lists, and have started using
> them more and more. It never occurred to me to do it with the command line
> (because you cannot pre-process the it).
>
> Regards,
> -- 
> Phil Ide
>
> ***************************************
> * Xbase++ FAQ, Libraries and Sources: *
> * goto: http://www.idep.org.uk/xbase  *
> ***************************************
>
> My Legions of Terror will be trained in basic marksmanship. Any who cannot
> learn to hit a man-sized target at 10 meters will be used for target
> practice.
>          [Things I'd do as an Evil Overlord]

Rodd,

> Are your 'informal parameter lists' named versus positional parameters?  
> If so, what is your implementation mechanism?
> 
> I have contemplated doing this with #xtranslate, but the clause syntax 
> in the context of an expression feels disagreeable.  As I am 
> working towards fully parsed, cataloged, and cross-indexed source code, 
> I suffer with the parsing of clauses at the expression 
> level.  I am wondering if you have a syntax that is compatible with 
> expression parsing.

There are several ways of doing it, but from a pre-processing point of view
it is very easy.  The first thing to do is make seperating commas optional.
Here the translation from XbHCL for HclDoc()

#xtranslate HclDoc( [\,[\,]] [html:<x>] [context:<y>] [template:<z>] ;
                    [<lKill:KILL>] [out:<a>] ) ;
         =>;
         MyDoc( <x>, <y>, <z>, <.lKill.>, <a> )

Instead of using ':' as seperators, I could have used '=' or even ' '.

This technique works well when you can process the code before it gets to
the target function, but when you can't then a different approach is
obviously necessary.

If as in the case of the command-line, you can accept all parameters as a
single string (or concatenate them), then you can parse them with a regular
expression parser. You could use my XbPCRE library, which provides a
class-based interface to PCRE.

I have also developed an embedded perl engine for Xbase++, which can be
called passing in pure perl code:

   cString := "this is a string"
   cString := perl '$x = "'+cString+'";'+;
                   '$x =~ s/(\b\w)(\w*)/uc($1).lc($2)/eg;'+;
                   '$a = $1; # save last matched primary'
                   '$x;'
   ? cString  "This Is A String"

You can even fetch values from perl variables:

   ? perl '$a;'  's'

Since the perl engine is running inside the Xbase++ thread (each thread gets
it's own engine), and once running remains running for the duration of the
thread, this is pretty fast stuff and extremely powerful. Could be useful
for parameter parsing 

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

If I have the hero cornered and am about to finish him off and he says "Look
out behind you!!" I will not laugh and say "You don't expect me to fall for
that old trick, do you?" Instead I will take a step to the side and half
turn. That way I can still keep my weapon trained on the hero, I can scan
the area behind me, and if anything was heading for me it will now be
heading for him.
          [Things I'd do as an Evil Overlord]