corneliusdavid

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.

26 minutes ago, Gustavo 'Gus' Carreno said:

The fact that Free Pascal has TCustomApplication that has inbuilt params parsing and checking makes it a breeze to use out of the box.
I'm just sad that Delphi hasn't invested in something like that out of the box and leaves the programmer a bit in the lurch to do the same boilerplate stuff every time.

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.

3 hours ago, Gustavo 'Gus' Carreno said:

Had a look at your fork and if you feel that your changes make more sense in the Delphi side of things, I'm quite happy to merge the PR and push a v1.1 tag.

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

57 minutes ago, Silver Black said:

they didn't report anything

I would consider this a report:

https://blogs.embarcadero.com/we-are-experiencing-a-hardware-outage/

21 hours ago, Henry Olive said:

Is there a way to consider also local bank holidays

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

10 hours ago, PiedSoftware said:

But when I run it without the debugger it is less than 3 seconds.

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.

On 2/3/2024 at 4:11 AM, Jonah Jeleniewski said:

I'm surprised no one has mentioned Boss,

Interesting! And written in Go.

6 hours ago, Vadimmmm said:

Can you point me to where to look, where to find them?

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/

6 hours ago, Vadimmmm said:

I didn’t find anything on their official website

https://raize.com/embarcadero-acquires-raize-components/

3 minutes ago, Vincent Parrett said:

I wasn't going to bring it up in this thread.. but since you opened the door...

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.

18 minutes ago, David Heffernan said:

I've never understood why anyone would use getit over the main source repo for open source projects

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.

On 1/30/2024 at 5:17 AM, marcocir said:

I've just deinstalled 10.3 version and this is what I get if I try to execute Delphi 10.4.2 or 11.3

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

2 hours ago, David Champion said:

An alternate package manager needs to be controlled and run by an organisation outside of Embarcadero which would give the community a little bit more leverage.

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.

1 minute ago, alogrep said:

Sorry, there was another FindFirst() very close to the first one  without FindClose().

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

2 minutes ago, alogrep said:

But I DO use FindClose()

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.

2 minutes ago, Anders Melander said:

So on failure there is nothing to free with FindClose;

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/

8 hours ago, Kas Ob. said:

the problem is what is on it !!?

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.