Lars Fosdal

@Uwe Raabe - The pro version of Kraken allows me to create and comment on issues in the tracker, being it Jira, GitHub, GitLab, etc. We simply liked Kraken better than Fork - who knows - that may change over time. You can also create a feature, hotfix or release branch from the Issue, ensuring the commit will contain the issue reference.

Web Installer or ISO image?

Rio 10.3.1 Indy TIdSSLIOHandlerSocketOpenSSL seems to not support TLS 1.3. Is there an update anywhere?

My perspective is from the VCL app where any number of frames and forms can have focus. Having to deal with the wedged in virtual keyboard that produces input that is not intended for a checkbox or a button is a PITA, hence the COM port. We accept the scan over the COM port in a background thread and decode the GS1 128 AIs to build a content description, queue it, and post a message to the main window which then propagates the info to the focused form/frame. The frame can then check the queued AIs by identity to see it there is content relevant to it. This also allows us to capture the scans faster than we process them, so that the user doesn't have to wait.

BTW - Technically, KebabCase 🐑🍽️ should read kebab-case since it typically is used for f.x. REST API URLs where each word is on a hyphen skewer, i.e. a kebab of words. F.x. https//fictivedictionary.com/api/get-meaning-of-word

Or simply prefix with Local<var name> or even UnitLocal<var name>? No need to remember any special meanings of a single letter.

If you already have a driver, the associated COM ports should be identifiable from the device manager. Open Device Manager Click on View in the menu bar and select Show hidden devices Locate Ports (COM & LPT) in the list Check for the com ports by expanding the same

Usually there would be a driver that allows the scanner to be accessed as a COM port, or the scanner presents as a virtual keyboard (wedge configuration). The latter is something that we avoid. The COM port abstraction means it doesn't matter if the device is a BT device, a serial device, or an USB device. A possible starting point would be to explore from here: https://www.zebra.com/us/en/support-downloads/knowledge-articles/evm/emulating-a-com-serial-port-over-usb-using-cdc-driver.html

No, not really. I just use a longish descriptive name, and I keep the declaration near the routines where it is used. F.x. unit SoAndSo; interface // lots of other declarations procedure ClearThreadContextLog; procedure SetThreadContextId(const aId: Integer); function GetThreadContextId: Cardinal; function GetThreadContextLog: TArray<String>; procedure AddThreadContextLog(const aText: String); implementation // lots of other code threadvar ThreadContextLog: TArray<String>; ThreadContextId: Integer; procedure ClearThreadContextLog; begin SetLength(ThreadContextLog, 0); end; procedure SetThreadContextId(const aId: Integer); begin if (aId <> ThreadContextId) then DebugOut(Format('Setting ThreadContextId %d for ThreadId %d', [aId, GetCurrentThreadId])); ThreadContextId := aId; end; function GetThreadContextId: Cardinal; begin if ThreadContextId > 0 then Result := ThreadContextId else Result := GetCurrentThreadId; end; function GetThreadContextLog: TArray<String>; begin Result := ThreadContextLog; end; procedure AddThreadContextLog(const aText: String); begin var len := Length(ThreadContextLog); SetLength(ThreadContextLog, len + 1); ThreadContextLog[len] := Format('%d %s', [TThread.CurrentThread.ThreadID, aText]); end; // lots of other code end.

Ref the title "Prefix unit local variable names" I avoid unit local variables as far as possible. Those I have made in recent years are declared under the implementation part of the unit. Any interaction with them from outside the unit uses procedures and/or functions Alternatively, they are implemented as class properties on a specific type.

What I am using the most 32-bit console or VCL for due to the shite debuggers for 64-bit platforms.

Valid point on the conclusion - but after testing a little, the IDE git support is to put it mildly - kinda gimped. If they can bring it up to the level you see in VS Code, it helps - but a proper UI or black belt in command line git still is needed. We've spent today testing Fork and GitKraken and landed on GitKraken Pro due to the issue tracker integrations and built in GitFlow support - which really simplify doing proper branching for features, fixes and releases.

I see that nobody has commented on the IDE git integration, so I guess nobody is using that?

QED: Lars is a sucker 😄

https://git-fork.com/ looks very interesting! ...and I suddenly realized that front page image shows Anders Heijlsberg doing his TypeScript commits with Fork. /star-struck

Even as a long time TortoiseSVN user, I am slightly uncomfortable by the rather cluttered interface in TortoiseGit. Too many options. We are more likely to document step by step actions using a specific GUI and use powershell scripts that are based on this method of working: https://nvie.com/posts/a-successful-git-branching-model/ where possible. Using git with Delphi is straight forward but using git for SQL Server is a major exercise in Catch-22. Currently evaluating 1. Visual Studio Solution & git integration commit and push -> pull request -> CI script to deploy to staging databases 2. Ediiting DB in SSMS ->script that runs DB -> ApexSQL Diff -> local file folder -> git commit and push -> pull request -> CI script to deploy to staging databases 3. ApexSQL Diff direct to/from DB and git (which should have worked, but does not - awaiting support response) -> CI script to deploy to staging databases Each of the variants have pros and cons.

Indeed.

Have you checked if this is registered on https://quality.embarcadero.com/ ? Could you please register it if you can't find it?

It is pretty quirky - even on Windows.

I had not read that. Lots of useful info, so I will have chat with the Azure guy. Azure being Azure, I don't know how much control we have of the separation of the VMs, except you pay quite a bit more if you want a dedicated instance.

You know the tool 🙂 Continua + FinalBuilder, @Vincent Parrett. Can't say that going from 10.3.3 to 10.4.1 made any significant improvement - that said - we also switched from a dedicated VM on a local cluster to a managed VM on Azure at the same time, so it is difficult to make a direct comparison. Yes, the code is generics heavy, but the above time also includes unit testing, code signing and Sisulizer translation of two of the apps as well as deploying the files to the staging catalog (edit2: oh, and we use Eurekalog which takes forever to fixup and link). Edit: the build time also goes up if the live branch is compiling at the same time as the trunk branch. Will need to learn to say main instead of trunk soon - to stay with git terminology. Finally making the move from SVN to git. Wish us luck.

Experimental only, and not with OTL - but we would also like to have OTL fully functional on Linux to open that door.

We've got some old, handcrafted Delphi code that produces dynamic HTML/CSS content that we use as a web UI to a service. I would NOT have done it the same way today.

Building our software takes about 20 minutes now. Building the 1MLoc "workstation" app, takes 1:17 with Eurekalog linking on my laptop. Just enough time to quickly glance at these forums 😛

Sometimes I've spotted domain names that were unused, and I wondered if I should be squatting - but - I decided against it. I do wish I grabbed some two decades back, though.