corneliusdavid

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.

The solution for this is genius! Thanks, @dummzeuch for that blog article and the library!

I had heard of this utility once before but failed to follow up and read about it--then promptly forgot about it. This looks very promising to solve a major migration effort at my job!

After reading some of the other posts here about Java 11, I breezed through the installation for both D11 and D12, opened a small project, made sure several units were open in the IDE, and selected Analyze All Open Files. I like how the suggestions are brightly highlighted right in the IDE--many good suggestions. This is pretty slick! I thought at first it only analyzed the current file but as soon as I switched to a different file in the IDE, the Delphi Lint window updated with the different list of suggestions for that file. Double slick!!

Yes, I'm a subscriber, too, and find it incredulous that I keep getting emails from "my representative" (as if I need one) about learning about the new version and would I like a demo. I usually just ignore these, shaking my head. But recently, I was in a mood that just sent me over the edge and fired back an email asking why on earth they keep asking if I want a demo and why doesn't the marketing department have a list of current paying customers? (I said a little more than that.) I got an apology back with a note that "marketing will be updated." I think every time we register for a webinar and have to check that box that agrees to receive marketing material, that it re-flags our email address as a "potential" new sale. I might stop registering for webinars and just watch the YouTube replays from now on. Yep. That's why we're still here. LOL! It's been a while since I heard these "shoot-yourself-in-the-foot" phrases--so funny because they're so true!

As @Dalija Prasnikar said, it'll depend a lot on your code. I work for a company who never upgrade a whole suite of accounting programs from Delphi 5; my primary job is to upgrade them to a newer version of Delphi and I'm very glad because many of the programs actually crash Delphi 5, just sitting there in the IDE, without editing or compiling! I'm sure it's some of the in-house components but there's just so much code and over two decades of history that I just can't wait to get rid of that version and move into a better, more feature-rich IDE with better debugging and newer components. Throughout this process, we're reviewing all the libraries and climbing out of a lot of technical debt. A big part of the change is switching from the BDE to FireDAC--that alone is solving a lot of problems and is a big factor in performance and stability. For my own projects, I have some code in Delphi 7 and XE, those are very stable versions; I prefer Delphi 10.4 and 11 for the IDE features--those are working well for me.

That's a great tip--I never noticed the "reset" button but I'll have to try that next time things look weird.

Are you using High-DPI? I was using mine in a multi-monitor setup where one of the monitors is High DPI and the other is regular resolution. My default desktop would run Delphi on the High-DPI monitor so I could see more on the screen at once while coding but I wanted to see the code while running the application, also on High-DPI, so the debug desktop was on the other monitor. After a few debug sessions with Delphi switching back and forth between the monitors, it started going wonky, so I just gave up and now always run Delphi on the High-DPI monitor only (always in DPI-unaware mode). But yeah, I remember toolbars disappearing or showing in weird places.

dir c:\* /s This is probably filtering out hidden and system files while FindFirst does not.

Yes, this has annoyed me in nearly every Windows program for many years. I often want to highlight something or select a row in a list, then go to a different program and look back at the other program to type something in that is similar or whatever and when I look back, the highlight is gone until I switch focus back to that program. I don't understand why someone thought this was better and designed the OS this way.

Strangely enough, I just also ran into this with Delphi 10.4 but had much less success. I tried disabling several packages but to no avail. In desperation, I tried to reinstall Delphi 10.4; it uninstalled it fine but when it started re-installing got an error trying to write a style file in the "Public Documents" folder. I thought this was very strange, especially since there is plenty of space and a quick test proved I could create a text file, modify it, and delete it just fine. Rebooted the computer--still no go. I have Delphi 10.4 still installed and working on my laptop, so at least I have that as a backup but this is concerning. I don't think it's a Delphi problem but won't have time to research further until next week.