Lajos Juhász

Is the list correct in your example the first numbers are delimited with semicolon while the last is with comma. The easiest way to type this for me is:

function ListContains(const PList: string; PNumber: integer): boolean;
var
  sl: TStringList;
begin
  sl:=TStringList.Create;
  try
    sl.Delimiter:=';';
    sl.DelimitedText:=StringReplace(PList, ',', ';', []);
    result:=sl.IndexOf(IntToStr(PNumber))<>-1;

  finally
    sl.Free;
  end;
end;

You can handle OnMessage for the Applicaton or simple use the OnScroll event of the component.

16 minutes ago, Virgo said:

There does not appear to be anything about progressbar in all this code... Unless  ProgressRunning and StopProgress variables have something to do with it.

There is Form7.pb1.Position (a bad design to call directly from another unit as you cannot be sure that the procedure was called from that object) in the code however that's all we can see (besides the problems that the code full of Application.ProcessMessages also that should be avoided).

You've to create a protocol eg. a prefix that will say the following x bytes is a string or a binary data so the reciever can convert the received bytes back.

Even some Unicode arrow characters are not supported by the IDE :(.

3 hours ago, Serge_G said:

But I don't understand where I miss something because I have some memoryleaks

---------------------------

It's very simple take a look at TImage.SetBitmap. The TImage object will assign the bitmap to the internal bitmap and will not take the ownership over of the parameter. You've to write:
 

var 
  lbm: TBitmap;
begin
  if OpenDialog1.Execute then
  begin
    Image1.Bitmap.LoadFromFile(OpenDialog1.FileName);
    lbm:=ConvertToGrayscale(image1.Bitmap);
    try
      Image2.Bitmap:=lbm;
    finally
      lbm.Free;
    end;
  end;  
end;

Maybe this thread can help (I have no experience with thermal printers).

I've also tested:

finalValue:=2*index + ResultIsFive(index);

the result 9. I guess this is one of the reasons why you should not write procedures with side effects. It can make a mission impossible to find the them.

Changing a DPI can also cause the following error message:

---------------------------
Debugger Exception Notification
---------------------------
Project XXXXX.exe raised exception class EReadError with message 'Stream read error'.
---------------------------
Break   Continue   Help   Copy   
---------------------------
 

With call stack: 

:7538b522 KERNELBASE.RaiseException + 0x62
:030f850a HookedRaiseException + $66
:50162931 rtl280.@System@Classes@TReader@ReadBuffer$qqrio + 0x55

After that the following exception is:

First chance exception at $7538B522. Exception class EArgumentOutOfRangeException with message 'Argument out of range'. Process XXXXX.exe (17800)

:7538b522 KERNELBASE.RaiseException + 0x62
:030f850a HookedRaiseException + $66
:50159093 rtl280.@System@Classes@TCollection@GetItem$qqri + 0x13
:50159093 rtl280.@System@Classes@TCollection@GetItem$qqri + 0x13
:50cc5327 vcl280.@Vcl@Controls@TControl@Resize$qqrv + 0x1b
:50ccac1a ; C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\vcl280.bpl
:50ccacec vcl280.@Vcl@Controls@TWinControl@AlignControl$qqrp21Vcl@Controls@TControl + 0x68
:50ccad47 vcl280.@Vcl@Controls@TWinControl@Realign$qqrv + 0x7
:50ccf78c vcl280.@Vcl@Controls@TWinControl@ScaleForPPI$qqri + 0xc8
:50ccf78c vcl280.@Vcl@Controls@TWinControl@ScaleForPPI$qqri + 0xc8
:50ccf78c vcl280.@Vcl@Controls@TWinControl@ScaleForPPI$qqri + 0xc8
:50ccf78c vcl280.@Vcl@Controls@TWinControl@ScaleForPPI$qqri + 0xc8
:50ccf78c vcl280.@Vcl@Controls@TWinControl@ScaleForPPI$qqri + 0xc8
:50ccf78c vcl280.@Vcl@Controls@TWinControl@ScaleForPPI$qqri + 0xc8
:50ccf78c vcl280.@Vcl@Controls@TWinControl@ScaleForPPI$qqri + 0xc8
:50e021a3 vcl280.@Vcl@Forms@TCustomForm@ScaleForPPIRect$qqrip18System@Types@TRect + 0x9b
:fffffff8

I don't have a test case for this as I put it on delay and re-testing with D12. Since Embarcadero thinks that it is not relevant to give a valid roadmap I promised to management at the company I work for that this should be fixed in Delphi 12. It's bad that Embarcadero follows the pattern from the past and now entered into the period when they hide every possible information.

On 10/17/2021 at 12:44 PM, dummzeuch said:

Has anybody else seen this?

Could be RSP-30614 maybe you could update that in D11 it's still not working at all?

There is also RSP-36616 where trace into FD source doesn't work when the application is build with run time packages. Unfortunately it's not confirmed yet from Embarcadero.

16 minutes ago, David Heffernan said:

No. The try finally here protects the lifetime management of the instantiated object, after the constructor has completed. An exception in the constructor will bubble up from here and never enter the try. This is a very very common misunderstanding. 

Exactly what I was saying.

In case you'write:

try

  lObj:=TMyClass.create;

finally

  lObj.Free;

end;

If the constructor raises the exception the RTL will clear that for you. However in case lObj as the name suggest is a local variable and you didn't assigned nil to it the value will be undefined and calling free on that reference can cause AV (in case you're not lucky that the value was nil).

