Leaderboard

In a word, no. However, if you intend to use the extended component in just one form/project, and don't mind setting the new properties in code at runtime rather than with the Object Inspector at design-time, then you could use an interposer class to add the properties, and that way you don't have to make the extra effort of putting the new component in a new package and installing it into the IDE. For example: unit MyUnit; interface uses ..., Vcl.Forms, Vcl.StdCtrls, System.IniFiles, ...; type TCheckBox = class(Vcl.StdCtrls.TCheckBox) public IniSection: string; IniProperty: string; procedure LoadFromIni(Ini: TCustomIniFile); procedure SaveToIni(Ini: TCustomIniFile); end; TMyForm = class(TForm) SomeCheckBox: TCheckBox; procedure FormCreate(Sender: TObject); ... private procedure LoadConfig; procedure SaveConfig; end; ... implementation ... procedure TCheckBox.LoadFromIni(Ini: TCustomIniFile); begin Checked := Ini.ReadBool(IniSection, IniProperty, False); end; procedure TCheckBox.SaveToIni(Ini: TCustomIniFile); begin Ini.WriteBool(IniSection, IniProperty, Checked); end; procedure TMyForm.FormCreate(Sender: TObject); begin SomeCheckBox.IniSection := ...; SomeCheckBox.IniProperty := ...; end; procedure TMyForm.LoadConfig; var Ini: TIniFile; begin ... SomeCheckBox.LoadFromIni(Ini); ... end; procedure TMyForm.SaveConfig; var Ini: TIniFile; begin ... SomeCheckBox.SaveToIni(Ini); ... end;

