In reply to your message of July 24, 2003
> In most cases, casting an ansistring as pchar will work. The only caveat is
> when Windows wants to alter the variable you pass' contenets.
> e.g.
> MessageBox( pchar(MyMessage), 'test', MB_OK);
> but not:
> GetUserName( pchar(Username), 255 ); //error!!!
> instead:
> var
> Username: array[0..255] or char;
> begin
> GetUserName( Username, 255 ); //This works!!
> end;
> This, however, is how Delphi does it, so you may find that your mileage
> varies. For example, the second GetUserName example my require an
> '@Username' param.
I tried that and still had problems. What I ended up doing is writing a really
tiny string unit (CString) of my own that translates back and forth between
string formats. It completely elimated the issue for me...
I ended up with syntax like this:
var
Buffer : CString;
begin
MessageBox(CSTR(MyMessage,@Buffer), 'test',MD_OK);
CSTR is a procedure that places the Null Terminated string in
MyMessage into Buffer and passes the pointer to Windows.
To get a string into pascal from windows, where I can mess with it I
wrote an opposite translator PSTR which reads the buffer and converts
it to a pascal string variable.
var
Buffer : CString;
USer : String
Begin
GetUserName(PSTR(@Buffer),255);
UserName := PSTR(@Buffer);
This works. And so far it's 100% reliable...
Typecasting and the Strings unit often produced strange results that ended up
putting garbage into edit boxes and left me with unusable strings. For
example, If the username was "Fred Smith", by your suggested method
Length(Username) would return an error and SizeOf(username) would be 256. My
way --running everything through a translator-- Length returns 10 and SizeOf
returns 11 (because of the length byte).
FWIW... CString is a tiny unit, less than 2k! If anyone wants a copy they can
drop me an e-mail and I'll send it out by attachment... (I've submitted it to a
website but it's not online yet.)
I'm not angry, I like FP just fine, but, really, why should I have to write
this unit?
> Most OS have similar concepts; they just accomplish things in different ways
> (e.g. Linux devices are all file descriptors, but BeOS devices are almost
> all file descriptors, and Windows Devices are not.) Wrapping up the
> differences is the smart way of making sure your skills are transferable.
It is exactly this difference that spawned my comments. Unless there is a way
to make the wrappers transparent to the programmer, you really have little
choice but to bend the language a little. If you think about a project of some
size (eg: a new web browser) it would be a lot smarter, and a lot more
compatible, to run the sources through a conversion routine when going
cross-platform than to include 1000 instances of some translator routine which
would give you fits on the new platform.
What I'm saying is that the native syntax of the language should be maintained
as closely as possible between platforms, but the mechanics of each function
and procedure should be altered to suit the platform.
EG: when on windows FPC should work natively with null terminated strings,
when on DOS it should work with pascal strings. But this difference should be
invisible to the programmer...
But then... I'm having the time of my life over here. Getting back into
Pascal, learning a little C, writing my first windows programs (3 on the go
right now), meeting a bunch of new people online... hey... I'm not complaining
<G>.
-----
L D Blake
_______________________________________________
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