13 minutes ago, David Heffernan said:

Again, can somebody explain what problem is caused by raising in a constructor

The only problem with it is that you've to write your code in form:

lObj:=TMyClass.Create(....);
try
.....
finally
  lObj.Free;
end;

Anyway you would write it in this form. So there is no problem. I believe it's just another phobia. People can be afraid from correct coding style but will happily use FreeAndNil everywhere in the code.

You missed the example with nested try finally. It should be:

 

    LA := TRaiseOnMinus.Create( AInputA );	//<== PossibleRaise
    try
        LB := TRaiseOnMinus.Create( AInputB );	//<== Possible Raise
        try
        finally
          LB.Free;
        end;
    finally
        LA.Free; 
    end;

You can use multiple try finally or>

LA := nil;
LB := nil;
try
    LA := TRaiseOnMinus.Create( AInputA );	//<== PossibleRaise
    LB := TRaiseOnMinus.Create( AInputB );	//<== Possible Raise
finally
  LA.Free;
  LB.Free;
end;

In this case before try LA and LB are both nil in case a constructor raises an exception it will still be NIL thus Free will do nothing.

26 minutes ago, Celso Henrique said:

Now, the newest and the best one. The compiler is not accepting the value 452 for a smallint property.

Wrong. The compiler doesn't accept 452 as a member of set of byte. You cannot define a set over a smallint range. 

It's a missing property for TIDMessage class and it's not related to win10. Search in dfm files for DeleteTempFiles and remove the property. In Indy10 TIdMessage doesn't have that property. I don't know whenever it ever had that property (I've never worked with that old version of Indy).

Edit: The only case when the application is compiled to use runtime packages. In that case if you provide the wrong bpls for Indy could result this error.

I cannot reproduce this in a simple test program. What I did is placed a TFDMemTable into a form:

  object FDMemTable1: TFDMemTable
    FetchOptions.AssignedValues = [evMode]
    FetchOptions.Mode = fmAll
    ResourceOptions.AssignedValues = [rvSilentMode]
    ResourceOptions.SilentMode = True
    UpdateOptions.AssignedValues = [uvCheckRequired, uvAutoCommitUpdates]
    UpdateOptions.CheckRequired = False
    UpdateOptions.AutoCommitUpdates = True
    Left = 304
    Top = 224
    object FDMemTable1a: TIntegerField
      FieldName = 'a'
    end
    object FDMemTable1b: TStringField
      FieldName = 'b'
      Size = 150
    end
  end
 

and a button with the following onclick event:

 

procedure TForm1.Button1Click(Sender: TObject);
begin
  if not FDMemTable1.Active then
    FDMemTable1.CreateDataSet
  else
  begin
//    FDMemTable1.Open; <- There is no need to do this Active is true
    FDMemTable1.EmptyDataSet;
  end;

  FDMemTable1.Append;
  FDMemTable1['a']:=1;
  FDMemTable1['b']:='1';
  FDMemTable1.Append;
  FDMemTable1['a']:=2;
  FDMemTable1['b']:='2';
  FDMemTable1.Append;
  FDMemTable1['a']:=3;
  FDMemTable1['b']:='3';
  FDMemTable1.Append;
  FDMemTable1['a']:=4;
  FDMemTable1['b']:='4';
  FDMemTable1.Post;
end;

It's working with multiple clicks.

1 hour ago, Vandrovnik said:

strings are not limited to 255 chars...

since Delphi 2.

In case you're connecting to remote servers you have to buy Enterprise or Architect version. Professional supports only local databases and doesn't include the source code for FD.

Before you open the project you have to migrate your project using the included refind utility using the included FireDAC_Migrate_BDE.txt.

9 minutes ago, audi30tdi said:

Is it easy to convert from Delphi7 with BDE to the nevest Delphi/Embarcadero version with FireDAC, or must I rewrite all my code??

FireDAC was written to be replacement for the BDE and there is a script that converts the properties. It really depends the database and methods from BDE you are using in your code.

Unfortunately if you're using persistent fields you will have to recreate them as most probably FD will require another class.

(You can try to map the data types in the TFDConnection object to the old classes, however I like to keep mapping to minimum.)

BDE is deprecated for 20 years. You can upgrade Delphi but that will change nothing how BDE interacts with Windows. The only solution is to migrate the application to anothe DAC.

In Delphi 11 F11 will eventually focus that part of the object inspector.

Maybe you should try the old way. Append the memtable and set the value for the fields. Depending if you have only couple of fields you can write an the assign statements otherwise use a for loop.

Something like this should work (you're copying the structure thus the order of the fields should be the same):

var

  i: integer;

begin
  kbmMemTable.Append;

  for i:=0 to kbmMemTable.fieldCount-1 do

     kbmMemTable.fields.value:=myTEDBTable.fields.value;

end;

7 hours ago, Qasim Shahzad said:

Now Please guide why this is a bad idea. It reduces a lot of code duplication and we can add Form Creation procedure in a common library.

When you're displaying the forms this way they are useless there are no input values to the form and the form doesn't produce any result. You're destroying the instance before the calling code could read the results back.

I am aware that you can initialize the form in the formcreate and write the results back in formdestroy but that is a bad design.