Convert TStream to String? - string

In Delphi 10.4, I try to convert a TStream to a string with this code:
function MyStreamToString(aStream: TStream): string;
var
SS: TStringStream;
begin
if aStream <> nil then
begin
SS := TStringStream.Create('');
try
SS.CopyFrom(aStream, 0); // Exception: TStream.Seek not implemented
Result := SS.DataString;
finally
SS.Free;
end;
end else
begin
Result := '';
end;
end;
But in this code line, I get an exception "TStream.Seek not implemented": SS.CopyFrom(aStream, 0);
Why? How can I "heal" this code?

The error means you are passing your function a TStream object that does not implement Seek() at all. Such as if you are passing in an actual TStream object and not a derived object, like TFileStream, TMemoryStream, etc, for instance:
var
Strm: TStream;
begin
Strm := TStream.Create; // <-- ERROR
try
MyStreamToString(Strm);
finally
Strm.Free;
end;
end;
TStream is an abstract base class, it should never be instantiated directly.
In this case, the 32-bit Seek() method in the base TStream class calls the 64-bit Seek() method, but will raise that "Seek not implemented" exception if the 64-bit Seek() has not been overridden. A TStream-derived class must override either the 32-bit Seek() or the 64-bit Seek(), and the overridden method must not call the base TStream method it is overriding.
So, make sure you are passing in a valid stream object to your function.

Related

Compile Error when trying to return PChar or OleVariant for UDF

The title doesn't quite capture the essence of the issue.
I have a UDF function that returns a PChar.
function AccountDescription(sAccountId: PChar) : PChar; stdcall;
This was working fine but I realized I wanted to return #N/A if the accountId was not found.
I discovered CVErr(xlErrNA) and changed the Signature to return OleVariant.
But now I am receiving [Error] Incompatible types: 'OleVariant' and 'PAnsiChar'.
I could not find any information on how to resolve this so I figure my understanding of the problem must not be correct.
I tried just passing a string which compiled but produced a runtime error of "Invalid variant type".
The full code is:
function AccountDescription(sAccountId: PChar): OleVariant; stdcall;
var
strResult: string;
strPChar : PChar;
begin
try
strResult:= repo.GetAccount(sAccountId).Description;
strPChar := strAlloc(length(strResult)+1) ;
StrPCopy(strPChar, strResult) ;
Result := strPChar;
except
Result := CVErr(xlErrNA);
end;
end;
Note: Is excel responsible for destroying the string or is that my cleanup? Should I be creating a copy or should I just be returning a pointer to an existing string. After typing it I feel like I should be returning a pointer.
Update:
Removed some irrelevant code in the example.
Now using:
function AccountDescription(sAccountId: PChar): OleVariant; stdcall;
var
strResult: string;
begin
try
Result := PChar(repo.GetAccount(sAccountId).Description);
except
Result := CVErr(xlErrNA);
end;
end;
You do not need the PChar cast, you can assign a String directly to an OleVariant (it will be converted by the RTL into a BSTR that the receiver will then free when done using it):
Result := repo.GetAccount(sAccountId).Description;
As for reporting an error, do you have a viable CVErr() function in your Delphi code? In VB, CVErr() returns a Variant of type Error (varError in Delphi) containing an error code (xlErrNA is 2042). Delphi has a VarAsError() function for that same purpose:
Result := VarAsError(2042);

Delphi thread return value

Can someone explain to me how I get a return value from myThread calling function test?
function test(value: Integer): Integer;
begin
Result := value+2;
end;
procedure myThread.Execute;
begin
inherited;
test(Self.fParameters);
end;
procedure getvaluefromthread();
var
Capture : myThread;
begin
list := TStringList.Create;
Capture := myThread.Create(False);
Capture.fParameters := 2;
Capture.Resume;
end;
Declare a class derived from TThread.
Add a field, or multiple fields, to contain the result value or values.
Set the result value field(s) in the overridden Execute method.
When the thread has finished, read the result from the thread instance.
As Remy points out, if you wish to return just a single Integer value, then you can use the ReturnValue property of TThread. Use this in just the same way as described above. Note that the value placed in ReturnValue is the value returned by the underlying OS thread.
You can listen for OnTerminate to find out when thread is done. Or call WaitFor.
Note that you set the thread's parameters after it starts running. Either create the thread suspended, or pass the parameters to the constructor. Also, you should use Start rather than Resume. The latter is deprecated.

TStringList CustomSort method in FreePascal

