dummzeuch

You said that error occurs when running the program. The first thing I'd do would be running it in the debugger, so I guess you did that too. Did it tell you where the problem is? Does it happen when reading the dfm from the resources?

I remember getting errors like this when adding components to a form and then deleting their name in the object inspector. This worked fine if the form contained other components of the same type which had a name, but failed with that error if it was the only one. That was with Delphi 5 though, so this might not apply to current Delphi versions. Back then we used this trick to reduce the number of fields for labels in the class declaration, because these were fully initialised in the designer and never accessed in the code, so we did not need the field. Edit: Thinking about it, it just occurred to me that the reason might be a missing entry in the uses list. Normally the IDE will add them for you, when you drop a component on a form. This may have failed for whatever reason.

One could also register a different program that simply calls bds.exe with the desired parameter.

Do that. It's lots of fun discovering all the new bugs in the IDE that creep up in that scenario. For bonus points make the 96dpi monitor our main monitor.

Ctrl+Arrow Keys or Shift+Arrow Keys. I forget which moves the control and which resizes it.

dzMdbViewer is a small tool I wrote, when I was stuck without a MS Access installation but needed to have a look into a .MDB file (and later .ACCDB file, if the Access Database Engine 2012 is installed). It can open these files and display a list of queries and tables stored in them as well as the data they contain. The new version doesn’t really add anything new to the tool. I updated the project to Delphi 10.2 ... https://blog.dummzeuch.de/2023/04/01/dzmdbviewer-1-0-4-released/

I'm not Uwe, but I have Delphi 6, 7 and 2006 to 11 installed on a physical machine in order to allow building GExperts for all those versions in one go. Yes, the length of the path variable can become a problem, but there are ways around this: 1. Don't install to c:\program files but use a shorter name (c:\delphi). 2. Replace the long names with the short names in the path 3. Use additional environment variables (e.g. Delphi6Path, Delphi7Path etc.) and only add those in the path (Rapid Environment Editor is a very useful tool for that) Works fine for me.

I just discovered that I had turned on "Background Compilation" (in Delphi 11, Tools -> Options -> IDE -> Compiling and Running) and that this was the cause for the Compile progress dialog not having the focus and not being centered on the IDE. Does anybody know how the IDE decides where to place this dialog? On my setup it's placed somewhere near the lower right of the main monitor (the IDE is on a secondary monitor on the left hand side). And if I move it, the IDE does not remember that position.

Quite possible.

The new GExperts version still supports all Delphi versions back to Delphi 6 (with the notable exception of Delphi 8 ) and even the Delphi 11 version is no longer in Beta state. There are even a few new features: * Fast add mode for the Uses Clause Manager is back. * Uses Clause Manager: Units “System” and “SysInit” and those already in the uses list are marked with strike through font. * New functionality to import the favourites from the Wuppdi Welcome Page * Form Hotkeys expert now allows assigning hotkeys. * For the Edit Path expert one can now select the default platform / configuration to edit * Grep no longer stops when it encounters an error (e.g. a file cannot be found or opened). * A non feature: The Goto Previous/Next Modifications editor experts were removed because they caused more trouble than they were worth. Several of those were contributed by GExperts users. Thanks a lot guys (and one girl). And of course a few bug fixes. Read on in the blog post

No, but that should be doable. Submit a feature request.

Ian and I have tried to track this problem down and at least succeeded in finding where it happens: It's in unit GX_CodeFormatterFormatter, method TCodeFormatterFormatter.doExecute. There is a while loop at the end of that method that is supposed to remove any additional CR/LF at the end of a unit: // remove empty lines from the end FTokenIdx := FTokens.Count - 1; while (FTokenIdx > 0) and TokenAtIs(FTokenIdx, rtLineFeed) do begin FTokens.Extract(FTokenIdx).Free; Dec(FTokenIdx); end; Somehow FTokenIdx (which is an integer field of that object) shows as a large negative number in the debugger, even though, as you can see, it is initialized properly. Then the while loop is entered even though the condition FTokenIdx > 0 is not met. Again that's according to the debugger. After executing that loop for a time it causes an access violation. That access violation is silently swallowed by an exception handler of one of the calling methods (yes, you can blame me for not writing a proper exception handler there) and the formatted code is not inserted into the edit buffer. Turning off optimization for that unit makes the issue disappear which seems to point to the Delphi 11 compiler as being the culprit here. Unfortunately I am not fluent enough with reading assembler code to find out what the actual problem is. And since it only ever happened once on my computer I can't really debug it and writing a bug report without any further info will probably pointless. If anybody with better knowledge in that area wants to step in, I would be grateful. For now, I have completely disabled optimization in Delphi 11 for that unit. That change was committed to revision #4003 and #4004

GExperts does not have a debugger. That dialog is from the "Filter Exception" expert. Just disable it and you will get the simpler exception dialog of the IDE back. But you will still get a dialog when your program raises an exception while you debug it. That's a functionality of the IDE's debugger. The Filter Exceptions expert allows you to specify which exceptions to ignore based on the exception type and the content of the message. And that's either global or specific to a project. It also allows you to ignore all exceptions in the current session.

Unit bla; interface type TServerParams = record Url: string; XCoord: Integer; YCoord: Integer; end; TServerParamsArr = array of TServerParams; const ServerParamsArr: TServerParamsArr = ( (Url: 'https://ows.terrestris.de/osm/service'; // <=== XCoord: 529850; YCoord: 5284850), (Url: 'https://geoportal.koblenz.de/geoserver/OEFFENTLICH/ows'; XCoord: (391000 + 408000) div 2; YCoord: (5571000 + 5586000) div 2) ); Given the code above, why do I get a compile error at the line marked with // <=== ? "E2003 Undeclared identifier: 'Url'" This is with Delphi 10.2, just in case that matters. edit: It compiles if I change TServerParamsArray: type TServerParamsArr = array[0..1] of TServerParams;

Has anybody ever implemented something like this in a Delphi program? Or did we all just sit there and tell everybody that this is not possible because the VCL is not thread safe? Sometimes it would be really nice to be able to create additional (VCL) controls in a background thread and then somehow pass these on to the main thread to add to a form. I never came around spending any time on this though.

Did you know that you can have multiple .dproj files referencing the same .dpr file? You could have one for each Delphi version your project needs to support: MyProg-2007.dproj, MyProg-XE2.dproj, MyProg-10-2.dproj and MyProg-11.dproj, all referencing MyProg.dpr.

That would be suicide not murder, because wrong answers kill only if the answer is accepted without any critical thought at all. (OK, it would probably kill about 90% of all people. Fair enough.)

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.