corneliusdavid

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!

Right, but only if FindFirst returns true; if it's false, that block of code, including FindClose, is skipped. However, as Anders pointed out, if FindFirst fails, it doesn't allocate memory and thus does not need to call FindClose. It's possible that MadExcept is thinking that there could be a memory leak when there isn't actually one.

Ah! Then ignore my post. Thanks for pointing that out.

if "FindFirst() = 0" returns false, then FindClose() is never called. From the documentation: "FindFirst allocates resources (memory) that must be released by calling FindClose"

I would think either copying the files from the CatalogRepository or choosing a different path from the default offered by the professional installer would be make things so much simpler. https://www.bonfire.com/dont-accept-the-defaults-abel-wang/

There was nothing but FireDAC database components, a FDConnection and a few FDQueries--that's it. But--I found the problem! I had first created a FireMonkey program to test database connection and query results. Then I created an ISAPI DLL and copied the data module over and got the error. For easier debugging, I created a new a CGI app with just "hello world" for the default path, and that worked. So, then looked more closely at the data module and remembered to check the platform to which it's assigned and realized it had carried over the Firemonkey platform in its data module. The solution was to change the ClassGroup property of the data module from FMX.Controls.TControl to System.Classes.TPersistent and all is good.

If the only reason you're not using the TTimeEdit is because of the tiny up/down arrows on Windows (which I agree are practically useless), then you could build your own compound component out of a couple of combo boxes and buttons all squished together. But if you're targeting mobile platforms, you might want to see how the TTimeEdit looks on those platforms--they might look quite different. Or you you could use the IFMXPickerServices.

@Kas Ob., I got this same error just yesterday--not for creating a TForm but for creating a TDataModule. I thought for sure I could create a data module in addition to the web module used by the ISAPI DLL. Certainly, this is a different issue, right? @RDP1974, Why would you want a Form in a web module? If you want to display something, it would be returning HTML through a web action. Or, you could create a CGI app and run it from the console to see some output--but that's still not going to allow a TForm.

This falls under "Registration & Installation" so you get free support from Embarcadero: https://www.embarcadero.com/support

It looks like it's advertising for his Free Typography course. But actually reading through it, I can't understand why anyone would want ligatures in their coding font. At least he quoted and linked to Matthew Butterick's article--with which several of the commenters (and myself) agree. For me, I've used Consolas for so long, anything else is uncomfortable.

I was going to recommend DevExpress QuantumGrid but then you said it must be "easy to learn" so that one's out. How about Woll2Woll InfoPower? Both of these companies have been around for many, many years, with high quality products and good support for all versions of Delphi.

You don't "upgrade" the IDE, you install 12 in addition to 11.3; later, when 12 is stable and you've moved all your projects over and no longer use 11.3, then uninstall 11.3. As for the settings, it shouldn't take long to set them up--unless you select every single option to a non-default value. If there's a settings transfer tool, I don't know about it as it was never that much of a bother for me. If you customize all the colors, I'm sure you know about the IDE Theme Editor. The only time-consuming part is if you have several GetIt packages (e.g. styles or sample projects or libraries). That can take awhile--which is why I wrote AutoGetIt.

While AI is not built-in to Delphi, I recently used ChatGPT to help me write a Delphi function, saving me several hours. I'm sure there's a future IDE plug-in that will incorporate this somehow. However, I agree that Delphi has fallen behind other tools--and will likely never catch up as the industry is moving faster than the small, incremental enhancements that come with each release.

You mean this one line?

If course, if using untyped or variant parameters, but OP declared the test procedure with a specific type (Int64--I mistakenly mentioned floating point), which would not compile.

I've actually wondered about this myself. Isn't the purpose of the unit test to test what happens if you get invalid parameters? So this test would be expected to fail because invalid parameters (string) were sent in to a function expecting floating point. However, I suppose it could be argued that a calling a function whose parameters require a floating point, would not even compile in Delphi if sending a string, so a unit test of this sort is pointless?