What am I doign wrong with the following code
function CompareFloat(List: TStringList; Index1, Index2: Integer): Integer;
and I call it as :
var
SL :TstringList;
SL.CustomSort(CompareFloat);
//SL.CustomSort(#CompareFloat); // Tried this one also
The first function call 'SL.CustomSort(CompareFloat)' retrieves that error from compiler "Error: Wrong number of parameters specified for call to "CompareFloat"
Second function call 'SL.CustomSort(#CompareFloat)' retrieves that error from compiler Error: Only class methods can be referred with class references
SL.CustomSort(CompareFloat); works if you add {$mode delphi} directive to somewhere to the beginning of a unit.
However SL.CustomSort(#CompareFloat); should work fine. Make sure the error message is not caused by something else.
Example:
program Project1;
//{$mode delphi}
uses
Classes,
SysUtils;
function CompareFloat(List: TStringList; Index1, Index2: Integer): Integer;
begin
Result := StrToInt(List[Index1]) - StrToInt(List[Index2]);
end;
var
SL: TStringList;
begin
SL := TStringList.Create;
try
SL.Add('3');
SL.Add('2');
SL.Add('1');
SL.CustomSort(#CompareFloat);
//SL.CustomSort(CompareFloat);
Writeln(SL[0], SL[1], SL[2]);
Readln;
finally
SL.Free;
end;
end.

Are `const` string parameters (thread) safe

This code
procedure MyThreadTestA(const AStr: string);
Is faster than
procedure MyThreadTestB(AStr: string);
Whilst doing the same work, both pass a pointer.
However version B 'correctly' updates the referencecount of AStr and makes a copy if I change it.
Version A passes just a pointer and only the compiler prevents me from changing AStr.
Version A is not safe if I do dirty tricks in Assembler or otherwise to circumvent the compiler protection, this is well known but...
Is passed AStr by reference as a const parameters thread safe?
What happens if AStr's reference count in some other thread goes to zero and the string is destroyed?
No, such tricks are not thread-safe. Const prevents the add-ref, so changes by another thread will affect the value in unpredictable ways. Sample program, try altering the const in the definition of P:
{$apptype console}
uses SysUtils, Classes, SyncObjs;
type
TObj = class
public
S: string;
end;
TWorker = class(TThread)
public
procedure Execute; override;
end;
var
lock: TCriticalSection;
obj: TObj;
procedure P(const x: string);
// procedure P(x: string);
begin
Writeln('P(1): x = ', x);
Writeln('Releasing obj');
lock.Release;
Sleep(10); // give worker a chance to run
Writeln('P(2): x = ', x);
end;
procedure TWorker.Execute;
begin
// wait until TMonitor is freed up
Writeln('Worker started...');
lock.Acquire;
Writeln('worker fiddling with obj.S');
obj.S := 'bar';
TMonitor.Exit(obj);
end;
procedure Go;
begin
lock := TCriticalSection.Create;
obj := TObj.Create;
obj.S := 'foo';
UniqueString(obj.S);
lock.Acquire;
TWorker.Create(False);
Sleep(10); // give worker a chance to run and block
P(obj.S);
end;
begin
Go;
end.
But it's not just limited to threads; modifying the underlying variable location has similar effects:
{$apptype console}
uses SysUtils, Classes, SyncObjs;
type
TObj = class
public
S: string;
end;
var
obj: TObj;
procedure P(const x: string);
begin
Writeln('P(1): x = ', x);
obj.S := 'bar';
Writeln('P(2): x = ', x);
end;
procedure Go;
begin
obj := TObj.Create;
obj.S := 'foo';
UniqueString(obj.S);
P(obj.S);
end;
begin
Go;
end.
To add to Barry's answer: It is definitely thread-safe if the string that got passed came from a local variable inside the callers scope.
In that case that local variable will hold a valid reference and the only way (assuming just valid pascal code, no fiddling around in asm) for that local variable to be changed is if your call returns.
This also includes all cases where the source of the string variable is the result of a function call (including property access, e.g. TStrings.Strings[]) because in this case the compiler has to store the string in a local temp variable.
Thread-safety problems can only result if you are directly passing a string from a location where that string can be changed (by the same or another thread) before your call returns.

BeginThread Structure - Delphi

I've got a almost completed app now and the next feature I want to implement is threading. I chose to go with BeginThread(), although am aware of TThread in delphi. The problem I'm coming across is the structure of BeginThread() call. Normally the line in the program that would call the function I want to be threaded is
CompareFiles(form1.Edit3.Text,Form1.Edit4.Text,Form1.StringGrid2,op);
op is a integer.
The line I've switched it out for to create a thread from it is
BeginThread(nil,0,CompareFiles,Addr('form1.Edit3.Text,Form1.Edit4.Text,Form1.StringGrid2,op'),0,x);
From the little amount of infromation I can find on how to actually use BeginThread() this should be a fine call, however on compling all I get is complier errors regarding the structure of my BeginThread() statement paramenters.
EDIT FOR INFORMATION.
The current procedure that calls CompareFiles is
procedure TForm1.Panel29Click(Sender: TObject);
var
op,x : integer;
begin
if (Form1.Edit3.Text <> '') AND (Form1.Edit4.Text <> '') then
begin
op := 3;
if RadioButton7.Checked = True then op := 0;
if RadioButton3.Checked = True then op := 1;
if RadioButton4.Checked = True then op := 2;
if RadioButton5.Checked = True then op := 3;
if RadioButton6.Checked = True then op := 4;
CompareFiles(form1.Edit3.Text,Form1.Edit4.Text,Form1.StringGrid2,op);
end;
end;
If I was to use TThread as suggested by a couple of people, and as displayed by Rob below, I'm confused at how a) I would pass op,Edit3/4.Text and StringGrid2 to the CompareFiles. Guessing from the example of TThread I've seen I thought I would replace the code above with TCompareFilesThread.Executeand the put the current code from Panel29Click into TCompareFilesThread.Create and then add
FEdit3Text := Edit3Text;
FEdit4Text := Edit4Text;
FGrid := Grid;
to this
FEdit3Text := Form1.Edit3.Text;
FEdit4Text := Form1.Edit4.Text;
FGrid := Form1.StringGrid2;
But I've got this nagging feeling that is totally off the mark.
That's not at all the way to use BeginThread. That function expects a pointer to a function that takes one parameter, but the function you're trying to call wants four. The one parameter you're giving to BeginThread for it to forward to the thread procedure is a string, but you evidently hope that some sort of magic will turn that string of characters into the values that those variables contain.
That's not how Delphi works, and even for the languages that can do something like that, it's generally discouraged to actually do it.
To pass multiple parameters to BeginThread, define a record with all the values you'll need, and also define a record pointer:
type
PCompareFilesParams = ^TCompareFilesParams;
TCompareFilesParams = record
Edit3Text,
Edit4Text: string;
Grid: TStringGrid;
Op: Integer;
end;
Change CompareFiles to accept a pointer to that record:
function CompareFiles(Params: PCompareFilesParams): Integer;
To start the thread, you'll need to allocate an instance of that record and populate its fields:
var
Params: PCompareFilesParams;
begin
New(Params);
Params.Edit3Text := Edit3.Text;
Params.Edit4Text := Edit4.Text;
Params.Grid := StringGrid2;
Params.Op := op;
BeginThread(nil, 0, #CompareFiles, Params, 0, x);
Implement CompareFiles like this so that the record will get freed before the thread terminates:
function CompareFiles(Params: PCompareFilesParams): Integer;
begin
try
// <Normal implementation goes here.>
finally
Dispose(Params);
end;
end;
You can make it all a lot easier if you just use TThread, though. You can make your descendant class have as many parameters as you want in its constructor, so you don't have to mess around with dynamically allocating and freeing a special record.
type
TCompareFilesThread = class(TThread)
private
FEdit3Text,
FEdit4Text: string;
FGrid: TStringGrid;
FOp: Integer;
procedure Execute; override;
public
constructor Create(const Edit3Text, Edit4Text: string; Grid: TStringGrid; Op: Integer);
property ReturnValue;
end;
constructor TCompareFilesThread.Create;
begin
inherited Create(False);
FEdit3Text := Edit3Text;
FEdit4Text := Edit4Text;
FGrid := Grid;
FOp := Op;
end;
procedure TCompareFilesThread.Execute;
begin
ReturnValue := CompareFiles(FEdit3Text, FEdit4Text, FGrid, FOp);
end;
Instead of calling BeginThread, you just instantiate the class and let it run:
var
ThreadRef: TThread;
ThreadRef := TCompareFilesThread.Create(Edit3.Text, Edit4.Text, StringGrid2, Op);
There's more to using threads, such as knowing when the thread has finished running, but I think you have enough to get started. One last thing to beware of, though, is that TStringGrid is a VCL control. You mustn't do anything with it from this new thread you create (regardless of how you end up creating it). Eveything you do with the grid control need to be done from the main thread. Use TThread.Synchronize and TThread.Queue to shift any VCL operations onto the main thread. Your file-comparing thread will wait for the synchronized operation to complete, but it will keep running without waiting for a queued operation to complete.

Resources