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

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?

Small example to access Github's contributions of a given user and display them using TeeChart. https://github.com/Steema/TeeChart-VCL-GitHub-Contributions This demo is made with VCL but almost identical code works in Firemonkey.

RTF Roulette: The Hidden Dangers of Storing Rich Text in VARCHAR Fields

InnoSetup

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

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

The IDE as well as MSBuild are using the dproj file of your project, while the compiler only sees the dpr. At the end of the dproj file there is an import command for CodeGear.Delphi.Targets, which itself imports CodeGear.Common.Targets. The latter sets the UnitAliases given to the compiler.

First of all, thanks. I'll be back as soon as I understand better what the analysis is showing, and then I might be able to do the "little code changes" you mention :). Just keep in mind, that the sinkwriter isn't giving you any control over dts, pts., or how video and audio are interleaved. Renate

Your issues are now fixed in SVN and will be zipped overnight. The GET and DELETE methods now support REST PContBodyJson, PContBodyUrlEn and PContBodyXML content types, beware web servers may not support this. The ICS web server also now supports body content with GET and DELETE requests, provided there are UrlJHandlers for these methods or the application handles the content stream. The TRestParams component has a new RParamFmt property that for Json only defines whether nested objects or an array should be formatted, default is RPFmtNestObj (Nested Objects, same as previously), or RPFmtArrayVal (Array of Values) if first element is any array, or RPFmtArrayObj (Array of Objects) where each element is treated as object in the array. Note RPFmtArrayObj allows duplicate names in Add methods, since output into different objects. For instance: RPFmtNestObj: {"field1":"data1","field2":"data2","field3":[data1, data2, data3]} RPFmtArrayVal: [data1, data2, data3] RPFmtArrayObj: [{"field":"data1"},{"field":"data2"},{"field":[data1, data2, data3]}] Angus

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)

