Leaderboard

Seems like dogma to me. Are you really saying that if a method uses more than 5 values of input data then it needs to be passed via properties rather than arguments? Many problems with that. Let's consider just one, thread safety.

Your code can be simplified in several ways. I will write each step separately, so you can more easily adapt your code if you need additional functionality beyond the code shown here. First, as I mentioned in previous post, you don't need to write getter and setter functions at all, if you just read or write field in those and noting more. First optimization would be removing all that redundant code. This is not just speed optimization, but also makes cleaner code that is easier to read and follow. This code is functionally completely equivalent to your declaration and you would create and initialize the form the same way you do now. TTracksAddEditForm = class(TForm) private FsMode: string; FiAlbum: integer; FsTrack: string; public property sMode: string read FsMode write FsMode; property iAlbum: integer read FiAlbum write FiAlbum; property sTrack: string read FsTrack write FsTrack; end; Your next question was whether you need to have both getters and setters. If you are just setting property, then you don't need getter. Similarly, if you have read only property that you will just read, then you don't need setter. So next optimization would be following. There is no difference in how you create and initialize your form. TTracksAddEditForm = class(TForm) private FsMode: string; FiAlbum: integer; FsTrack: string; public property sMode: string write FsMode; property iAlbum: integer write FiAlbum; property sTrack: string write FsTrack; end; procedure TAudioForm.btnInsertTrackClick(Sender: TObject); begin TracksAddEditForm := TTracksAddEditForm.Create(Self); TracksAddEditForm.sMode := 'Insert'; TracksAddEditForm.iAlbum := Albums.FieldByName('Index').AsInteger; TracksAddEditForm.sTrack := TracksView.FieldByName('Title').AsString; TracksAddEditForm.Show; end; But, the best way to initialize any class that you will construct through code (without bringing in dependency injection) would be declaring all required information as parameters to the constructor, Such code would also require different code when constructing form. TTracksAddEditForm = class(TForm) private FsMode: string; FiAlbum: integer; FsTrack: string; public constructor Create(AOwner: TComponent; const AsMode: string; AiAlbum: integer; const AsTrack: string); reintroduce; end; procedure TAudioForm.btnInsertTrackClick(Sender: TObject); begin TracksAddEditForm := TTracksAddEditForm.Create(Self, 'Insert', Albums.FieldByName('Index').AsInteger, TracksView.FieldByName('Title').AsString); TracksAddEditForm.Show; end; The advantage of passing all required data as parameters during construction process is that you cannot accidentally forget to initialize some required field. If some fields are optional, then you can stick to initializing through properties, but using simplified examples before this last one.

Apparently, this is a known bug since inline variables were first introduced in 10.3 Rio, and the following tickets are still open: RSP-22359: Nameless types are not allowed within inline variable declarations RSP-31970: How to inline static array variables in Rio Based on the comments on the tickets, the workaround I suggested earlier to pre-define the array type should work for an inline variable: type Char256Array = array [0 .. 255] of Char; var buffer: Char256Array;

Never mind what the ide says. What does the compiler say?

