Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: Best Practices for Implicit String Conversions


This question is answered.


Permlink Replies: 17 - Last Post: Mar 7, 2016 9:54 AM Last Post By: Richard Zarr
Richard Zarr

Posts: 74
Registered: 7/1/98
Best Practices for Implicit String Conversions  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 4, 2016 6:35 AM
We are in the process of migrating roughly 1M lines of code to RAD Studio 2010. In a typical project in this group, we'll see 600-700 warnings on implicit string casts where we've done something this:

var
 ss : ShortString;
begin
 ss := Edit1.Text; // flags a warning
 SendToDLL(ss); // use short strings for passing text data to DLLs
end 


We're thinking of creating several helper routines that would check the string before converting it to a ShortString (no loss of data) and doing something like this (simple example below, however we use structures and pointers):

var
 ss : ShortString;
begin
 try
  ss := StringToShortString(Edit1.Text); // flags a warning
  SendToDLL(ss); // use short strings for passing text data to DLLs
 except
  // raise error that string will lose data
 end
end 


Is there a "best practice" for these types of string conversions - we (literally) have thousands of them in our code due to structures we pass between the core application and our support DLLs. We really don't like simply ignoring the warnings... they are there for a good reason. Any insight would be appreciated.
David Millington

Posts: 257
Registered: 5/29/05
Re: Best Practices for Implicit String Conversions  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 4, 2016 7:06 AM   in response to: Richard Zarr in response to: Richard Zarr
The best practice is to not convert to ShortString :) Do you control
the DLLs, too? If so, convert them to Unicode as well.

You say there is "no loss of data" - are you sure? That's unlikely.

Otherwise, instead of this:

var
 ss : ShortString;
begin
 try
  ss := StringToShortString(Edit1.Text); // flags a warning
  SendToDLL(ss); // use short strings for passing text data to DLLs
 except
  // raise error that string will lose data
 end
end


Why have StringToShortString flag a warning - why can't it raise the
exception itself? I think if you are certain the strings you are
converting can never lose data, then checking in the method and raising
an exception there is a good approach. (Not raising one outside the
method.) If you are not sure, then you should stick with Unicode and
make sure your support libraries handle it.
Richard Zarr

Posts: 74
Registered: 7/1/98
Re: Best Practices for Implicit String Conversions  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 4, 2016 8:06 AM   in response to: David Millington in response to: David Millington
David Millington wrote:
The best practice is to not convert to ShortString :) Do you control
the DLLs, too? If so, convert them to Unicode as well.

You say there is "no loss of data" - are you sure? That's unlikely.

Otherwise, instead of this:

var
 ss : ShortString;
begin
 try
  ss := StringToShortString(Edit1.Text); // flags a warning
  SendToDLL(ss); // use short strings for passing text data to DLLs
 except
  // raise error that string will lose data
 end
end


Why have StringToShortString flag a warning - why can't it raise the
exception itself? I think if you are certain the strings you are
converting can never lose data, then checking in the method and raising
an exception there is a good approach. (Not raising one outside the
method.) If you are not sure, then you should stick with Unicode and
make sure your support libraries handle it.

We do control both ends... we deliberately designed structures to pass various parameters back and forth with our support DLLs (plug-ins). So a typical structure might look like this:

PDllStruct = ^TDllStruct;
TDllStruct = record
 Title : shortstring;
 Location : shortstring;
 LocLat : double;
 LocLong : double;
 OtherStuff : integer; 
end


and it is used like this:

var
 DllStruct : TDllStruct;
begin
 DllStruct.Title := ebTitle.Text;
 DllStruct.Location := ebLocation.Text;
 
...
 
 SendDllStructToPlugIn(@DllStruct);
 
// DLL may fill in or alter various pieces of this structure, so we cannot use dynamic arrays (strings)... size must remain fixed.
 
 ebTitle.Text := DllStruct.Title;
 ebLocation.Text := DllStruct.Location;
end


Our text entries never exceed 255 characters, however Unicode may be valuable if we localize our application. I don't believe we can simply change the ShortString in our structure to a String without having memory management issues.
Robert Triest

Posts: 687
Registered: 3/24/05
Re: Best Practices for Implicit String Conversions  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 4, 2016 8:15 AM   in response to: Richard Zarr in response to: Richard Zarr
You can do :

ss := ShortString(Edit1.Text); // No warning