Great, and you are on the right way, make use of real video for testing. You are right and i am right here, but you are ignoring one essential fact, that your daily player as mine are good, they are so good that they fix this stuff at runtime to their best effort, i provided earlier a link to ffmpeg and how it does its magic to fix these to its best effort. As for proof, i will provide one, but let me make it clear here, your player not showing the problem is solemnly based on their advanced algorithm for corrections, BUT and it is huge but, if you are you use similar code with basic algorithms and APIs just like yours the problem will manifest badly. now to the proof; 1) i went to this page https://archive.org/details/4-k-hdr-60-fps-dolby-vision-demo-2160p-60fps-vp-9-128kbit-aac and didn't download the video with highest quality, i used the "H.264" on the right side under "Download Options" it is 16.6mb , that is enough. 2) I have ffprobe (the link to download is in earlier post) and extracted the frames and their timing for debugging the video its self and see how original with quality encoder have interleaved the frames and their duration. 3) i transcoded the video without changing the default setting and repeated the process with output video and restoring the FPS to 60 instead of 30, the downloaded/original video is 59.94 fps 4) used the ffprobe on these 3 video files 5) made small parser for the ffprobe output, here is its parsing loop, it is easier to see and follow than using Notepad++ procedure TForm10.ProcessFile(const FileN: string); var StrList: TStringList; Line: string; i, p: Integer; begin StrList := TStringList.Create; try StrList.LineBreak := '[/FRAME]'#13#10; StrList.LoadFromFile(FileN); if StrList.Count = 0 then Exit; Memo1.Lines.BeginUpdate; try for i := 0 to StrList.Count - 1 do begin Line := StrList[i]; p := PosEx('pkt_pos', Line); if p > 0 then Line := LeftStr(Line, p - 1); if Length(Line) > Length('[FRAME] media_type=') then Line := RightStr(Line, Length(Line) - Length('[FRAME] media_type=') - 1); Line := ReplaceStr(Line, #13#10, ' '); Memo1.Lines.Add(Line); end; finally Memo1.Lines.EndUpdate; end; finally StrList.Free; end; end; Now i went to compare and check for the timestamps 1) the original (downloaded) some of the begging and middle and end of that original video, how commercial (or may be even not commercial) and high end encoder interleaved the frames and their durations What we see, smooth interleave with fixed frames length, but it compensate with extra video when it is short, and extra audio frame when it is short, notice the audio and video end at the same, the green box show at the end the difference is small, yet after that it will push both streams to the end but the difference through out all video didn't go above this 10-13 ms, 2) Lets see the transcoded version at 30 fps (default setting) and from the middle We see a desyncing in the middle the last video frame in the video sequence is 99.133333 while the following audio sections of frames, the last one corresponding to that video frame is 99.118271 the difference is 15ms at the end the difference is 33ms, so we correct and synced video now is desynced and audio is drifting by something 10-11ms per minutes, not much , i agree and in fact it is almost within the allowed standard for 10ms drift, but again this small drifting is for this combination for this video. 3) lets see the one i transcoded further from the generated 60 fps into 60fps and the result , taking only the first frames and the last Now it is more synced at the end than the first transcoded one, the drift is only 6ms ! How this happen ? Just look at how the first frames and their time stamps, the audio start at "pts=2229 pts_time=0.046437" meaning the audio is drifted forward 46ms since the the start and lost 40ms till the end. Dear Renate, in no way i am saying it is bad or wrong, pointing to anything, and pretty please don't take my posts here in the wrong way, you did awesome job and pretty neat usage MF, i merely want to show you a better way, make it commercial worth and avoid these hidden bugs, my points here are for anyone who love to know, or care. Now, is it huge adjustment, no you are overthinking it, it is the small details, like when the audio frames should be pushed and interleaved?, how many of these streams and frames of sort before switching to another? do we need to make sure of the duration in dynamic way instead of simple loops? All of these questions are very simple and the change in your code should be minimum, again not asking you to change it, just to point when it fail if it failed beyond acceptable video quality, the culprit was the fixed frames count and duration, and that is it. Debugging (in this case dissecting) the video itself to its frames while keeping an eye on how best practice is being utilized is way better then watching video as player play their roles, and not being sure of using best practice or accurate timing. To summarize what could be better; 1) push less frames before switching between streams like shown above, like you LOTR video, 1or 2 then switch instead of pushing over 8, 2) make sure the the audio frames start form 0 time 3) if you don't like adjusting video duration, it is ok, we have many ways to skin a cat, don't know what the cat did but follow best practice and the cat will be skinned, adjust audio frames, even this is not really necessary, and both can be skipped, and not touched 4) third way to fix 3, we use the most naive way, and make sure there is no drifting skipping (3) , just make audio frames try to hit the video duration or more, if it did hit more even with 1ms then the next chunk of audio push less frames and skip an audio frame, because we are pushing at 1 video frame then 1 audio frame, then it is easy as skip this time. and we fixed synced video. Anyway, that is all and good luck, it is your code and it is your call.

In OpenSSL, SSL 3.0 and TLS 1.x share some common code during the handshake, so you may see references to SSL3 when TLS is actually being used. Nor should you, except when you have very specific security requirements. If you don't set a CipherList explicitly, a default one is used, which should usually be suitable for most tasks. HOWEVER, do note that in July 2018 (between D10.2 and D10.3), there was a behavior change made in Indy. Maybe that is contributing to your issue? Prior to the change (ie, in the Indy bundled with XE7), if the CipherList was empty then Indy used a hard-coded cipher list that was taken from the OpenSSL SDK: 'AES:ALL:!aNULL:!eNULL:+RC4:@STRENGTH' After the change, Indy no longer uses that. It now lets OpenSSL use whatever default cipher list it was compiled with. If IsTLSv1_2Available() returns False, that means the OpenSSL DLLs you are using do not export the TLSv1_2_method(), TLSv1_2_server_method() and, TLSv1_2_client_method() functions. I can assure you that the OpenSSL 1.0.2 DLLs in Indy's GitHub repo DO export those functions. Note, if Indy doesn't detect TLS 1.1 and TLS 1.2 are available, it will silently fallback to TLS 1.0. That might also be contributing to your issue. Just to check, what does Indy's OpenSSLVersion() function report for you after the DLLs are loaded? I would also suggest using SysInternals Process Explorer to view your app's process at runtime and verify that your app is actually loading the expected OpenSSL DLLs and not some other incompatible OpenSSL DLLs that may be located elsewhere on your PC.

"Not thread-safe" in this case doesn't mean crash and burn. It just means that if one thread modifies the global FormatSettings then it will affect all other threads also using it. Hardly a problem - even if you did output floating point values in the exception message.

I updated the report https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-3711

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!