function TForm7.GetMyStationNameFromAngleMethod( const AAngle : Single ) : String; const CStations : array[0..24-1] of String = ( 'New York, 'Honolulu', 'Tokyo' ... 'Paris' ); var LIdx : Integer; begin LIdx := AAngle div 15.0; // 0 ... 360 to 0 ... 23 Result := CStations[ LIdx ]; end; function TForm7.GetMyStationFreqFromAngleMethod( const AAngle : Single ) : Single; begin Result := (AAngle / 360.0) * 200.0; // 0 ... 360 to 0 ... 200.0 MHz end; procedure TForm7.KnobLeftClick(Sender: TObject); begin MyRoundRect.RotationAngle := MyRoundRect.RotationAngle - 15.0; Label1.Text := Format( 'My station is %s at %4.0f MHz, [ GetMyStationNameFromAngleMethod( MyRoundRect.RotationAngle ), GetMyStationFreqFromAngleMethod( MyRoundRect.RotationAngle ) ] ); end; procedure TForm7.KnobRightClick(Sender: TObject); begin MyRoundRect.RotationAngle := MyRoundRect.RotationAngle + 15.0; Label1.Text := Format( 'My station is %s at %4.0f MHz, [ GetMyStationNameFromAngleMethod( MyRoundRect.RotationAngle ), GetMyStationFreqFromAngleMethod( MyRoundRect.RotationAngle ) ] ); end; I assume you want to display the station name and frequency, right ? Just a rough idea, its already very late here ... Since I don't know exactly what you need this is a wild guess 🙂

procedure TForm7.FormCreate(Sender: TObject); begin MyRoundRect.RotationCenter.Point( Pointf( MyRoundRect.Position.X + MyRoundRect.Width / 2.0, MyRoundRect.Position.Y + MyRoundRect.Height / 2.0 ) ); end; procedure TForm7.KnobLeftClick(Sender: TObject); begin MyRoundRect.RotationAngle := MyRoundRect.RotationAngle - 15.0; end; procedure TForm7.KnobRightClick(Sender: TObject); begin MyRoundRect.RotationAngle := MyRoundRect.RotationAngle + 15.0; end; Something similar like this (Untested) ? Or even adding some smooth animation by TFloatAnimation, like this.

This is hardly uncommon. Otherwise why pay for maintenance, ever, until you "need" it?

If the information needs to be transmitted, it has to get there somehow.

So I suggest you to use Frames and a ScrollBox (or VertScrollBox or HorzScrollBox) Here my "french" way to do it. But I remember also a some videos of CodeRage 2019 #13

I would not bother with the constructor just add a method for setup and show: procedure TTracksAddEditForm.ShowForm(const AsMode: string; AiAlbum: integer; const AsTrack: string); begin FsMode := AsMode; FiAlbum := AiAlbum; // or set the controls directly FsTrack := AsTrack; Show; end; use it: TTracksAddEditForm.Create(Self).ShowForm('Insert', blah, buh); or for showmodal function TSomeValueReturningForm.ShowForm(var AVar: string): TModalResult; begin FVar := AVar; Result := ShowModal; AVar := FVar; end; use it: lStringVar := 'Initialvalue'; case TSomeValueReturningForm.Create(Self).ShowForm(lStringVar) of mrOk: DoSomething(lStringVar); else Whatever... end; the variable var TracksAddEditForm : TTracksAddEditForm; is only needed if the forms are created with Application.CreateForm() by the dpr itself. Otherwise it should be deleted immediately.

...or you can use default parameters or even overloaded constructors with different parameters.

Apart from data validation as suggested above, you can use setters and getters for other purposes e.g procedure SetName(NewName: string); begin if NewName<>fName then begin fName := NewName; ProjectNotSaved := true; end; end;

Getters and Setters are methods called when you get (read) or set (write) property. In Delphi you don't need to have getter and setter methods. Properties can be directly connected to a field. You use getters or setters when you want to run additional code besides directly reading or writing some field value. Following is basic property declaration without any getters or setters. When you access property, compiler just directly reads or writes from associated field. TFoo = class protected FValue: Integer; published property Value: Integer read FValue write FValue; end; Following is property declaration with setter method (you can have any combination you need and you don't need to declare both methods if you just need one of them) TFoo = class protected FValue: Integer; procedure SetValue(AValue: Integer); published property Value: Integer read FValue write SetValue; end; Because getters and setters are methods, they will be a bit slower than directly using a field. If your setter is just setting a field and does nothing more, then you don't really need it. Same goes for getter. If it just returns the field then it is not needed. procedure TFoo.SetValue(AValue: Integer); begin FValue := AValue; end; If for instance you don't want to allow setting Value to zero, you might have following code in a setter. procedure TFoo.SetValue(AValue: Integer); begin if AValue <> 0 then FValue := AValue; end; You can even raise an exception if you set property to invalid value or similar. The only time when you would need to use getters and setters that just read or write to a field, is when your property needs to be accessible through interface. Interfaces require that getters and setters are methods.

If the code still makes sense to you years latter and you can follow it without difficulty then there should be no complaints. Applying a rule or guideline too rigidly before the skill or knowledge to do so has been acquired often makes things worse. In your example learning how to use continue; or break; to control the flow of a for loop would be best but applying a no goto rule and using multiple cascading IF's around a large blocks of code could be worse than just using a goto. The top hall of shame code I have ever seen was due to developers rigidly applying rules before the skill and knowledge to do so was acquired. It made the code more complex and a lot harder to follow to the point is was often easier to just re-write it from scratch.

They seem to have serious issue with their base. In what world "ensure" rhymes with "fire"? Or they just dumbly took all words ending with "re"?

IMO, the modern alternative is a decent website. I was a member of the ASP and even sat on its Board for two years. Like PAD, it served its purpose and is now completely obsolete. Honestly, if I could take down every single file download site listing of my software, I would. People find your software with search engines, not download sites. Today, download sites exist to siphon visitors away from direct sources so they can shovel borderline malware at visitors with useless file download and scanner tools, etc.

Nevermind.. solved the issue.. !