corneliusdavid

I don't understand why this would be a concern. Certainly, any AI built in would just be an interface to utilize your own AI account somewhere, right? Nothing would get automatically uploaded unless you hook it up and start using it. Just like Delphi has integration for git but you don't have to use git inside the IDE unless you tell it to and give it your account information. Am I missing something?

It was interesting seeing this list and the responses as I've only used the free ChatGPT about a half dozen times--I haven't considered getting into it seriously. But I decided I should look through these tools listed here (didn't know there were so many geared for programming!) and get up to speed since AI is here and being used and talked about everywhere these days--I'm starting to see how this could be quite a time-saver for many things. Today, I was struggling with some untyped string parameters being passed into a function and it was failing to get the values properly after converting this old code from Delphi 5 to Delphi 12. I knew I had to add support for UnicodeCode types but I was struggling with how to get the value from the embedded pointer. I asked ChatGPT and it gave a pretty good answer--and it was correct but it only listed the new Unicode and WideString types. I wanted to be able to support ShortString as well. So, I posed the exact same question to Claude and it gave a nearly identical answer BUT included support for ShortString as well, noting the slightly different syntax (you have to dereference it while you don't with the new modern string types). I asked Claude about the difference and it gave a good answer about the history of string types and why ShortString has to be handled differently. I'm very impressed and am about ready to sign up for Claude! (I like what I'm reading about it's "project" feature as well.) Thanks all for your comments!

By default, creating a new Windows Application in Delphi 7 uses the VCL framework. That was the default since Delphi 1--and actually is still the primary one on the menu today (unless you change it). So, if you select "Application" and not "CLX Application" from the New menu then you are creating a VCL application: Once the application is created, you can look at the main form of your application. In addition to what @jonnyg said by checking whether it's linked to DFM or XFM resource, you can Ctrl+Click on one of the used units, such as Forms, and look at the comment header, which will tell you explicitly what type of component library is being compiled and linked in: {*******************************************************} { } { Borland Delphi Visual Component Library } { } { Copyright (c) 1995-2002 Borland Software Corporation } { } {*******************************************************} unit Forms; In newer versions of Delphi where VCL is not always assumed, the menu choices to create a project are more clearly specified. For example, in Delphi 11, this is the default New menu: ... and "Multi-Device Application" is using FireMonkey (FMX) as that is the only cross-platform visual library that comes with Delphi these days.

Well, I feel silly. I just noticed a parameter in DosCommand's NewLine event that indicates whether it's a full line or not. Checking that now gives a cleaner log--no partial lines. So, yeah, DosCommand works great!

AutoGetIt uses it to launch batch files. The only problem I've had is that sometimes partial lines are returned as full lines, then the next NewLine event returns the full line. Not sure if this is a problem in DosCommand or some OS-level buffering--never took the time to look deeply into it.

That's what I was thinking. DosCommand works great and is pretty easy to use--no need to get into the intricacies of CreateProcess.

What is "such a shame"? Perhaps you're just unfamiliar with current best practices? There are many components that use the Images property: TBitBtn TSpeedButton TCategoryPanelGroup TMainMenu TActionList TTabControl TPageControl And many more. Plus, many third-party components use this property as well. It's far more versatile than the old Glyph property. Search for articles and YouTube tutorials--you'll find plenty of information.

I believe you're right as evidenced by both 12.1 and 11.3: But back in XE series, some patches were referred to as updates: That's pretty nice and comprehensive code!

It sure seems like there should be but I can't find it. I think the Wikipedia page has a pretty good overview of the version history but it's unofficial, of course. I've got a list of several Delphi About screens of several versions of Delphi and your 12.1 build number matches the one I have installed. I've found that "patch" is often interchangeable with "update" when it comes to Delphi version numbers (although "update" seems more official and more often includes features while "patch" is more often used for bug fixes or missing files in the original installation).

Visit the Indy page on Github and follow the Documentation link on the Wiki: https://github.com/IndySockets/Indy/wiki/Documentation

What kind of help are you looking for? Design suggestions? You could reduce the font size so the tab captions fit. You could show the tabs vertically instead of horizontally so you could see the tab text but it would take a lot of screen space. You could display icons instead of text on the tabs and then have a label at the top of the each tab's body area to identify the selected tab. You could detect the form factor and use different techniques on different devices to show more text on larger devices and less on smaller ones, putting the ease-of-use back on the user and their choice of device.

Is this a one-time input of historical data or is more data available from the API every day? Perhaps it makes sense to write a completely separate program that operates in the background and just pulls data into a local database on a regular basis and then your user-facing program interacts with the local database?

I totally agree. I don't think I have EVER created two forms to work with the same data--seems like tremendous unnecessary duplication of effort plus a maintenance nightmare to remember to have to make changes in two places any time you need to add or change a field or label or some other aspect of the form. And, as mentioned, it's as easy as checking the State property of the associated dataset or a flag variable if you're using non-data-aware controls. This would be the one exception I can imagine and makes sense to tightly control some required fields and help the user fill out the data properly but that's really a different purpose, sort of like creating a report or grid to view records in addition to the form that created them is also a different purpose.

From the Delphi Help file on TSQLTable.IndexFieldNames...

So, just to make sure we're on the same page, I open up the Windows unit (or WinAPI.Windows), find a function with a stdcall that calls an external Windows DLL, like CreateRemoteThreadEx or GetFreeSpace or QueryIdleProcessorCycleTime (just to pick a few at random), place the cursor and hit F1 and it should take me to a Windows API Help, right? I think I remember seeing this many years ago but not recently. I tried this in several versions of Delphi (XE, XE2, 10.1, 11.3, and 12.1); most of these pull up the generic "Code Editor - Getting Started with RAD Studio" help (some of the older ones have broken help files now). Some of them find specific (or related?) help, such as ToolsAPI.IOTAProcess60.GetCurrentThread and System.FindResource. But none of them brought up a Windows API local help file. In both Delphi 11.3 and 12.1, the Help menu has Platform SDK Help > Windows Platform SDK Library and clicking that takes me to the learn.microsoft.com web site for Win32 API. I guess that's the best we have now.