But your problem will remain that the user can add non ASCII chars in the Edit1.Text (Unicode String)
Like, as soon the user Copy Paste something from a webbrowser or other source you never know if your ShortString can handle the text..

Our text entries never exceed 255 characters,
The warning problem is not about the length of the string but about what characters (chinese, arabic or other non ASCII characters) can be added to the string..

Edited by: Robert Triest on Mar 4, 2016 5:17 PM
Richard Zarr

Posts: 74
Registered: 7/1/98
Re: Best Practices for Implicit String Conversions  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 4, 2016 8:55 AM   in response to: Robert Triest in response to: Robert Triest
Robert Triest wrote:
You can do :

ss := ShortString(Edit1.Text); // No warning


But your problem will remain that the user can add non ASCII chars in the Edit1.Text (Unicode String)
Like, as soon the user Copy Paste something from a webbrowser or other source you never know if your ShortString can handle the text..

Our text entries never exceed 255 characters,
The warning problem is not about the length of the string but about what characters (chinese, arabic or other non ASCII characters) can be added to the string..

Edited by: Robert Triest on Mar 4, 2016 5:17 PM

When doing this:

 ss := ShortString(Edit1.Text); // No warning


the ShortString cast is now explicit (intentional) which is also an optional warning. We'd like to understand better what this type cast does in the presence of Unicode characters (or lengths > 255). I know there are problems in our application with password obfuscation in TEdit controls. It shows up as an issue in one of our custom controls, so we need to investigate the problem.

If anyone can comment on replacing the ShortString with String in our example structure, we'd appreciate it. This architecture was done about 5 years ago, and we're going from our aging brains - we're pretty sure we chose the ShortString type to fix the length of the string and allow simple passing to the DLLs. Dynamic arrays in these structures change the memory allocation thus memory management of Strings is (fairly) problematic when passed back and forth with DLLs. If this is not true, please explain why...
David Millington

Posts: 257
Registered: 5/29/05
Re: Best Practices for Implicit String Conversions
Helpful
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 4, 2016 9:03 AM   in response to: Richard Zarr in response to: Richard Zarr
On 2016-03-04 16:55:36 +0000, Richard Zarr said:
When doing this:

 ss := ShortString(Edit1.Text); // No warning


the ShortString cast is now explicit (intentional) which is also an
optional warning. We'd like to understand better what this type cast
does in the presence of Unicode characters (or lengths > 255). I know
there are problems in our application with password obfuscation in
TEdit controls. It shows up as an issue in one of our custom controls,
so we need to investigate the problem.

If anyone can comment on replacing the ShortString with String in our
example structure, we'd appreciate it. This architecture was done
about 5 years ago, and we're going from our aging brains - we're pretty
sure we chose the ShortString type to fix the length of the string and
allow simple passing to the DLLs. Dynamic arrays in these structures
change the memory allocation thus memory management of Strings is
(fairly) problematic when passed back and forth with DLLs. If this is
not true, please explai
n why...

See my other reply, but if you want a fixed length structure, replace
shortstring with a fixed length array of Char. Both are fixed-length -
problem solved :)

Re shortstring casts, I haven't used shortstring for a long, long time,
and it woudln't surprise me if there are quirks converting from
unicode, but with that caveat:
a) I think it truncates at 255 characters - I know it doesn't support
more than 255 characters, anyway
b) If it behaves like an AnsiString cast, it will attempt to convert to
the local codepage.
David Millington

Posts: 257
Registered: 5/29/05
Re: Best Practices for Implicit String Conversions  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 4, 2016 8:58 AM   in response to: Richard Zarr in response to: Richard Zarr
On 2016-03-04 16:06:02 +0000, Richard Zarr said:

We do control both ends... we deliberately designed structures to pass
various parameters back and forth with our support DLLs (plug-ins). ...
Our text entries never exceed 255 characters, however Unicode may be
valuable if we localize our application. I don't believe we can simply
change the ShortString in our structure to a String without having
memory management issues.

You can share strings between the app and DLLs by using ShareMem. But
there's one simple solution - if you're okay having a converter method
(as you are using to convert string to ShortString), and a length liit
of 255 is fixed, why not change your structures to have an
array[1..255] of Char? In other words, convert to and from an array of
Unicode characters.

You keep fixed length structures, but gain Unicode.

Btw, I don't know where the strings come from, but if they come from
user input anywhere, then they may contain Unicode characters. So there
may be data loss if you keep using short strings.
Peter Below

