dummzeuch

You seem to have had merge conflicts. Your second try with a fresh check out did not compile because you compiled it with the release configuration. With the debug config it would have compiled. You need to use the debug config because otherwise no messages will be written to the log. (I have also just committed revision #3991 which fixes the compile error in release mode.)

I have just committed revision #3989 containing additional debug messages that should help tracking down the reason for the failure. Please update your sources and compile a new DLL in debug mode(!). Then, the next time formatting failed, check the topmost entries in the GExperts debug window (in the icon tray). And copy them to the bug report. Please start with the line saying TeCodeFormatterExpert.Execute and include all lines above that start with the string "GXFormatter:".

If you haven't already, please file a bug report on sourceforge. Make sure to include what you already tried and also the source code changes you used for that. I look into those bug reports regularly and have recently fixed quite a lot of them. But I tend to forget about bugs only reported here.

Isn't C++ Builder also capable of compiling and using Delphi code? If I remember correctly it uses the VCL without any modifications. But I don't know specifics, I only ever wrote one C++ Builder program.

The "Evaluate / Modify" window (which you get with Ctrl+F7) has a button "Inspect" which for objects opens a "Debug Inspector" window. In my Delphi 10.2 installation (but probably other versions too) this window always opens on the left hand side of the monitor, right below the menu. I can move it around, even dock it somewhere, but I found no way to persist this position. Saving the current desktop layout, closing the window and reopening brings it back to the same starting position, not where it was when I saved the desktop. Restoring the desktop does not move this window. If it was docked, restoring the desktop undocks it. Similarly there seems to be no way to persist the windows opened by the TActionList, TMenuBar and TPopupMenu property editors. Is it just me being stupid or is there no way to save / restore those window's positions (and preferable sizes too)?

You are interpreting interesting things into what I wrote. But you and I have a history of talking at cross purposes (that's DeepL's translation of "aneinander vorbeireden") with each other, so I was expecting something like this.

They may not care about the technicalities, but they do care about the time it takes to develop the software, and that depends a lot on turnaround times. And all else being equal(*1), a single-pass compiler is inherently faster than a multi-pass compiler. (*1: Of course, a badly written single-pass compiler could still be slower than a well-written multi-pass compiler).

For me it's mostly annoying, because I have no idea what could cause this. Maybe the formatter itself works but writing the formatted code back to the edit buffer doesn't? I'm not sure how good the error handling is there. I haven't looked at this code for ages.

It shouldn't matter whether you run that batch file as admin or not. It only adds entries to HKCU in the registry.

Source/Formatter/GX_CodeFormatterExpert.pas Or even earlier: Source/Formatter/GX_eCodeFormatter.pas

Could you please add e.g. a messagebox call to the expert's execute method and check whether it shows that message?

What exactly do you mean by ? Is the menu entry disabled? Is it enabled but the formatter does nothing? Do you get an error message? Any message at all? I simply can't imagine what this tool might do that prevents the GExperts formatter from working. Maybe setting the editor buffer to read only? But then you wouldn't be able to edit your code.

Thanks for the confirmation. I'm only now updating my Delphi installation to 11.3. And also thanks for the donation.

Did you use the (old) installer? If yes, compiling and replacing the DLL will probably work. I haven't installed 11.3 yet. The download has finished thought.

They must be rather desperate.

It most certainly is. I've never been surprised by how cheap a product is, when I had to ask for a price. On the other hand it's sometimes worth to ask for a discount when the price is published.

Fixed. I forgot to call InitDpiScaler in the constructor.

Just so nobody gets disappointed: That expert is only available for Delphi 2009 and later. Delphi 2007 and older are lacking the OTAPI support for it. Here is the original blog post.

If I remember correctly there is a splitter between the edit memo and the inherited list. But I think the position isn't saved (yet). Is that screenshot from the Delphi 11 version? On a monitor with > 100% scaling?

I call GExperts experimental because I don't want anybody thinking that it has been thoroughly tested. Way back, when there actually were several people working on it and many more testing it, there were stable releases. Today I'm the only developer (apart from some very few contributions from others, for which I'm very grateful) and my time is very limited. I simply can't test with all Delphi versions, so only those that I use regularly (currently 2007, 10.2 and some XE2) could be called kind of stable.

If I hadn't seen this post before reading the previous one, I wouldn't have recognised the sarcasm there either.

That's no alpha symbol in your template, that's a lower case sigma. (Or it's the forum software that broke it.) Care to share those templates?

It's DxGettext. If I disable translations, renaming the file works with SysUtils.RenameFile, with the Explorer and also with the Rename command. Man wird alt wie 'ne Kuh und lernt immer noch dazu.

That's really odd. I just tried it because I couldn't believe it: VCL-Application with a form and a button b_Rename and the following code: procedure TRenameExeTest.b_RenameClick(Sender: TObject); begin RenameFile(Application.ExeName, Application.ExeName + '.old'); end; Works as expected or rather as not expected by me. Now I wonder why the Explorer and the Rename command cannot do this. Interestingly, after the program has renamed its own executable, it's possible to rename it back using the Explorer. And even more strange: This program can be renamed with the Explorer while its running. The one I tried first (last post with the screenshot) could not. I wonder what causes this. Maybe it's DxGettext that keeps the file open because it accesses the linked in translations? Or JclDebug accessing the jdbg information in the file?