Leaderboard

I think calling AI for AI still is a misnomer. It is various facets of specialized ML. An actual self-organizing AI is very, very far in the future. A self-aware AI, even further in the future. As the problem domain becomes more complex, it will be harder and harder to tell the rubbish from the pearls. That is a real problem. I like tools that I can rely on. That I can trust. Actual knowledge that reflects reality, not constructs generated by algorithms with a certain risk of failure. Art generators like MidJourney, are fun and useful, and I even subscribe for $10/month to be able to play around with it - but AI art also pose a risk as it undermines actual artists. MidJourney prompt: "A computer programmer asks an AI to assist him in writing complex code, photography, ultrarealistic --v 4" It looks great until you notice the glaring mistakes.

Note that such usage is demonstrated in Embarcadero's documentation, though it is not explicitly called out as being a requirement: https://docwiki.embarcadero.com/RADStudio/en/Inline_Variable_Declaration procedure Test99; begin // some code if (something) then begin var Intf: IInterface = GetInterface; // Intf.AddRef // <-- HERE! var MRec: TManagedRecord = GetMRecValue; // MRec.Create + MRec.Assign UseIntf(Intf); UseMRec(MRec); end; // Intf.Release and MRec.Destroy are implicitly called at end of scope // more code end; // no additional cleanup

The inline variable in question will be of type TCar as its type will be inferred from type used in constructor: TCar. In such code where object instances are reference counted, you will need to explicitly specify correct type: ICar because reference counted instances need to be stored in interface references for proper initialization of reference counting mechanism. var car: ICar := TCar.Create;

Hi Currently in the AddressBook sample app it display Arabic letters scrambled like ي ا ش ق So no possible way to display it correctly ?

Nothing shown references a component in another unit. I only see a local ProgressBar1 defined in the Var section of your procedure that isn't created / initialized so will throw access violations when an attempt it made to reference/access it. Usually you would put the other form unit in the Uses clause of the implementation section of the form you want to reference it from. Then use the form variable to access it like Form1.ProgressBar1.Visible := true;. implementation {$R *.dfm} uses Unit1;

I have made some changes to the BDSLauncher that may be useful to the general public. I had the problem that the rule "*\My Projects\Project Name\*.dproj" was not recognized as true by the used function "System.Masks.MatchesMask". Therefore I made the following changes in the unit "uBDSLauncherMainForm": Unit uBDSLauncherMainForm; Interface Uses ... Type ... // // Replacement for MatchesMask from Unit System.Masks // function PathMatchSpecEx(pszFile, pszSpec : LPCWSTR; dwFlags : DWORD) : HRESULT; stdcall; .... Implementation Uses ... // // Replacement for MatchesMask from Unit System.Masks // function PathMatchSpecEx; external 'shlwapi.dll' name 'PathMatchSpecExW'; function BDSMatchesMask(const pszFile, pszSpec : String) : Boolean; const PMSF_NORMAL = $000000; PMSF_MULTIPLE = $00000001; begin Result := PathMatchSpecEx(PChar(pszFile), PChar(pszSpec), PMSF_NORMAL or PMSF_MULTIPLE) = S_OK; end; .... Function TBDSLauncherMainForm.OpenWithRules(Const inFileName, inDetectedVersion: String): Boolean; Var ... Begin ... For mask In rule.FileMasks.Split([sLineBreak]) Do //anymatch := anymatch Or MatchesMask(inFileName, mask); anymatch := anymatch Or BDSMatchesMask(inFileName, mask); ... Another change I have made in the unit "AE.IDE.DelphiVersions". Reason was here that there is with me in the Registry the path "HKCU\SOFTWARE\Embarcadero\BDS\_22.0". The underscore then led to the error "'_22' is not a valid integer value for type 'Integer'". Unit AE.IDE.DelphiVersions; Interface Uses ... Type ... Implementation Uses ... .... Procedure TAEDelphiVersions.DiscoverVersions(Const inRegistry: TRegistry; Const inDelphiVersionClass: TAEDelphiVersionClass); Var ... Begin ... //Self.AddVersion(inDelphiVersionClass.Create(Self, inRegistry.ReadString('App'), Integer.Parse(s.Substring(0, s.IndexOf('.'))))); var arr : TArray<string> := s.Split(['.']); var ver : Integer := StrToIntDef(arr[0], 0); if ver > 0 then begin Self.AddVersion(inDelphiVersionClass.Create(Self, inRegistry.ReadString('App'), ver)); end; Finally ...

You can add TListBoxItem controls to TComboBox, for example: procedure TForm1.AddComboBoxItem(const AText: String; const AImageIndex: Integer); var LItem: TListBoxItem; begin TComboBox1.BeginUpdate; LItem := TListBoxItem.Create(TComboBox1); LItem.Parent := TComboBox1; LItem.Images := TImageList1; LItem.ImageIndex := AImageIndex; LItem.Text := AText; TComboBox1.EndUpdate; end; TComboBox will use these exactly the same if you were to put strings in TComboBox.Items. LItem.Images is a property to which you assign a TImageList control, in which you can add images. By assigning LItem.ImageIndex, you will then use the image you defined at that index inside the TImageList. Another option is to define an FMX style in TStyleBook and directly put the image there, but that might be redundant for this specific scenario. Unsure of which approach is better in general, but I prefer the latter one as it is more convenient to use in multiple places. Really depends on what you need though.

install fmxrtl FmxRtl or use this unit from see this forum arabic fmx

I seriously suck at UI design so tips like this are more than welcome 🙂 Changed the version selector to show up as a list instead and it indeed feels nicer to handle:

I'm not sure a combobox is the right decision here as it will slow down the process. I'd stick with a listbox or grid or similar with RETURN key and a button for the rookies.

https://github.com/ideasawakened/DelphiKB/wiki/D28.ALEXANDRIA.11.0.0.0 This might help Can no longer build executables for Windows XP without customization: Project Options->Building->Delphi Compiler->Linking->Set OS Version fields in PE Headers (and Set SubSystem Version fields in PE Headers" to 5.1 (it now defaults to 6.0) If you use System.Threading, then need to change GetTickCount64 references to a new routine matching something like the code below and then use a modified system.thread.dcu in your projects (or update \lib\win32\debug and \lib\win32\release with new versions of System.Threading.dcu) More info from Michal Mutl on Delphi PRAXIS forum message function _GetTickCount64: UInt64; begin if TOSVersion.Major<6 then Result := TThread.GetTickCount else Result := TThread.GetTickCount64; end; XP Compatibility notes As reported by Marco Cantu on Delphi PRAXIS, better HighDPI support was the reason for the PE header change. And the GetTickCount was un intentional. Changing the PE format to target newer versions was a design decision. It's the same Visual Studio does. And it does make a difference in the results when invoking some HighDPI related Windows APIs. They fail to return the right value if the app is for XP, so if you change the PE setting (doable) you'll have some trouble on the latest systems. The introduction of an XP breaking issue with GetTickCount64 was not intentional and discussed. We don't test on XP by design, no one in the beta did, most likley. While we don't officially support XP, such a simple change is doable -- as long there is zero impact on newer systems and it costs a limited time. I doubt we'll release a patch for it, though...