Posts: 1,227
Registered: 12/16/99
Re: Best Practices for Implicit String Conversions  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 4, 2016 9:30 AM   in response to: Richard Zarr in response to: Richard Zarr
Richard Zarr wrote:

We do control both ends... we deliberately designed structures to
pass various parameters back and forth with our support DLLs
(plug-ins). So a typical structure might look like this:

PDllStruct = ^TDllStruct;
TDllStruct = record
 Title : shortstring;
 Location : shortstring;
 LocLat : double;
 LocLong : double;
 OtherStuff : integer; 
end


and it is used like this:

var
 DllStruct : TDllStruct;
begin
 DllStruct.Title := ebTitle.Text;
 DllStruct.Location := ebLocation.Text;
 
 SendDllStructToPlugIn(@DllStruct);
 
// DLL may fill in or alter various pieces of this structure, so we
cannot use dynamic arrays (strings)... size must remain fixed.
 
 ebTitle.Text := DllStruct.Title;
 ebLocation.Text := DllStruct.Location;
end


Our text entries never exceed 255 characters, however Unicode may be
valuable if we localize our application. I don't believe we can
simply change the ShortString in our structure to a String without
having memory management issues.

But you could use array [0..255] of char as the field type (or a larger
upper bound if needed). You have to use Sysutils.StrPLCopy to copy a
UnicodeString into such a field (to make sure it is zero-terminated),
but you can directly assign the field to a UnicodeString variable.

--
Peter Below
TeamB

Richard Zarr

Posts: 74
Registered: 7/1/98
Re: Best Practices for Implicit String Conversions  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 4, 2016 10:37 AM   in response to: Peter Below in response to: Peter Below
Peter Below wrote:
Richard Zarr wrote:

We do control both ends... we deliberately designed structures to
pass various parameters back and forth with our support DLLs
(plug-ins). So a typical structure might look like this:

PDllStruct = ^TDllStruct;
TDllStruct = record
 Title : shortstring;
 Location : shortstring;
 LocLat : double;
 LocLong : double;
 OtherStuff : integer; 
end


and it is used like this:

var
 DllStruct : TDllStruct;
begin
 DllStruct.Title := ebTitle.Text;
 DllStruct.Location := ebLocation.Text;
 
 SendDllStructToPlugIn(@DllStruct);
 
// DLL may fill in or alter various pieces of this structure, so we
cannot use dynamic arrays (strings)... size must remain fixed.
 
 ebTitle.Text := DllStruct.Title;
 ebLocation.Text := DllStruct.Location;
end


Our text entries never exceed 255 characters, however Unicode may be
valuable if we localize our application. I don't believe we can
simply change the ShortString in our structure to a String without
having memory management issues.

But you could use array [0..255] of char as the field type (or a larger
upper bound if needed). You have to use Sysutils.StrPLCopy to copy a
UnicodeString into such a field (to make sure it is zero-terminated),
but you can directly assign the field to a UnicodeString variable.

--
Peter Below
TeamB


OK... so to be clear, our code would look like this:

type
 PDllStruct = ^TDllStruct;
 TDllStruct = record
 Title : array[0..255] of char; // can handle Unicode...
 Location : array[0..255] of char; // can handle Unicode...
 LocLat : double;
 LocLong : double;
 OtherStuff : integer; 
end;
 
var
 DllStruct : TDllStruct;
begin
 with DllStruct do
 begin
  StrPLCopy(Title, ebTitle.Text, 255);
  StrPLCopy(Location, ebLocation.Text, 255);
 end
 
 SendDllStructToPlugIn(@DllStruct); // fixed on both ends, but this should now work with Unicode...
 
// DLL may fill in or alter various pieces of this structure, so what do we do here to get the values back into the string type?
 ebTitle.Text := DllStruct.Title; // will not work now
 ebLocation.Text := DllStruct.Location;  // will not work now
end
Peter Below

Posts: 1,227
Registered: 12/16/99
Re: Best Practices for Implicit String Conversions  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2016 10:13 AM   in response to: Richard Zarr in response to: Richard Zarr
Richard Zarr wrote:

OK... so to be clear, our code would look like this:

{code}
type
PDllStruct = ^TDllStruct;
TDllStruct = record
Title : array[0..255] of char; // can handle Unicode...
Location : array[0..255] of char; // can handle Unicode...
LocLat : double;
LocLong : double;
OtherStuff : integer;
end;

