corneliusdavid

And don't forget to select MS Build for "developer tools for compiling, building and testing" as that's what the Delphi IDE uses.

I have found myself writing a method that then got longer than I originally anticipated. In order to keep it to a manageable size, I would separate sections out to sub-procedures but then find it necessary to refactor and the decision to send parameters to these new subroutines or not generally ends up with these "local global variables" instead so I don't have to change so much of the code. Yes, it's a little lazy but I never considered any performance hit until reading this thread. Still, for these programs, the performance is usually negligible. And for the record, I never start out with the intention of writing nested procedures like this, it only happens after-the-fact during a refactor process.

Yes, I have used the UniGUI Migration tool on a fairly small (~40k lines) Delphi XE project. It's supposed to take a VCL program and replace all the components with their UniGUI equivalents so that you can turn your Windows-only program into one that runs through the web. As most typical applications, I use a few third-party components like DevExpress Quantumn Grid, Raize Controls, and some spell-check components. I figured I'd either lose functionality or have to find replacements for a few but was surprised that the migration tool does not support ANY third-party controls; in fact, it doesn't even support all the VCL ones. It doesn't know how to translate TLabeledEdit, TNotebook, TGridPanel, TBalloonHint, TBevel, TDBRichEdit, TDropDownButton, or (a big one for me in this particular project) TCategoryButtons. Many of these I could modify the script to add direct replacements but something like TLabeledEdit that needs both a TLabel and a TEdit, you have to do manually (separate into two VCL components in the original code before migrating). Things like TBalloonHint just get deleted as the functionality on a web app is different. Also, none of the dialog components (TOpenDialog, TSaveDialog, TTaskDialog, TPrinterSetupDialog) are supported. For most of the RaizeControls, I easily found the UniGUI replacements in the script for the VCL equivalents and added these to the list but I wish support for some of the more popular component sets could've been added to the standard script. If a control is not found, it's just skipped so it wouldn't hurt to have lots of third-party controls listed in there. The user interface is clunky--no settings are remembered between sessions, you have to hunt for the project file every time and once it's finished processing, the only option is to close the program. After running a migration and loading a converted project, I would make some changes to the script and have to restart the program, re-select the project file, and hit Next a few times in order to run the migration again; a minor irritation, I suppose, but for something that will be run multiple times until it looks right, having to restart and go through this whole series of steps instead of just clicking re-run or something was annoying. However, it does do a lot of the migration work for you, copying your project to a separate directory and making all the project and unit changes to produce a UniGUI project. I never did finish migrating my project to UniGUI because I was doing this on my own time and got busy with other stuff--but I still might come back to it some day and try to finish it.

There is nothing AI Powered about it; he's just trying to utilize the current hype. The product has not changed in at least four years--except to be recompiled to support newer versions of Delphi. It's just a parser that replaces components and units according to a script.

For what it's worth, I've been using Delphi 10.4, 11, and 12 and just the other day, I encountered this exact same problem with Delphi 11, runtime error 236. I did a quick internet search and landed here, so tried the suggestion of removing things, except I went to the Registry and deleted entries from "Software\Embarcadero\BDS\22.0\Known Packages". Since I don't do any repository management from within the IDE, I deleted anything to do with SVN, Mercurial, and Git (about 6 entries, I think) and restarted Delphi 11 just fine.

No need for any changes to my entry--TStreamReader handles both already. And yes, I tested it.

I inadvertently included a second screenshot in my previous post--ignore that. Also, I didn't thoroughly read the whole problem and my answer does not solve the problem, even after playing around with the combination of AutoActivate, InitializeControlValue, Managed, and Track properties of the binding.

