Leaderboard

Are you kidding me? You, Sir, are a TeamB legend and as such I would have assumed you're an MVP now, with - AFAIK - much earlier access to the betas. Heck, I learned a ton from all of your posts going all the way back to when we were still hanging out on nntp://borland.* with the likes of Neil J. Rubenking and the other TeamB members (or maybe even earlier back, then CompuServe was a thing, but I'm not sure whether my memory serves me right on this one). I sincerely hope you're able to enjoy your time as a pensioner now. You've been an inspiration to me in more than just one way. So thank you a lot. FWIW I didn't receive a beta invite as a regular subscription user, but I'm actually not surprised by that - I mean how is Calvin Tang going to handle beta invitation requests if everyone with an active subscription is invited?

Part of the NDA you agreed to when you signed up was to not publicly mention that you are participating in the beta, nor any details about it, so you have already broken your NDA.

There are many components/libraries available for running processes and capturing their output. But, I got frustrated with their design and functionality, mostly for the following reasons: Fixation with and premature conversion to strings. Processes produce and consume bytes. Blocking reading of process output, resulting to inefficiencies (tight loops with Sleep, or separate threads for reading the output or providing input to the process) Incomplete features and/or over-bloated So, I have made my own pascal-process single unit library. Main features: Asynchronous reading of process output Separate stdout and stderr reading which can optionally be merged Ability to consume output as it is produced or else let it accumulate and read the final result Ability to provide input to the running process before or while the process is running. Ability to terminate the running process. Synchronous and asynchronous execution of processes. Interfaced-based facilitating memory management. MIT licence Usage: You do not need to install the library. Just download or clone the repo and add the source subdirectory to the Library path. Then add PascalProcess to your uses clause. If you just want to get the output of a process you can use the class functions of TPProcess. TPProcess = class(TInterfacedObject, IPProcess) class function Execute(const ACommandLine: string; const ACurrentDir: string = ''): TBytes; overload; class procedure Execute(const ACommandLine: string; const ACurrentDir: string; out Output, ErrOutput: TBytes) overload; end; This is an example: var Output: TBytes; begin Output := TPProcess.Execute('cmd /c echo Hi'); Writeln(TEncoding.ANSI.GetString(Output)); end; For more demanding cases you can use the IPProcess interface. Example: type TUtils = class class procedure OnRead(Sender: TObject; const Bytes: TBytes); end; class procedure TUtils.OnRead(Sender: TObject; const Bytes: TBytes); begin Writeln(TEncoding.ANSI.GetString(Bytes)); end; procedure Test2; // Processes ouput as it gets produced // The main thread terminates the process var Process: IPProcess; begin Process := TPProcess.Create('cmd /c dir c:\ /s'); Process.OnRead := TUtils.OnRead; WriteLn('Press Enter to start the process. Press Enter again to terminate'); ReadLn; Process.Execute; ReadLn; Process.Terminate; end; See here the definition of IPProcess. Limitations: Currently the library is Windows only. The intention is to support other platforms (help wanted).

You’re right, @Dave Nottage, the problem was with SDK version 6.28. I managed to fix it using Delphi 12.2 with Firebase SDK 11.2.0, iOS SDK 18.2, and Xcode 16.2. For FCM integration, I used Kastri and made some Delphi adjustments based on the example here: https://github.com/DelphiWorlds/Kastri/tree/master/Demos/FCMRebooted

I still don't understand the problem of detecting whether dcc32 of a CE installation can compile anything. What does it do if you give it an empty .dpr file to compile from a cmd window? Does it just silently fail? No error message? But even if that is the case, you could at least try to compile said empty .dpr file and check whether an executable is created. Not quite an elegant solution but it should work.

That was a looong time ago and I've not done any serious programming in years. Actually I newer participated in a beta due to lack of time and spare hardware (installing a beta on my production PC was just too risky). And your memory is correct, I did start on the old Compuserve BPASCAL forum before Delphi was even an idea in Anders' brain 8-). Those were the days, acoustic couplers to connect via phone line, later 9600 baud modems, Turbo Pascal, later for Windows with OWL... lots of fun. Just a bit depressing that quite a few of the old crew have already passed away...

Of course.

In his defense, now I'm hyped for the release

