Fred Ahrens

You can control the client via command line (see https://www.virtualhere.com/client_api). This allows you to create build scripts that temporarily activate the dongle on the client system only when it's needed for signing your files and deactivating it after when the script finishes.

+1 for Proxmox. For a very long time I had the impression, it's an "enthusiasts platform for virtualization". One of our customers "forced" us to test our software under Proxmox and 1 month later most of our bare metal machines and VMs were migrated to Proxmox VMs and containers. Couldn't be happier too.

For using the code signing dongles (or any other USB device) I recommend VirtualHere. Install the VirtualHere server in the host machine and your USB dongles/devices connected to the host can be accessed via a simple client within your VMs. It's not free but not expensive and just works. Meanwhile we switched from Hyper-V to Proxmox as it has built-in USB-pass-through and other features missing in Hyper-V. But main reason was: there is actually no longer a free stand-alone Hyper-V server as it got discontinued by Microsoft.

I don't need any new features. I just need that the existing features work as intended. And there are many areas where existing features need to be made usable again (e.g. refactoring, code formatting, HighDPI). OK, one new feature would be nice: compiling for Raspberry Pi. But fixing the existing features needs to be done first.

For me it's the lack of communication. Errors happen, but at a certain stage they should start to communicate about the error and give some advice about expected timeframe for fixing the problem, possible workarounds and so on. I really don't care (that much) how long this takes - but it would be nice to get some regular updates about the progress made. We are now in a situation where we have to review our development environment and make it as independent as possible from the availability of Embarcadero servers. In result we have to stop using GetIt, and other services may follow.

Sorting units by name is dangerous. There are some units that need to be added at the end of the list, if they overwrite some behavior's of objects and functions of other units above in the list. There are other units that need to be placed on top of the list if they do some special initialization that needs to be done in the app as soon as possible, before any other parts of the app start to initialize.

I prefer Alternative 1 but I wouldn't use "else". Using "else" might slightly improve performance in some cases, but without the "else" I think the code can be parsed better during code reviews (gets closer to the readability of the version using the case statement). if aMessageType = 'EXPREG' then DecodeExportReg(vDoc, aCdn, aRequestCorrelation, aMessageText); if aMessageType = 'EXPACC' then DecodeExportAcc(vDoc, aCdn, aRequestCorrelation, aMessageText); if aMessageType = 'EXPERR' then DecodeExportErr(vDoc, aCdn, aRequestCorrelation, aMessageText); if aMessageType = 'EXPREL' then DecodeExportRel(vDoc, aCdn, aRequestCorrelation, aMessageText); if aMessageType = 'EXPREF' then DecodeExportRef(vDoc, aCdn, aRequestCorrelation, aMessageText); if aMessageType = 'EXPREQ' then DecodeExportReq(vDoc, aCdn, aRequestCorrelation, aMessageText); if aMessageType = 'EXPINF' then DecodeExportInf(vDoc, aCdn, aRequestCorrelation, aMessageText); if aMessageType = 'EXPREJ' then DecodeExportRej(vDoc, aCdn, aRequestCorrelation, aMessageText); if aMessageType = 'EXPCLA' then DecodeExportCla(vDoc, aCdn, aRequestCorrelation, aMessageText); if aMessageType = 'EXPCON' then DecodeExportCon(vDoc, aCdn, aRequestCorrelation, aMessageText); if aMessageType = 'EXPAME' then DecodeExportAme(vDoc, aCdn, aRequestCorrelation, aMessageText); if aMessageType = 'EXPIRJ' then DecodeExportIrj(vDoc, aCdn, aRequestCorrelation, aMessageText); if aMessageType = 'EXPARJ' then DecodeExportArj(vDoc, aCdn, aRequestCorrelation, aMessageText); if aMessageType = 'EXPHRT' then DecodeExportHrt(vDoc, aCdn, aRequestCorrelation, aMessageText); OT: just learned about the existence of IndexStr.

This looks like a rounding problem in the function that calculates the toolbar sections. As a workaround you can try to move each section of the toolbar to the right while leaving gaps with some pixels width between all sections. This should avoid the overlapping of sections due to the calculation error and prevent moving toolbar sections to the next free line on the toolbar. (not tested just guessed)

For HTML to MD conversion (and from/to other formats) have a look at https://pandoc.org/

If you want to convert .md files, you are looking for a "Markdown" converter - not "Markup". The source code at https://github.com/grahamegrieve/delphi-markdown might be exactly what you are looking for.

Had the same problem. After disabling the ad blocker the Submit button appeared.

uses Vcl.ExtActns; procedure Download(URL: String; FileName: String); var DownloadAction: TDownloadUrl; begin DownloadAction := TDownloadUrl.Create(nil); DownloadAction.Filename:=FileName; DownloadAction.URL:=URL; DownloadAction.Execute; DownloadAction.Free; end; But no error handling at all.

@w0wbagger you should read their license carefully. After the last update of the license the components were limited to development and inhouse use only. Edited: I was wrong about inhouse solutions. Those are covered by the license.

Sending it by fax means you have to print it first. Your printer driver may offer a watermark function.

Wow. We started using CDATA connectors already two years before Embarcadero started bundling it with some of the Delphi SKUs. I wasn't aware that license conditions have changed. I just checked and compared with older EULAs shown during the CDATA component installation and there wasn't a limitation to inhouse distribution only. The 2018 version of the EULA was more similar to typical other component packages - only the typical restrictions did apply. With this license change we'll have to stop using CDATA components. I guess we could afford to pay the costs for upgrading our existing licenses and bring them back to a royalty-free distribution model. Finally it would be a stupid investment as we don't know what other changes might be introduced in the licenses through the backdoor and might render our investment useless (again). I'll be happier with spending that money at other component developers who have a more developer-friendly business model.