var
DllStruct : TDllStruct;
begin
with DllStruct do
begin
StrPLCopy(Title, ebTitle.Text, 255);
StrPLCopy(Location, ebLocation.Text, 255);
end

SendDllStructToPlugIn(@DllStruct); // fixed on both ends, but this
should now work with Unicode...
// DLL may fill in or alter various pieces of this structure, so what
do we do here to get the values back into the string type?

ebTitle.Text := DllStruct.Title; // will not work now

But it should work, if Text is a property of type String (Unicodestring
if the DLL has been unicodified). What kind of error message does the
compiler give you for this statement?

A zero-based array of Char is compatible with PChar, and PChar can be
assigned to String, with an automatic conversion happening behind the
scenes.


--
Peter Below
TeamB

Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Best Practices for Implicit String Conversions
Correct
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 4, 2016 10:24 AM   in response to: Richard Zarr in response to: Richard Zarr
Richard wrote:

Our text entries never exceed 255 characters, however Unicode may be
valuable if we localize our application.

One change you could try is to store UTF-8 data in the ShortString values.
As long as the UTF-8 data does not exceed 255 bytes, you will not lose data,
as long as you update the DLLs to expect UTF-8 and not ANSI.

var
  DllStruct : TDllStruct;
begin
  DllStruct.Title := UTF8String(ebTitle.Text);
  DllStruct.Location := UTF8String(ebLocation.Text);
...


Since UTF-8 is backwards compatible with ASCII, you would only have to worry
about potential data loss for UTF-8 lengths > 255. You could build that
logic into your proposed StringToShortString() function, eg:

function StringToUTF8ShortString(S: String): ShortString;
var
  U: UTF8String;
begin
  U := UTF8String(S);
  if Length(U) > 255 then raise ...;
  Result := ShortString(U);
end;
 
var
  DllStruct : TDllStruct;
begin
  DllStruct.Title := StringToUTF8ShortString(ebTitle.Text);
  DllStruct.Location := StringToUTF8ShortString(ebLocation.Text);
...


To convert the UTF-8 ShortString back to a String, just type-cast it:

Title := String(UTF8String(DllStruct.Title));


--
Remy Lebeau (TeamB)
Richard Zarr

Posts: 74
Registered: 7/1/98
Re: Best Practices for Implicit String Conversions  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 4, 2016 11:08 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
Richard wrote:

Our text entries never exceed 255 characters, however Unicode may be
valuable if we localize our application.

One change you could try is to store UTF-8 data in the ShortString values.
As long as the UTF-8 data does not exceed 255 bytes, you will not lose data,
as long as you update the DLLs to expect UTF-8 and not ANSI.

var
  DllStruct : TDllStruct;
begin
  DllStruct.Title := UTF8String(ebTitle.Text);
  DllStruct.Location := UTF8String(ebLocation.Text);
...


Since UTF-8 is backwards compatible with ASCII, you would only have to worry
about potential data loss for UTF-8 lengths > 255. You could build that
logic into your proposed StringToShortString() function, eg:

function StringToUTF8ShortString(S: String): ShortString;
var
  U: UTF8String;
begin
  U := UTF8String(S);
  if Length(U) > 255 then raise ...;
  Result := ShortString(U);
end;
 
var
  DllStruct : TDllStruct;
begin
  DllStruct.Title := StringToUTF8ShortString(ebTitle.Text);
  DllStruct.Location := StringToUTF8ShortString(ebLocation.Text);
...


To convert the UTF-8 ShortString back to a String, just type-cast it:

Title := String(UTF8String(DllStruct.Title));


--
Remy Lebeau (TeamB)

I think you have provided the best solution... array[0..255] of Char. See our sample VCL unit:

unit Unit1;
 
interface
 
uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;
 
type
 TTestStruct = record
  Text : array[0..255] of char;
  Other : double;
  Text2 : array[0..255] of char;
 end;
 
  TForm1 = class(TForm)
    Edit1: TEdit;
    Edit2: TEdit;
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.dfm}
 
procedure TForm1.Button1Click(Sender: TObject);
var
 Struct : TTestStruct;
begin
 StrPLCopy(Struct.Text, Edit1.Text, 255);
 Edit2.Text := Struct.Text;
end;


