dummzeuch

I tried MMX but it's a lot less convenient than the integrated refactoring. I don't remember the specifics, but I think e.g. you have to enter / select the type for a new variable / field rather than have the tool infer it from what is assigned to it.

Hm, interesting. Some of it could be easily done with the GExperts code formatter, but not all of it. Care to write a feature request? (I'm not promising anything! But having a formal feature request would definitely increase the likelihood of somebody implementing it.)

These refactoring methods worked for me quite well, most of the time: Declare a variable or field Rename an identifier (that one always worked fine within a single unit and most of the time even for the whole project) Extract selected code to a method I have been using them since they were introduce in Delphi 2007 and I already miss them.

I just tried the new RAD AI companion: Give me example code that returns the IDE's version number plus build number as a string from within an IDE plugin Not impressed.

The form is a TfmClassBrowser, which descends from TfmBaseForm which in turn descends from TForm. It calls this function passing Self as parameter: function GxOtaInitTheming(AForm: TCustomForm): Boolean; var LService : IOTAIDEThemingServices; begin Result := False; LService := GxOtaGetIDEThemingServices; if Assigned(AForm) and Assigned(LService) and (LService.IDEThemingEnabled) then begin LService.RegisterFormClass(TCustomFormClass(AForm.ClassType)); LService.ApplyTheme(AForm); Result := True; end; end; Which is what I think you mean by "registered to the ThemingService". I also tried explicitly calling IOTAIDEThemingServices.ApplyTheme for the TMainMenu, but it didn't have any effect.

I am trying to fix the remaining glitches in GExperts to follow the IDE's dark/light mode setting (which was implemented by @Achim Kalwa, Thanks a lot Achim!). One thing that does not work is dark mode for a TMainMenu. The menu bar itself is not themed, but its sub menus are themed as expected. Is that a bug in the VCL? A problem that only happens in IDE plugins? Or PEBKAC ?

Simple answer: Yes. You don't take any code from the web and use it without understanding it.

So you are a lucky one. For me it's also mostly our own code, but some of it is so ancient that it did not follow the our current style. Of course that's only at work, my hobby projects are a different story all together: Many different styles from many different authors. Some even from past me.

No, I am one of them. And of course I hate jokes.

What kind of strange formatting might that be?

So if you get some source code to work on, you really go through it and add begin/end for every code block? I for one are definitely to lazy for that.

Yes, I do. When I test AIs I tend to ask things I already know so I can easily spot whether the answers are any good. In this case I had just updated the version detection in GExperts to support Delphi 13 so this was the first question that came into my mind.

That's a joke right? They gave the version the number 13 and you suppose they jump in the BDS version from 23 to 37 in order to avoid 13?

Autoformat has one huge advantage (apart from laziness, of course): It catches wrong indentations that suggest wrong code flows: if Condition then doX; doY; doOtherStuff;

And here we go: An installer for the Beta version of GExperts for Delphi 13: See the blog post.

I'm away at the moment and can't build an installer, but the current source code compiles with Delphi 13 and works with the 32 bit IDE.

On the sign up page it says you have to pay a year in advance. Is that wrong?

Given that for Claude Code you need a subscription that has to be paid for a year in advance I am not surprised.

My experience does indeed not include Claude Code. If you say its awesome, I believe you. I still severely doubt that it could take over my daily work, so I'm not worried. As for the wrong planet: I have had the nagging feeling for years that I am on the wrong planet. Usually when listening to Frankie goes to Hollywood's "Two Tribes"

They will be unemployed because AI will write all the code (or to rephrase: "Computers will program themselves") within a few years, as predicted already 30 years ago and time and time again afterwards. This time for real, we promise!

Currently I am mostly with the "I don't use AI" faction because it did not work for me when I tried it. But I will look into it again regularly and maybe I will actually find a use for it. Given that Delphi Praxis is a lot less active than it used to be - did all those people die? Have they switched to other programming languages? Or a different Forum? - I don't see much use for yet another sub forum. And apart from this: I am reading Delphi Praxis via the unread content filter, so it doesn't matter for me, where that unread content is.

Shared memory, a named pipe, sockets or even a file comes to mind.

Following up on I am trying to use the 64 bit dll from a 64 bit program that then executes a 32 bit program and controls it via stdin/stdout/stderr redirection. While this works fine (after I realized that I need to call Flush after each Write call otherwise it might be stuck in the 128 byte internal cache), I wonder how I am going to debug the 32 bit executable. I remember seeing a debugger option to also debug external executables started by the executable being debugged, but I have no idea whether that was in Delphi or some other programming environment I used years ago (Virtual Pascal?) and I can't find it in Delphi. Also I doubt that this would work for 64 bit programs executing 32 bit programs. Just to be clear: I have got a 64 bit Delphi program that starts a 32 bit Delhi program, sends input to it via stdin and receives output from it via stdout and stderr. I want to run that 32 bit Delphi program in the debugger. The only way I currently see would be to attach to that program after it has been executed. But that's rather cumbersome. Hm, maybe I could reverse this: Have the 32 bit programm run in the debugger and have that start the 64 bit program and communicate with it via stdin/out/err ...

Interesting idea ... [testing it] ... doesn't work though. The 64bit programm configured as host application doesn't get started at all. The debugger starts the 32bit program but without input/output redirection. Maybe this only works for DLLs and packages?

Wich will result in multiple expensive calls to GetLocationInfo...