In the LiveBindings Designer, click on the arrow-line that connects the two components (the line will turn bold to indicate it's selected): (Instead of visually selecting it, you can double-click the BindingsList component on the form and select the TLinkControlToProperty that connects these two components from the list of LiveBindings.) Then in the Object Inspector for this link, check InitializeControlValue.

Lots of options! Command-line parameter validation fixed for Delphi--pull request made. Generated a few different sized files for testing, the last two: 100-million row file created in 9 seconds 1-billion row file created in 2 minutes, 23 seconds.

QuickLib.Parameters would've prevented you from needing to reinvent the technique--but it's a little overkill and it would require bringing a whole lot of other stuff along with it.

I almost made a pull request last night but then backed it out after I made another test. The generator program parses the parameters and checks to make sure they're valid but in Delphi, the way it's done adds a CR/LF which causes 'h' <> 'h$D$A' and thus fails even a valid command-line. I fixed that but didn't take into account that some parameters have a second part (like --line-count or --input-file) so I need to add that. I'll certainly make a PR when it's ready.

Hey Gus, It seems like a fun challenge that people who have time and interest will look at and participate. We've got a couple of months, so plenty of time to get involved if you're so inclined. One question: the .CSV in the repository has only 44,691 entries. So, the idea is that we need to run the generator program first to generate the 1B file, right? I suppose this could also, then, be used to generate smaller files for development testing. Thanks for the links and for bringing it to the Delphi community!

Might possibly be for future implementation. Or maybe these were part of a large group of types or constants imported from a header file of some sort. I found a couple of references that look like there's some relevance: https://github.com/dotnet/runtime/issues/29900 https://www.newtonsoft.com/json/help/html/t_newtonsoft_json_defaultvaluehandling.htm

I would consider this a report: https://blogs.embarcadero.com/we-are-experiencing-a-hardware-outage/

This may be overkill and I'm not sure there's a way to limit to just bank holidays or to specify the country, but here's an API that boasts 5,000 holidays: https://apilayer.com/marketplace/checkiday-api

If it runs fine in debug mode but then you compile in release mode (which I think is what you mean), is there a conditional in your code that sets up the database connection differently for debug mode, like maybe you're using a local database for testing but the release mode one is connecting remotely for the customer?

What version of Delphi? At runtime or design-time in the IDE? What database? What type of activity--I assume at least connecting? Is it using the same connection in debug and release modes? Are the release and debug configs generating executable in different directories? Perhaps it loading a configuration from an .INI file which is in one location but not the other? After the form is loaded, does everything run fine (assuming this is at runtime)? There are so many things this could be--we need a little more information.

Interesting! And written in Go.

They're now called the Konopka Signature VCL Controls (KSVC) but carry the "Rz" prefix from when they were known as Raize Controls. Here's the GetIt link: https://getitnow.embarcadero.com/bonus-ksvc/ https://raize.com/embarcadero-acquires-raize-components/

This is the perfect time and place to bring it up and get people behind it! I've started reading a little about it and it looks well thought out.

Convenience, laziness, curiosity. I've found myself browsing the GetIt packages (when it worked) and coming across something that looks interesting but I had not seen before. To try it out, it's really easy to just click Install and start using it to see if it's something I want to keep around. After it's installed, it might get "stuck" there out of laziness or because I only used it once or twice. To switch to the original repo means uninstalling the GetIt package, cloning the repo, learning how it's installed or how to access it... not difficult, just steps to take when there's time and it's going to become a steady part of my library.

Do these files still exist? C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusNavigator_XSydney.dll C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusCoreEditor_XSydney.dll C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusBookmarks_XSydney.dll C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusCoreEditor.dll C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusNavigator_Alexandria.dll C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusCoreEditor_XAlexandria.dll C:\Program Files (x86)\Common Files\ParnassusShared\ParnassusBookmarks_Alexandria.dll

I agree. Perhaps this will give a popularity/support boost to one of these: dpm duget For me, any open source package that I had previously installed via GetIt, I'm now pulling from GitHub. I suppose I should've done that from the beginning as it would always provide the latest version but this has certainly solidified that decision.

I'd suggest calling support.

Oh, so the error was in code that we did not see! LOL! That makes it difficult for us to debug!