Calling takecmd.dll from PBCC

[Michael Mattias]

>which inserts the thousands separator into the supplied number

Not to beat the dying horse, but wouldn't it have been a lot easier to just use....

FormattedString  = FORMAT$(VAL(numberAsString), "#,")

... than screwing around with this API?

Conversion tool Number One is that grey stuff between the ears!

[Scott Slater]

It is a void so you should be using a PB SUB instead of a FUNCTION, not critical but just thought I'd add that.

Try:

'void WINAPI AddCommas( LPTSTR pszNumber );

Declare Sub AddCommas Lib "TakeCmd.dll" Alias "AddCommas"(zNumber as Asciiz)

[Michael Mattias]

Your mismatch is caused by defining TheString a "STRING* 512" instead just calling it what it is - a "STRING"

Had you been able to compile it it would have probably GPFed anyway, since fixed-length strings ("STRING * anything') are regular scalar variables, which is not the same as an "AS STRING" variable.

However, I think your declare is wrong anyway; I'd bet "pWideChar" means "address of a buffer containing a null-terminated Unicode string"; also not the same as an "AS STRING."

There are very few functions in "redistributed" DLLs .. i.e., those made available to the public at large - which would use an 'AS STRING' parameter. Almost all such redistributed functions accept string (small s) parameters as the address of a null-terminated character string.

MCM

[José Roca]

DECLARE SUB AddCommas LIB "TakeCmd.dll" _
                           ALIAS "AddCommas" _
                           (BYVAL lpstr AS DWORD)

FUNCTION PBMAIN () AS LONG
  DIM TheString AS STRING * 512
  TheString = "12345678"
  AddCommas VARPTR(TheString)
  PRINT TheString
END FUNCTION

If the procedure wants an Unicode string (the parameter is defined as PWideChar in the Pascal prototype), then use:

  TheString = UCODE$("12345678")
  AddCommas VARPTR(TheString)
  PRINT ACODE$(TheString)

In any case, you will need to trim the trailing blanks.

[Joe Caverly]

Hi,
I'm using PBCC 5.01, and would like to use some of the functions available from JPSoftware's 4NT8 product.

I have no problem using the functions from Delphi 2.0, but I must be missing something simple when calling from PBCC 5.01. Here's some sample code that I'm working with;

#COMPILE EXE
#DIM ALL

'The following comments are from the [URL="ftp://ftp.jpsoft.com/sdk/sdk.zip"]Plugin SDK[/URL] from JPSoft;

'From takecmd.h
'
'void WINAPI AddCommas( LPTSTR pszNumber );
'/*
'    Insert thousands separators in pszNumber
'*/

'3.3  Some functions in TakeCmd.dll manipulate the string that you pass to them
'     within the buffer in which the string resides.  Therefore, if the
'     TakeCmd.dll function can return a longer string than is passed to it, you
'     must make sure that you pass the string in a buffer that is large enough
'     to provide working space and to hold the returned string if appropriate.

'     An example of such a function is:

'    void WINAPI AddCommas( LPTSTR pszNumber );

'     which inserts the thousands separator into the supplied number.  In
'     Delphi this would be declared as:

'    procedure AddCommas(Arguments: PWideChar); stdcall;  external 'TakeCmd.dll';

'     When this procedure adds in the thousands separator the resulting string
'     will be longer than the string that you started with, and so you must
'     allow room for that expansion.  The size of the buffer that you need
'     cannot be precisely defined, and you may need to experiment.  However, as
'     a guideline I would suggest a buffer of at least three times the length
'     of the string that you are passing to the function.


DECLARE FUNCTION AddCommas LIB "TakeCmd.dll" _
                           ALIAS "AddCommas" _
                           (lpstr AS STRING) AS STRING

FUNCTION PBMAIN () AS LONG
  DIM TheString AS STRING * 512
  TheString = "12345678"
  AddCommas TheString
  PRINT TheString
END FUNCTION

I'm getting a "Parameter mismatches definition" error at

AddCommas TheString

I've been looking at the screen for too long, so it's probably something simple. Constructive suggestions welcome.

Thanks from Joe