Leaderboard

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 can always use VMs for betas. But I hear you. I usually don't have spare time to actively do any testing, but I do like to join in to see what's coming ahead of time.

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...

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?

Of course.

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.

Hello Delphi Enthusiasts! An absolutely unique event is approaching, one that no Delphi enthusiast can afford to miss! On June 5-6, 2025, the Delphi Summit will take place in vibrant Amsterdam, celebrating an incredible 30 years of Delphi's existence! This isn't just another conference – it's a global gathering of the Delphi community, a unique opportunity to: Discover the latest trends and technologies: Explore the future of Delphi, see innovative solutions, and learn how to leverage the full potential of this environment in your projects. Learn from the best: Listen to presentations by world-class experts, Delphi creators, and industry leaders who will share their knowledge and experience. Participate in hands-on sessions: Dive into code during workshops and technical sessions, gaining practical skills that you can immediately implement in your work. Make invaluable connections: Meet other developers, exchange ideas, build business relationships, and become part of the global Delphi family. Experience a unique atmosphere: Celebrate 30 years of Delphi in an international group, drawing inspiration and energy from the passion of other participants! (More details about the agenda and speakers can be found on the official website: https://delphisummit.com/) Join our group trip and take advantage of a DISCOUNT! To make this trip even more exciting and hassle-free, we are organizing a joint group trip to the Delphi Summit (in cooperation with BSC Polska)! Why travel with us? Super Discount: We have a special discount code that lowers the price of the Summit ticket 🙂 only for our group. Fantastic company: Travel and stay with a group of Delphi enthusiasts – guaranteed inspiring conversations, exchange of experiences, and lots of fun! Convenient transportation: We are traveling in a comfortable, air-conditioned van directly from Zielona Góra (Poland). Possibility to join along the way (Świebodzin, Berlin, Hanover, ...) Organized accommodation: We provide comfortable accommodation in a picturesque area, not far from the conference venue. Full integration: The journey itself is a great opportunity to meet interesting people with the same interests and network in a relaxed atmosphere. Cost optimization: We share the costs of transportation and accommodation, making the trip more affordable. Preliminary plan and estimated costs: Departure: Wednesday, June 4, 2025, at 8:00 AM from Zielona Góra. Possibility to join along the way (Świebodzin, Berlin, Hanover, ...). Transportation: Comfortable van (Ford Transit Custom 2021, 8 seats, air conditioning, plenty of space). Accommodation: 3 nights (04.06 - 07.06.2025) in Marinapark Volendam (charming location approx. 9 km from the Summit). Double rooms. Link to the property: https://www.booking.com/Share-ondy5X Return: Saturday, June 7, 2025, after breakfast. We plan a quick tour of Amsterdam before heading back! Additionally: Stops for meals during the trip Parking: Possibility to leave (free of charge) your car for the duration of the trip in a monitored, closed parking lot in Zielona Góra. Interested? Don't hesitate! We have a limited number of seats in the van and accommodation reservations. If you want to experience this amazing adventure, meet fantastic people, take advantage of the discount, and be part of the historic, jubilee Delphi Summit, contact me as soon as possible to reserve your spot and get the discount code! Best Regards Marcin You can contact also by www.linkedin.com/in/marcinmoszkowicz

Isolate your business logic from the UI. Use an intermediate class to pass the data around.

You can contact Devid Espenschied

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

But you and Remy are still there with a greater, precious and fundamental tireless contribution. Thank you for all, for what you have done and for what you will do (to others of TeamB too, that I don't know).

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.

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

30 fps is not 1 frame per 0.0333333 ms. It's 1 frame per 33.33333 ms, or 0.033333 seconds.

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

The eel is a critically endangered specie.

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.

Yellow, again... Did Quick tests with PPL, seems that tested code it self did not work wery well when runniing in parallel. Do'h Heve to to think of this later... Code should be about thread safe, but did not cope, or at least I did not saw anything that was obviously not thhread safee and protected few spots with Critical section. -Tee-

There are also some code templates in Delphi to simplify writing these comments: summary, params, returns, remarks

Okay, I just thought Lazarus version could have got some updates and improvements. TurboPower was an amazing company, they had so much open source components with great docs, and many of them are still actual, >10 years after abandonment!