Rollo62

There have been some discussion here and in the German DP, but best of all, there is an official announcment. https://blogs.embarcadero.com/fmx-linux-for-delphi-12-3-is-now-available/ https://www.delphipraxis.net/216783-fmx-linux-kennt-jemand-den-aktuellen-stand.html#post1546803 https://en.delphipraxis.net/topic/12288-fmxlinux-missing/?tab=comments#comment-102324 It should be available in summer, as arnof reported from the 12.3 introduction.

Yes, thats nice and useful, you can also extend this a bit, to avoid dangling pointers. See these rough ideas ... destructor TAnonProc.Destroy; begin if (Owner is TButton) and (TMethod(TButton(Owner).OnClick).Data = Self) then begin TButton( Owner ).OnClick := nil; // Ensure to remove dangling Pointer end; inherited; end; or you could even separate the Owner from the Observer type TAnonProc = class(TComponent) private FProc: TProc<TObject>; procedure Notification(AComponent: TComponent; Operation: TOperation); override; procedure OnSender(Sender: TObject); public constructor Create(AOwner, AObserved: TComponent; AProc: TProc<TObject>); end; constructor TAnonProc.Create(AOwner, AObserved: TComponent; AProc: TProc<TObject>); begin inherited Create(AOwner); // Owner = Form FProc := AProc; AObserved.FreeNotification(Self); // register observer if AObserved is TButton then TButton(AObserved).OnClick := OnSender; end; procedure TAnonProc.Notification(AComponent: TComponent; Operation: TOperation); begin if (Operation = opRemove) and (AComponent is TButton) then begin TButton(AComponent).OnClick := nil; // Clear the Pointer end; inherited; end; procedure TAnonProc.OnSender(Sender: TObject); begin if Assigned(FProc) then FProc(Sender); end; //.......................... TAnonProc.Create(Self, Button1, procedure(Sender: TObject) begin Caption := 'Click!'; end);

Perhaps Uses KillLSP is still the way to go? https://www.delphipraxis.net/1512626-post2.html

I just noticed this, maybe its interesting https://www.delphipraxis.net/217543-embarcadero-jobportal.html#post1550400

Just try with GELATO to find out if its defined somewhere

Never say never. There are also a lot of local, free AI models around nowadays, keeping stuff private ....

Interesting approach. 👍 Don't you get then varying font sizes for each control, by differing MaxWidths? How do you control that there is a unique look-and-feel, do you use always the same width spaces for all components? Maybe you have some screenshots available, to get a better idea.

As explained above, define work top-down as compiletime, pretty much as the "defines" in C/C++. This is very useful since you can switch between certain code behaviour parts, include or not to compile, depending on a compiletime defined condition. //Can be used with DEFINED() in a more speaking, checkbox-like version {$DEFINE ___USE_THE_BO_VARIANT } {$DEFINE _X_USE_THE_MO_VARIANT } {$DEFINE ___USE_THE_ZO_VARIANT } FUNCTION DOTHERPORT; BEGIN {$ifDEF _X_USE_THE_BO_VARIANT} result :=DoCharges(true,-1,false,False,false,lg('CLOSE CHARGES'),'1',dm2.sysdate.fieldbyname('date').asdatetime) {$else} result := DoCharges(sender=Nil,-1,False,False,FALSE,lg(TDsFancyButton(Sender).Caption),'',0,dm2.sysdate.fieldbyname('date').asdatetime); {$endif} END; //Or maybe in mode complex scenarios, as switch/case-like option, like this FUNCTION DOTHERPORT2; BEGIN {$if DEFINED( _X_USE_THE_BO_VARIANT ) } result :=DoCharges(true,-1,false,False,false,lg('CLOSE CHARGES'),'1',dm2.sysdate.fieldbyname('date').asdatetime) {$elseif DEFINED( _X_USE_THE_MO_VARIANT ) } result := DoCharges(sender=Nil,-1,False,False,FALSE,lg(TDsFancyButton(Sender).Caption),'',0,dm2.sysdate.fieldbyname('date').asdatetime); {$elseif DEFINED( _X_USE_THE_ZO_VARIANT ) } result :=DoCharges(true,-1,false,False,false,lg('ZOOOO'),'1',dm2.sysdate.fieldbyname('date').asdatetime) {$else } result :=DoCharges(true,-1,false,False,false,lg('NOTHING ELSE MATTERS'),'1',dm2.sysdate.fieldbyname('date').asdatetime) {$endif} END;

I was curious how far you can get with the newer System.Net.HttpClient, System.Net.HttpClientComponent, System.Net.URLClient. It seems quite limited, perhaps the good old Indy might have more tricks up its sleeve. TNetHTTPClient TRESTClient and friends are not so verbose in regards of internal stream data. Perhaps a combination of both can get more insights about the underlying data streams? T526_RestDebug_002.zip

Have seen it, but never checked it out before. Its on my ToDo list now

Not that it solves your RestDebugger but, but there is also a nice tool Bruno, which might help to dig deeper. https://www.usebruno.com/

Nice demo. 👍 Perhaps you forgot to mention that its available on GetIt https://getitnow.embarcadero.com/delphi-yolo-onnx-runtime-wrapper/ and on GitHub https://github.com/SoftacomCompany/Delphi-YOLO-ONNX-RuntimeWrapper and Medium https://medium.com/@softacom.com/object-detection-in-delphi-with-onnx-runtime-2b1e28b0e1b3

I could think of maybe parsing and replacing somehow, or edit manually at least in an easier editing system than InDesign. Im not an InDesign user, but my impression is that using InDesign as-is is a pain-in-the-.... in the first place. Maybe I'm wrong, but its not something I would love to use on a daily base.

But thats not always what it is. It may be a signal word, it may be a warning sign, which is crucial to the user in user manuals. https://www.kothes.com/en/blog/creating-safety-and-warning-notices-with-the-safe-method Ok, those can be maybe set in their local language, but sometimes these icons were not repeated in each language. Thats hard to keep on track, if you have 8000 of those entries in hundrets of files. Our artwork department will be working on that alone for half a year, updating the current/older documents. I think the best way is to keep as-is and to provide a second channel of those documents, e.g. by HTML, where it will be possible to somehow auto-translate and fill those elements.

Yes, that is some messy stuff, the icons. What I do, to avoid getting even more messy: - I made a 1:1 copy of the original Embarcadero artwork from /bin/artwork/... into a local folder to my project - This ensure that I use the same filenames as Embarcadero did, if I forget one or some changes in new versions, there is always the fallback to the Emba Icon - Then I redirect the folders ( not the filenames ) of the Icons dialog, to link to my local folder ( this can be done by search/replace in *.dproj too, if you do carefully ). - Then you might change the icons accordingly to your design, keep all dimensions, file-names, file-formats, etc., just relace the image to your design - After that, your app takes the new images (perhaps you have to de-install/re-install) the app, to make it happen. That way you don't have to fumble around with deployment at all, if its only about the original Embarcadero App Icons. You just trick the IDE to replace the original artwork by your, without even add more and more messy filenames.