Vincent Parrett

FinalBuilder is a fully featured automated build tool, which supports Delphi 3 to 10.4, along with C++Builder 4 or later. FinalBuilder makes it simple to automate your entire build process, from compiling your delphi projects to compiling and uploading installers, creating ISO's. There are over 600 built in actions, with support for Git, Mercurial, Perforce, Subversion, TFS and many other version control systems. Unlike xml or batch file based systems, with FinalBuilder you can easily debug your build process, with breakpoints, step over, step into etc. Of course FinalBuilder also integrates with Continua CI - our continuous integration server product, and with other CI servers such as Jenkins. Thousands of Software Developers rely on FinalBuilder to automate the build, test and release process. If you are not using FinalBuilder to automate your builds, you are missing out. Download a fully functional 30 day trial version today.

Flex and grid would be nice, for sure, but you realise browsers with huge dev teams have taken years to implement and perfect these features.. not a small ask for a component vendor!

I find using unit namespaces to be extremely helpful in structuring code e.g VSoft.Core.Utils.String I can look at that unit name and know which project it's in (core) and which folder it's in (Utils). I always prefix my units (in new code, not all older code has been changed yet) with VSoft (company name) - it helps a) avoid conflicts with other libraries b) let's me differentiate between the code I wrote vs a library. I really wish all library vendors would do the same. Utils.pas in 20 different libraries is not helpful! Other than that, I will say code navigation is not one of Rad Studio's strengths.. hopefully with them moving to LSP this will improve in the next few releases.

That is in a separate repo - https://github.com/VSoftTechnologies/VSoft.WeakReferences

No, just as string fields in the record. Yes by value, they are wrapped in a class while in the queue, see TVSMessageWrapper<T>. You don't need to anything fancy, just create a message record type with the fields you want to pass around. We use have been using this library (or variations of if, I refactored it a few years ago) in FinalBuilder for a long time to send messages from the stepping engine to the UI and the logger and I've never seen any issues with message contents etc. There's a sample application (vcl and fmx versions) which shows it passing strings around just fine.

Not sure how much scope you have to change things, but this is what I use for internal messaging from threads https://github.com/VSoftTechnologies/VSoft.Messaging - it uses custom messages rather than trying to pass data using wparam.

Is it possible to determine if a record type has an equality operator overload? I'm scratching my head on this one, not sure if there's enough info in the rtti or I'm just not looking at the right thing. Use case, I need to compare if two records are equal (this is for DUnitX & Delphi-Mocks). Of course due to managed types etc it's not as simple as it seems.. however if the record has an Equals or NotEquals operator overload then I could use that.

@Stefan Glienke thanks.. I didn't even think to look at spring, and yet I use it every day!

Yes, I posted about that a few days ago You will need to adjust your DUNITX variable to add \Source as the source code was moved into a subfolder.

The System.Classes issue is a but, I have just pushed a fix for this. I don't have D2010 installed at the moment so am not able to test with it. That file was added in Aug 2018 and no one has reported this issue until now, which suggests not a lot of D2010 users using DUnitX. If you downloaded the project rather than creating it with wizard then I can't do much about the search path. As for he community edition, I have never used it so not sure whether it includes DUnitX (it's bundled with the full versions these days).

Thanks guy's, I think that should be enough to get me going.

Unit namespace prefixes for the RTL/VCL etc were only introduced in XE2 As for DUnitX, my guess there is something wrong with the DUNITX variable, either the value it has or how it's referenced. Have a look at the Messages built tab, the dcc command line args should give you a clue what the library paths/search paths are. Also my suggestion is to never use the Library path and always use the project's Search Path. The DUnitX project wizard actually adds $(DUnitX) to the project's search path for you. Lastly, DUnitX really pushed the D2010 compiler to it's limits, so if you are at all able to, I would use a newer version of delphi!

Thx, I just emailed you.

How do existing users get updates, do we just download using the original link provided?

Excellent, thanks!

at the top of DSiWin32.pas People can comment it out to enable those functions. Alternatively, switch it around, e.g. {$IFDEF UseVcl} readfont etc {$ENDIF} Then they need to define UseVcl. There's likely very few people using those functions so the impact would be low.

This is a good workaround if people are just using from the repo, but if they use Delphinus or DPM (I was planning on creating packages as I have a package that has a dependency on Omni) then that's a bit problematic. Perhaps defining NoVcl default would be better?

https://github.com/VSoftTechnologies/VSoft.Awaitable This is a simple wrapper over OmniThreadLibrary that borrows from it's Parallel.Async idea, but allows you to call functions that return values. e.g TAsync.Configure<string>( function (const cancelToken : ICancellationToken) : string var i: Integer; begin result := 'Hello ' + value; for i := 0 to 2000 do begin Sleep(1); //in loops, check the token if cancelToken.IsCancelled then exit; end; //where api's can take a handle for cancellation, use the token.handle WaitForSingleObject(cancelToken.Handle,5000); //any unhandled exceptions here will result in the on exception pro being called (if configured) //raise Exception.Create('Error Message'); end, token); ) .OnException( procedure (const e : Exception) begin Label1.Caption := e.Message; end) .OnCancellation( procedure begin //clean up Label1.Caption := 'Cancelled'; end) .Await( procedure (const value : string) begin //use result Label1.Caption := value; end); BTW, I know this isn't really quite the same as async/await (I use C# a lot) but it's about as close as we can get right now. My use case was just to be able to make long running requests in a thread and allow the caller to cancel the requests.

@Lars Fosdal I tested with regular methods and it does work fine. I updated it today to include overloads for procedures (ie where you don't need to return anything).

It's currently tied to the vcl (only in DSiWin32.pas) so if anyone is trying to use Omni in a console/service running in a windows docker container they will be blocked. For now I just commented out the offending code (reading/writing fonts to registry, which isn't needed for omni).

What would that look like? I guess I could try adding overloads that take regular methods, I'll have a stab at it. As for captures, yes I've been caught out myself a few times.

@A.M. Hoornweg have a look at the LMD Docking library, we use it in FinalBuilder and it is by far the best implementation of docking I have seen for delphi. https://lmd.de/products/vcl/lmddockpack/ You can save layouts and switch between them quite easily. In FinalBuilder, we save the layout separately for when there is 1) no projects open, 2) projects open in design mode and 3) when a project is running. Switching layouts is pretty simple and saving/restoring them them is trivial.

I've been using Delphi for 25 years, I'm working on a 20 year old code base, I'll let you know when I'm done refactoring

I've used the addictive lib for many years, but it's become a problem for me while separating execution from UI code so I can get by app running on docker - the library is so tied up in the vcl that it's not usable from a console app. Sadly, it appears the devexpress and tms ones are also dependent on the vcl (layered api's people!)

I just got done with this and it just worked! I did have to modify the hard coded path for the UsesHelper.SearchPath to match the delphi version I'm using. I tested first by specifying an output directory, and after checking with beyond compare to see how it did, I just processed the original files. It did also introduce some compilation errors, where I have prefixed function calls with the unit names (e.g SysUtils.DeleteFile ), simple to fix though. Thanks @Uwe Raabe