This effectively copies the string type from the Edit1 (TEdit), to our sample fixed size structure as Unicode (verified with Chinese symbols) and passes it back to a second TEdit control. No warnings on this project when compiling. So... do you see anything wrong with this? We'll need to change about 50-100 structures to reflect this change as well as roughly 2500 string assignment lines... about 20 minutes of work :-), so we want to be sure this is the answer. If so, it now allows localization and consistent Unicode across our entire line of applications.
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Best Practices for Implicit String Conversions
Helpful
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 4, 2016 11:46 AM   in response to: Richard Zarr in response to: Richard Zarr
Richard wrote:

I think you have provided the best solution... array[0..255] of Char.

That is NOT the solution I provided. My solution allows you to continue
using ShortString in your DLL interface with minimal changes on both sides.
By changing ShortString to "array[] of (Wide)Char" in your structure, not
only are you changing its memory layout, but you will have to re-write a
lot more code to accomodate the change on both sides. But, if you are going
to change the interface anyway, you may as well change it to allow dynamic
string lengths, eg:

type
  PDllStruct = ^TDllStruct;
  TDllStruct = record
    Title : PWideChar;
    TitleLen: Integer;
    Location : PWideChar;
    LocationLen : Integer;
    LocLat : double;
    LocLong : double;
    OtherStuff : integer; 
  end;
 
...
 
var
  DllStruct : TDllStruct;
  Title, Location: UnicodeString;
begin
  Title := ebTitle.Text;
  Location := ebLocation.Text;
 
  DllStruct.Title := PChar(Title);
  DllStruct.TitleLen := Length(Title);
  DllStruct.Location := PChar(Location);
  DllStruct.LocationLen := Length(Location);
  ...
  SendDllStructToPlugIn(@DllStruct);
end;


procedure SendDllStructToPlugIn(ds: PDllStruct);
var
  Title, Location: UnicodeString;
begin
  SetString(Title, ds.Title, ds.TitleLen);
  SetString(Location, ds.Location, ds.Location);
  ...
end;


--
Remy Lebeau (TeamB)
Richard Zarr

Posts: 74
Registered: 7/1/98
Re: Best Practices for Implicit String Conversions  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 4, 2016 12:59 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
Richard wrote:

I think you have provided the best solution... array[0..255] of Char.

That is NOT the solution I provided. My solution allows you to continue
using ShortString in your DLL interface with minimal changes on both sides.
By changing ShortString to "array[] of (Wide)Char" in your structure, not
only are you changing its memory layout, but you will have to re-write a
lot more code to accomodate the change on both sides. But, if you are going
to change the interface anyway, you may as well change it to allow dynamic
string lengths, eg:

type
  PDllStruct = ^TDllStruct;
  TDllStruct = record
    Title : PWideChar;
    TitleLen: Integer;
    Location : PWideChar;
    LocationLen : Integer;
    LocLat : double;
    LocLong : double;
    OtherStuff : integer; 
  end;
 
...
 
var
  DllStruct : TDllStruct;
  Title, Location: UnicodeString;
begin
  Title := ebTitle.Text;
  Location := ebLocation.Text;
 
  DllStruct.Title := PChar(Title);
  DllStruct.TitleLen := Length(Title);
  DllStruct.Location := PChar(Location);
  DllStruct.LocationLen := Length(Location);
  ...
  SendDllStructToPlugIn(@DllStruct);
end;


procedure SendDllStructToPlugIn(ds: PDllStruct);
var
  Title, Location: UnicodeString;
begin
  SetString(Title, ds.Title, ds.TitleLen);
  SetString(Location, ds.Location, ds.Location);
  ...
end;


--
Remy Lebeau (TeamB)

OK...there are several options open... let me provide some additional restrictions, but we are examining whether to address this as well. Since the conversion from BDS2006 (pre-Unicode) to RAD Studio 2010 Seattle (Unicode) is quite complicated for us in many dimensions (graphics, Unicode, new controls, Windows 10 support, etc) we are open to making significant changes to our plug-in API as well as internal structures and GUIs. Pretty much everyone that has commented on this level of conversion has stated to update ansi strings to Unicode. We currently only use ShortStrings for descriptions, names, titles, locations, etc. We NEVER use ShortStrings or Strings for buffers... with one exception - our transport layer used a 'string' type for the payload. This will be addressed as a TBytes structure which we can stream to and from the TCP stack.

