Lars Fosdal

I know @Daniel tweaked something - but it was supposed to only affect the EMBT people's inability to edit their own posts?

Anders, With Assert If In_The_Shit then Panic Without Assert If In_The_Shit then DoOurBestToCope else BizAsUsual;

David, The full callstack at the time of the assert is in the first attached QPInfo file of https://quality.embarcadero.com/browse/RSP-31944 Added the extract in a comment.

Please give your post a meaningful title.

Just want to add that I loved the way it worked up until that error which hopefully can be quickly remedied.

@David Millington Unable to reproduce in small example. But, uninstalled the Parallel Debugger - and the Assert fail no longer happened. Created a QP https://quality.embarcadero.com/browse/RSP-31944

Repeatable. And - it brings down the IDE. Will be checking if it is possible to make a small example when I get time.

I had a failing assert in some CPP code - which I sort of assume is this plugin, since I've never seen it before. It happened on a breakpoint in an exception handler, and it brought down the IDE. Asserts in production code is not a good practice.

There is a fallback to the free version for GitKraken as far as I can tell?

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