An easy way to introduce new methods and properties to components on a form is to use interposers: type TCheckBox = class(StdCtrls.TCheckBox) private FGroup: string; FValue1: string; FValue2: string; public property Group: string read FGroup write FGroup; property Value1: string read FValue1 write FValue1; property Value2: string read FValue2 write FValue2; end; Insert this in the interface section of your form unit. It must be before the declaration of the form. You can also put it in a separate unit but then you need to ensure that that unit is referenced after StdCtrls. Basically, this trick fools the Delphi DFM loader into creating an instance of your TCheckBox class instead of the standard one in StdCtrls. Note that interposers only enables you to extend a component at run-time. The design-time environment (i.e. the Delphi IDE) knows nothing about this trickery so the new properties will not appear in the property inspector (which is also why I didn't bother declaring them as published). If you want design-time support you will have to create and register a custom component the normal way.

Or if you want to go fancy, then build a class/component (a manager) that do that automatically, i mean enumerate all the controls and create an ini file with them, while it such in design time will enumerate all the controls and have a list at design time that can be checked to include/exclude from saving. Building such component will give you huge experience while being fun.

https://ib-aid.com/en/articles/detailed-new-features-of-firebird-5-part-1-improvements-in-optimizer My preliminary tests on our product(s) show that FB5 is clearly faster than FB4. Did not need to measure result, because you could see/feel it very easily. When you saw Vista Wheel with FB4, on top of FB5 you can't even see it, form just opens faster. For sure there will be some corner cases when some query, very carefully optimized for older version of FB will perform worse in FB5. At least always there had been some "regressions". But for every new Firebird release, there has been performance increase. FB5 is close to the release, so please evaluate is best as you can, and report any bugs or regressions ASAP, so they could be addressed before release. -Tee-

https://firebirdsql.org/en/firebird-5-0/ New In Firebird 5.0 Summary of New Features Firebird 5.0 introduces many improvements without any changes in architecture or operation, the most important are: Parallel (multi-threaded) operation for backup/restore, sweep and index creation; Partial indices; SKIP LOCKED clause for SELECT WITH LOCK, UPDATE and DELETE statements; Inline minor ODS upgrade; Compiled statement cache; PSQL and SQL profiler; Support for WHEN NOT MATCHED BY SOURCE for MERGE statement; Support multiple rows for DML RETURNING; New built-in functions and packages; Denser record-level compression; Network support for scrollable cursors;

Programmers have a strange way of thinking that I don't understand. Because I'm not a pro-programmer. That's the case here. I'm dealing with something similar. It is about setting values and appearance of individual components on a form. I'm using JSON to do this. That's a significant difference, because you're using IniFile. The principle is simple. The title consists of the names: Owner (form) + Parent + Component The result is e.g.: "frmsubMatchesByRoundfdnvDraw": { "jstpnlTeamVst": { "jstvstTeam": { "VTSearchDirection": 0, "Width": [ 120,165,100,84,167], "Position": [ 0,1,2,3,4], "SortColumn": -1, "VTSearchStart": 2, "ShowSortGlyphs": false, "FirstSetFocus": false, "VTSortDirection": 0 } }, ... }, To do this, functions of the type Read..., Write... function TAppearance.DoCareNoEdit(const ACont: TControl): Boolean; begin Result := True; if (ACont is TAdvOfficeRadioButton) then CareAdvOfficeRadioButton(TAdvOfficeRadioButton(ACont)) else if (ACont is TjstVirtualStringTree) then CarejstVirtualStringTree(TjstVirtualStringTree(ACont)) ... procedure TAppearance.CarejstVirtualStringTree(const AComp: TjstVirtualStringTree); begin AComp.ParentDoubleBuffered := True; FjstVst := AComp; FJsonItemName := oGlobVar.ActualForm.Name +'.'+ FjstVst.Parent.Name +'.'+ FjstVst.Name +'.'; CreateVstPopupMenu; SetVstProperties; end; Hopefully this will help in some way. If I haven't hit the topic at all, then ignore it

How about a collection of check boxes TCheckListBox The sample simply clears the checkboxes that were in the IDE and adds the ones that are in Array<string> To extend you would change the Panel and Tstrings that the UI uses update the backend. Here the back end simply updates the UI when programs are used. It uses a Ddd pattern Data driven pattern. " Update the data early and often" class function TptrApps.HookInUI(inSG: TStringGrid; inLog: TStrings; inChBxs: TcheckListBox; inBanner: TPanel): TptrApps; begin Result := nil; focusedApp := @cacheApp; var R := TptrApps.Create; R.ChBxs := inChBxs; R.ChBxs.OnClick := R.changeExesList; R.ChBxs.Items.Clear; for var I := Low(goodApps) to High(goodApps) do begin R.ChBxs.Items.add(goodApps[I]); R.ChBxs.Checked[I] := True; ... const selfClass = 'FrmPat'; GoodApps: Tarray<string> = [cEveryThing,'Shell_TrayWnd','Notepad', 'TAppBuilder', 'Window', 'Chrome_WidgetWin_1', 'Notepad++', selfClass, 'TfmPeInformation' ];

So for such cases these is "case" in Pascal/Delphi Case the control is CheckBox then the value is Boolean type Case of TMemo then the value is Base64 Encoded text. Case of something need more than one property then (like DataSet) MyDataSet.XX or MyDataSet_XX is TXX type .....

Hm, I remember writing something like this (many) years ago, but never actually used it. The code should be on sourceforge, I'll have to look it up. Found it: https://sourceforge.net/projects/dzconfig/ As I said: That was years ago, but maybe you will find it useful.

Hi, Do it stupid simple, do you need it to be used or modified by users manually ?!! most likely no.. So, even for both cases (Yes/No) : Name these CheckBoxes with useful and clear names, then use the their names as Ini file Value while use for the Ini file Sections the Form/Frame name ... Don't forget to handle missed value with notification or errors or skip silently.... , For saving (or loading): enumerate all the controls in the form/frame and utilize the tag property to indicate the need to be saved/stored in Ini file or not. Just an idea !

You cannot add a property without a new class. If you don't want to extend the component you can store the additional information in a dictionary or in other data structure.

This should give you an idea type TForm3 = class(TForm) EdgeBrowser: TEdgeBrowser; Button1: TButton; procedure Button1Click(Sender: TObject); procedure EdgeBrowserWebMessageReceived(Sender: TCustomEdgeBrowser; Args: TWebMessageReceivedEventArgs); procedure EdgeBrowserNavigationCompleted(Sender: TCustomEdgeBrowser; IsSuccess: Boolean; WebErrorStatus: TOleEnum); private public end; var Form3: TForm3; implementation {$R *.dfm} procedure TForm3.Button1Click(Sender: TObject); begin EdgeBrowser.Navigate('https://www.google.com'); end; procedure TForm3.EdgeBrowserNavigationCompleted(Sender: TCustomEdgeBrowser; IsSuccess: Boolean; WebErrorStatus: TOleEnum); begin EdgeBrowser.ExecuteScript('window.addEventListener("click",function(e) {' + ' e = e || window.event;' + ' var target = e.target || e.srcElement;' + ' var text = target.textContent || target.innerText;' + ' window.chrome.webview.postMessage(target.outerHTML);' + ' }, false);'); end; procedure TForm3.EdgeBrowserWebMessageReceived(Sender: TCustomEdgeBrowser; Args: TWebMessageReceivedEventArgs); var LMsg : PWideChar; begin Args.ArgsInterface.TryGetWebMessageAsString(LMsg); ShowMessage(LMsg); end;

>>without creating a new component? >>and I think about a new VCL. Sounds a bit strange.. Don't modify the original VCL component (if you have the Delphi sourcecode..) Modifying_Existing_Controls

I'm struggling to imagine what headaches would be solved by this feature. I don't know how you can't get a list of generated files by simply checking out the project and then compiling it. All the files created after you compiled are the ones made by that compile.

There is no such list generated by the IDE/compiler. And the only documentation that I know of which talks about generated files is: File Types Index File Extensions of Files Generated by RAD Studio

Well, sorry if it's too late, i saw this post today. "Yes you can" , playing with the ItemHeight, alas this height is an integer and can't be lesser than 1 (0 => default size) so you will obtain a gray gap more or less high depending on items count in the group I explain how in this blogpost (sorry french only)