corneliusdavid

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.

Yes, you can manage, but you might be missing out on productivity features or tips for improving your code by not taking advantage of some of these tools, many of which are free.

There's a good collection of tools and plug-ins listed. There are a few I had not heard of and some I've only recently learned about through this forum. It's a good idea to periodically review the tools available and make sure they're used to their fullest potential. I'm looking forward to the webinar.

The question wasn't which version of Delphi has NO bugs, just which one has the fewest.

That looks pretty cool. I'm a little nervous about running a program that messes with such an important part of Windows operations but it looks like it would work well.

Using tricks like this to is how I've gotten several versions of Delphi installed on one box (along with everything else I use regularly). The PATH setting on my machine only takes 1,876 characters but when fully expanded, it's 6,327 characters long! Every time I install another version of Delphi, I ignore the "PATH is close to the limit" warning, then go edit it later, creating, for example, D23 to replace "C:\Program Files (x86)\Embarcadero\Studio\23.0".

True but it's more than just RegEx--Grep also uses RegEx expressions. reFind has some Pascal smarts in it; for example, when using #migrate to change a class and identifier in your code, it can add the new required units to the uses clause.

It's a batch file run by the Task Scheduler as administrator calling the sc command. For me, it's an in-house copy of RAD Server, so just stateless web server API calls--no continuously connected client. And to be clear, for a customer installation, I would purchase a license.

grep is just search; reFind is search and replace.

Same here. Pretty easy limitation to get around.

I spent a bunch of time with this tool last week and am developing a big script for our use. One of the clunky steps in our migration process is converting a TPanel with TSpeedButtons to a TRzToolbar with TRzToolButtons. The original instructions had us manually editing a descendant form's DFM outside of Delphi before opening the project because of all the errors we'd get otherwise. Now, ReFind modifies the DFM and PAS file for us smoothing that process significantly. This, along with several other unit and method signature changes, the migration process will likely be reduced by several days or even weeks! Comparing with my experience using DelphiParser, there are still a few things things DelphiParser can do, like adding a new unit to the uses clause, which, as an action by itself, reFind cannot--it can replace an identifier and add to the uses section that way but there is not just a stand-alone unit addition command in reFind. DelphiParser seems to actually understands the Delphi syntax better and work with different unit sections and objects and variables whereas reFind is mostly a line-by-line string replacer. I'm over-generalizing and there's a lot of overlap but the reFind tool, being free and command-line based is much more accessible and easier to use. Thanks again, @Jim McKeeth for reminding me of this tool.

Code Compatibility. Delphi is nicely upwards compatible. There may be a few things where Unicode or AnsiString types are concerned but the code itself is surprisingly simple to upgrade. Third-Party Components: This may be the biggest challenge. Many small third-party component vendors are no longer around and there are some new ones. If you used Woll2Woll, you're in luck; if you used AddictSpell for spell-check, you'll need to look at TMS or DevExpress. If you used Raize Components, they now come with Delphi as Konopka Signature VCL Controls. TurboPower components are now open source with a few of them forked off to new products. You will have to do a lot of research to figure out which ones you can upgrade, which ones you'll have to replace. Database Connectivity: This will be highly dependent on what database you're connecting to. If you used a dBASE or Paradox type connection through the BDE, you would be advised to migrate to a SQL-based engine. If you used a BDE-replacement database, like DBISAM or one of the many others that are still in business, you can likely just upgrade. There are a few, like Firebird or Advantage, that FireDAC actually supports today. User Interface: Monitors are much bigger and have much higher resolution today, so a program that looked fine on 800x600 yesteryear will look tiny and outdated today. Increase the font size, use TGridPanel in some cases, add styles, use AlignWithMargins, and study webinars on the subject. A lot of the answers you're seeking will depend a lot on what you have. For example, the database update could be simple or difficult depending on what you're using. I'm involved in a large migration from Delphi 5 to Delphi 12 and the database back end is SQL Server which makes it simpler in some ways but going from BDE to FireDAC is not easy. If we were using a well-established database alternative that existed for D5 and is still around today, we probably wouldn't have to change quite so much--but then again, it all depends on how it was originally written: iterating through table components, no matter what database technology or components are in use, should be tossed in favor of writing queries--which could've been done in D5 or D6. Lots of other good answers here too, but with vague questions, you'll get vague answers.

No, the server service has to be stopped (disconnecting all connections) and restarted.

What does this have to do with Wonky Toolbars? @Kgorinyane, please repost in a new topic.

Probably this one as it's the only one (I know of) that is focused on FireMonkey: Delphi GUI Programming with FireMonkey.