function EditStreamInCallback(dwCookie: Longint; pbBuff: PByte; cb: Longint; var pcb: Longint): dword; stdcall; const E_FAIL = dword($80004005); var theStream: TStream; dataAvail: Longint; begin theStream := TStream(dwCookie); with theStream do begin dataAvail := Size - Position; Result := 0; { assume everything is ok } if dataAvail <= cb then begin pcb := read(pbBuff^, dataAvail); if pcb <> dataAvail then { couldnt read req. amount of bytes } Result := E_FAIL; end else begin pcb := read(pbBuff^, cb); if pcb <> cb then Result := E_FAIL; end; end; end; function EditStreamOutCallback(dwCookie: Longint; pbBuff: PByte; cb: Longint; var pcb: Longint): dword; stdcall; var theStream: TStream; begin theStream := TStream(dwCookie); with theStream do begin if cb > 0 then pcb := write(pbBuff^, cb); Result := 0; end; end; procedure GetRTFSelection(aRichEdit: TJvRichEdit; intoStream: TStream); var editstream: TEditStream; begin with editstream do begin dwCookie := Longint(intoStream); dwError := 0; pfnCallback := @EditStreamOutCallback; end; aRichEdit.Perform(EM_STREAMOUT, SF_RTF or SFF_SELECTION, LParam(@editstream)); end; procedure PutRTFSelection(aRichEdit: TJvRichEdit; sourceStream: TStream); var editstream: TEditStream; begin with editstream do begin dwCookie := Longint(sourceStream); dwError := 0; pfnCallback := @EditStreamInCallback; end; aRichEdit.Perform(EM_STREAMIN, SF_RTF or SFF_SELECTION, LParam(@editstream)); end; function GetRTF(RE: TJvRichEdit; Selection: Boolean = false): string; var strStream: TStringStream; begin strStream := TStringStream.Create(''); try if Selection then begin GetRTFSelection(RE, strStream); Result := strStream.DataString; end else begin RE.PlainText := false; RE.Lines.SaveToStream(strStream); Result := strStream.DataString; end; finally strStream.Free end; end; procedure SetRTF(var RE: TJvRichEdit; S: string); var strStream: TStringStream; begin strStream := TStringStream.Create(''); try strStream.WriteString(S); strStream.Position := 0; RE.PlainText := false; RE.Lines.LoadFromStream(strStream); finally strStream.Free end; end; GetRTF/SetRTF for the complete content of TRichEdit (I use TJvRichEdit but you can change that to TRichEdit). GetRTFSelection/SetRTFSelection for only the selected content. With ExecSQL you don't work with dataaware components. The you can just use TField.AsString for the parameterized select/update/insert. TRichEdit is not dataaware. When you want to work with data-aware components like TDBRichEdit, you don't need to use ExecSQL. You can just do SELECT and fill in the UpdateSQL Object with INSERT/UPDATE/DELETE statements. Then in code you only have to do TQuery.Open (for the SELECT). Your TDBRichEdit will be automatically filled. When you do TQuery.Edit you enter edit mode (or you can do TQuery.Insert to insert a new record). After you are ready, you do TQuery.Post and the records (including the content of TDBRichEdit) is saved. (don't forget to Commit the transaction)

How upgrading from Delphi 7 to Delphi 12 eliminated 15 monthly support tickets and unlocked Linux deployment In May 2024, we were contacted by a European leader in natural gas measurement systems. Their software was partly built in Delphi 7 and partly in C#. It had become difficult to maintain. The company wanted to migrate to Delphi 12, modernize the UI, and enable Linux deployment, without breaking existing functionality. Our team faced and handled the following challenges: The project relied on Delphi 7. That version lacked full Unicode support. The framework used ANSI strings by default, and this created critical limitations for modern global applications. The legacy app only ran on 32-bit Windows, using outdated Win32 APIs and hardcoded paths (C:\Data\). This prevented deployment on Linux cloud servers (AWS/Ubuntu). The app was built on obsolete BDE components and unsupported libraries. Here's what we did: ✅ Migrated from Delphi 7 to Delphi 12 ✅ Replaced BDE and Indy 9 with FireDAC and Indy 10 ✅ Refactored code for cross-platform compatibility ✅ Delivered a modernized UI with preserved workflow familiarity We achieved: - 15 support tickets per month were reduced to zero - Windows-only application is now cross-platform - Overall, the application is more prepared for future challenges A few months later, the client returned for an estimate to migrate other Delphi projects to a web-based platform. If you want to see the full story, with the challenges and solutions broken down, follow the link https://www.softacom.com/cases/modernizing-industrial-software-with-delphi-12/

Please make sure you are using MQTT from SVN or the overnight zip, I did a major rewrite a couple of months ago that is not yet released. Coming back to your original problem, the best solution will be a new wrapper component around the ICS MQTT client, that handles reconnection if the connection drops, including using a list of IP addresses for multiple servers. This will avoid applications needing to handle all the reconnection stuff, which is tedious. I'll put it on my list, but it may not make the next release, which is already overdue. The TIcsIpStrmLog client component already does reconnections, just need to take those properties and methods. Angus

Instead of PING, I can use TCP/UDP client-server code to check one another, which might be simpler. The network consists of 1G/10G wired backend, as well as Wifi5 (2.4 + 5G) which is fairly fast and stable. Ideally, it would be much simpler if I could tell the clients to communicate with 2 (or more) brokers/servers, but I have no control over that feature on the clients which are sometimes tiny IOT devicess. As a result, I have resorted to this idea. BTW, I am using ICS (your brain child) and would like to thank you for it. I have heavily modified the MQTT code. When finished, I might submit it for the next major version. Thank you again.

ofc

Sure

After a conversation I have had with someone with the same problem, it seems it is due to a bug in earlier versions of the Firebase iOS SDK. The implementation in Delphi uses v6.28, and the latest version is v11.11, so it is quite a way "behind". Due to a linker issue in Delphi 12.1 and earlier, the latest version of the Firebase iOS SDK that can be used with it is v10.8. Delphi 12.2 can use at least v11.2, however I believe the linker starts failing again sometime before v11.11 (I'd have to check this). Having said all that, even if you download one of the later versions of the Firebase iOS SDK, there's a number of changes that would need to be made to Delphi source code in order to make it work. Alternatively, the FCM implementation in Kastri could be used, which is known to work with Firebase iOS SDK v11.2.