We wish to limit the lengths of the text fields basically to < 255 characters so we can use a simple SQL VARCHAR() field which is limited to 255 characters in the DB (MySQL has this limit, other DBs do not). Otherwise we need to use BLOB or TEXT fields. So an "array[0..255] of char" is feasible, but we'd need to convert to NVARCHAR where applicable in the various supported DBs (SQLite is Unicode by design). The UTF-8 solution looks like the least impactful, but I want to make sure that before I turn our guys lose to make these changes, we've made the correct architectural decision.

So we're going to review your solutions and may have additional questions next week... thanks very much for the assistance. This change is the most dramatic to our applications and we only want to do this once! :-)
Richard Zarr

Posts: 74
Registered: 7/1/98
Re: Best Practices for Implicit String Conversions  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2016 9:54 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
Richard wrote:

Our text entries never exceed 255 characters, however Unicode may be
valuable if we localize our application.

One change you could try is to store UTF-8 data in the ShortString values.
As long as the UTF-8 data does not exceed 255 bytes, you will not lose data,
as long as you update the DLLs to expect UTF-8 and not ANSI.

var
  DllStruct : TDllStruct;
begin
  DllStruct.Title := UTF8String(ebTitle.Text);
  DllStruct.Location := UTF8String(ebLocation.Text);
...


Since UTF-8 is backwards compatible with ASCII, you would only have to worry
about potential data loss for UTF-8 lengths > 255. You could build that
logic into your proposed StringToShortString() function, eg:

function StringToUTF8ShortString(S: String): ShortString;
var
  U: UTF8String;
begin
  U := UTF8String(S);
  if Length(U) > 255 then raise ...;
  Result := ShortString(U);
end;
 
var
  DllStruct : TDllStruct;
begin
  DllStruct.Title := StringToUTF8ShortString(ebTitle.Text);
  DllStruct.Location := StringToUTF8ShortString(ebLocation.Text);
...


To convert the UTF-8 ShortString back to a String, just type-cast it:

Title := String(UTF8String(DllStruct.Title));


--
Remy Lebeau (TeamB)

This is the solution we've elected. We've created two functions: StringToUTF8ShortString() and UTF8ShortStringToString(). We've also converted any superfluous ShortStrings to Strings (those which exists inside of clients, etc). We've also converted the ShortString type in all of our custom controls to Strings. This fixed a bunch of Unicode problems we were seeing with things like passwords. Thanks for the suggestions and support!
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Best Practices for Implicit String Conversions  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2016 9:59 AM   in response to: Richard Zarr in response to: Richard Zarr
Richard Zarr wrote:

Is there a "best practice" for these types of string conversions

Yes. Get rid of ShortString, string[xx] and AnsiString as much as you
can. Use "string" wherever you can.

I know others have said that, and it is thorough advice.

--
Rudy Velthuis http://www.rvelthuis.de

"You can know the name of a bird in all the languages of the
world, but when you're finished, you'll know absolutely nothing
whatever about the bird... So let's look at the bird and see
what it's doing -- that's what counts. I learned very early
the difference between knowing the name of something and knowing
something." -- Richard Feynman
Lajos Juhasz

Posts: 801
Registered: 3/14/14
Re: Best Practices for Implicit String Conversions  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2016 10:34 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB) wrote:

Richard Zarr wrote:

Is there a "best practice" for these types of string conversions

Yes. Get rid of ShortString, string[xx] and AnsiString as much as you
can. Use "string" wherever you can.

I know others have said that, and it is thorough advice.

You should read the entire post. It's about sending data structures to
dll. Sending string to dll was never the best solution.
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Best Practices for Implicit String Conversions  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 6, 2016 1:32 AM   in response to: Lajos Juhasz in response to: Lajos Juhasz
Lajos Juhasz wrote:

Rudy Velthuis (TeamB) wrote:

Richard Zarr wrote:

Is there a "best practice" for these types of string conversions

Yes. Get rid of ShortString, string[xx] and AnsiString as much as
you can. Use "string" wherever you can.

I know others have said that, and it is thorough advice.

You should read the entire post. It's about sending data structures to
dll. Sending string to dll was never the best solution.

For that, you reserve your own buffer and use PChar or PAnsiChar to
pass it. You keep control over the memory management.

--
Rudy Velthuis http://www.rvelthuis.de

"Five exclamation marks, the sure sign of an insane mind."
-- Terry Pratchett (Reaper Man)
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02