Vincent Parrett

You can do dynamic test creation in DUnitX by creating a TestCaseProvider https://github.com/VSoftTechnologies/DUnitX/blob/master/Examples/ProviderExample.pas https://github.com/VSoftTechnologies/DUnitX/blob/master/TestCaseProvider.md I just pushed a small change that makes it easier to create unique test case names. Note - this won't resolve the debugging one case at a time issue though, unless you modify how your TestCaseProvider somehow.

that should be $MESSAGE {$IFNDEF MSWINDOWS } {$MESSAGE Fatal 'This unit should not be included in a Windows project. Make sure you use Winapi.Messages instead'} {$ENDIF}

https://www.gnu.org/licenses/gpl-faq.en.html

+1000 for the package naming changes, I wish more vendors would use libsuffix properly - this makes upgrading compiler versions so much easier! I highly recommend the LMD DockingPack, it's 1000% better than the VCL docking or any other docking library (I tried them all!).

That's ok, it's not quite ready to go yet.. and likewise I have other stuff to work on this week, hope to find some time over the weekend or early next week to finish it off.

https://github.com/EtheaDev/SVGIconImageList By the same author. I'm working on a pull request to add a virtualimagelist and imagecollection using the same svg code.

I was interested in it, but you can only purchase the full UI pack, and I don't need all those other components.

Just a heads up for those that use the github repo rather than the embarcadero bundled version - I have re-organised the repo and moved the source into a Source folder, so you next time you pull you will need to adjust your library/search paths. Apologies for the pain this might cause but it needed to be done, the repo was a bit of a mess. Same applies to the DelphiMocks repo.

1) Under Install Packages - remove "Embarcadero Unit Testing IDE Package" 2) Remove $(BDS)\source\DUnitX from the browsing path 3) Under tools options, go to environment variables, add a user override for DUNITX - point it to the Source folder in your local clone of the repo. 4) Open the expert project for your delphi version, compile and install the expert Restart the IDE. After that you should be using the repo version.

I guess I just stubbed that out as an idea back in 2010 and never got around to implementing it (amazing it's taken 10 years for someone to notice!). Since you want to show these reports to your users, you should probably create your own implementation anyway, that way you can include just the info they need to see. Please add an issue on the github repo for this so I have at least some way of remembering it, when time permits I'll add a default implementation.

Nice, however the lack of text support might be an issue. It pains me that windows doesn't have a fully featured svg render build it.. it's not like svg's are a new thing!

I would approach this from the point of view that all data provided by the client is bad until proven otherwise - seriously, expect bad data, when it' encountered report that and exit/stop gracefully (with an error message that enables the client to fix the data).

Perhaps using something like VMMap might help - https://docs.microsoft.com/en-us/sysinternals/downloads/vmmap

Are you not excluding the history from version control? If not you really should. I look at it as a session thing, what change(s) did I make since my last commit - my colleagues do not care about that so why burden them with it by adding it into version control?

Plenty, this is my current gui of choice - https://git-fork.com/

Old style TFS is on its way out.. microsoft have pretty much deprecated it now in azure devops.. they use and encourage the use of Git instead.

If I had a $ for every time I heard this argument, well I'd have more beer money 🍺 Using version control really is a must these days, I don't know how you manage to keep track of things without it. There are plenty of zero cost options : Git - I use this for my open source projects - I use Fork as the ui but often just use the command line, Mercurial - we use this in house - Install TortoiseHg and you have a great UI Subversion - not my fav but some people like it Along with version control, a good diff tool is invaluable, we use Beyond Compare (written in delphi, built with FinalBuilder, gotta love inception!) - it's a bargain at USD$60 - I am amazed they don't charge more for it, but on the other hand I have 5 licenses so happy with the price 😉 Learning version control is not difficult (if you can drive delphi you have some tech skills for sure!), there are lots of tutorials etc on youtube etc. So my advice would be to start there. Once you have that ticking along (a few weeks of practice and discipline at the most) then you can move on to other things like build processes. Of course getting started with version control, builds etc can seem like a lot of overhead, but once you have it mastered it becomes a productivity boost and a life saver (when did I make that change and why? - be sure to add good commit messages!).

BTW, there is nothing wrong with this, but I really only do that for code that would have zero dependencies on any other parts of the application - ie utilities etc. pretty much all of my open source projects here https://github.com/VSoftTechnologies were written for a project, but could stand alone. For adding features to an application, it's best done in the application.

Do you have any sort of Automated build or Continuous Integration - this can ease the pain a lot. When I merge and push (we use Mercurial and Git), my CI server triggers builds on the affected branches, runs the unit tests etc and lets me know how it all went - all unattended and automatically. <plug> Take a look at FinalBuilder (not free) and Continua CI (free for 1 concurrent build). Of course I'm biased, since they are my products but there are no better tools when it comes to delphi builds. https://www.finalbuilder.com/ </plug>

There is no standard answer to this, and I guess it also depends on what you are using for version control and it's branching capabilities. We try to follow this strategy https://nvie.com/posts/a-successful-git-branching-model/ but not religiously. I tend to create a feature branch off of my dev branch. If I find that I need other changes that are not specific to (but needed by) that feature, I'll go back and do them in another branch of off dev, and merge that into my feature branch and dev (assuming it's all good and tested). The main thing with feature branches is to make sure you are merging your dev branch into it often.. that softens the blow when it comes to merging the feature branch into dev when done. Long running feature branches are a pain in the proverbial, I often have several on the go at any one time... keeping them up with dev etc is a constant process.. I merge often - lots of small merges are easier than one big one with conflicts to resolve on code you wrote ages ago an can't remember specifics etc. HTH

Seems like the record constraint issue again. Same issue I have.

I use Spring4D extensively (but not all of it obviously) - Base and Core and Extensions compiled fine for me with Update 2.

I can't really say, I installed it, my code failed to compile and I did something else for the weekend. I would love it if the debugger was improved but haven't got to that point yet, perhaps others can chime in.

ok I'm blaming @Dalija Prasnikar for logging bugs on such esoteric code that no sane person would ever use

Logged as https://quality.embarcadero.com/browse/RSP-30073