Uwe Raabe

Perhaps I am a bit too optimistic, but I do have hope that some library providers will adhere to a reasonable standard whenever it will be established. If this Package Manager forces some requirements on any package/library to be supported, that might help to canalize the chaos diversity currently out there.

Only virtually 🚯

I am inclined to see this as the compiler barfing at the language designer who came up with this ambiguous set/array thing in the first place.

Good reading on this subject: Are there any downsides to using UPX to compress a Windows executable?

type TInfoType = (itProject, itContacts, itWorker, itWorkers); const cInfoTypeNodeNames: array[TInfoType] of string = ('project', 'contacts_info', 'WRK', 'WRKS'); begin Writeln(cInfoTypeNodeNames[1]); // will not compile Writeln(cInfoTypeNodeNames[itContacts]); // will compile end.

Not quite. You cannot use an integer index for such an array, only the declared index type.

Not in the Action dialog itself, but in the script. The iterator sets a variable CompilerVersion in OnBeforeEachIteration: CompilerVersion = Delphi10Seattle + Iteration - 1; and the compiler action sets the Action property in the OnBeforeAction script: Action.CompilerVersion = CompilerVersion;

The docs say about static arrays: So any ordinal type (which includes enumerations) are valid as array index. That has been this way since the invention of Pascal.

Not for a build server running a FinalBuilder project with an iterator over the required compiler versions. Compiling in own VMs for each compiler version would be a nightmare. Let alone having to run all those VMs synchronously during the build process. F.i. building MMX Code Explorer for the current 4 compilers, creating the setup, signing and upload is done in about 45 seconds. I doubt that would be possible if I would compile on 4 different VMs. Looking at ProjectMagician, which targets XE3 and up (10 compilers involved) currently needs about 30 seconds to build. Hard to achieve that with 10 separate VMs without significantly extending the build server hardware. To be fair, all these IDE installations are only for building, not for working interactively. and currently I have no mobile projects to be build on that system. Aren't the paths to those libraries and frameworks set individually for each IDE Version? In that case FinalBuilder takes care to adjust the environment accordingly when executing the compile action. What are your specific problems with those?

In Editor Options - Display disable Show Navigation Toolbar

In the comments Marco suggested to use multiple packages.

Well, that is what giving number in the enum declaration is, too, The ADD example was just a little joke, because the numbers given nicely add up by coincidence.

Yes, definitely! It is just quite some work to do.

Exactly! Anyway, looking into the source is more reliable and usually also faster.

Lately I often use helpers to map those enumerations to their ordinal values. type TEnum = (plough, foo, bar, wtf); TEnumHelper = record helper for TEnum private const FMap: array[TEnum] of Integer = (5, 9, 14, 1000); function GetAsInteger: Integer; procedure SetAsInteger(const Value: Integer); public property AsInteger: Integer read GetAsInteger write SetAsInteger; end; function TEnumHelper.GetAsInteger: Integer; begin Result := FMap[Self]; end; procedure TEnumHelper.SetAsInteger(const Value: Integer); var idx: TEnum; begin for idx := Low(FMap) to High(FMap) do begin if FMap[idx] = Value then begin Self := idx; Exit; end; end; raise ERangeError.CreateFmt('invalid integer for TEnum: %d', [Value]); end; This is pretty simple to use: var enum: TEnum; begin enum.AsInteger := plough.AsInteger + foo.AsInteger; if enum = bar then begin ShowMessage('Hooray!'); end else begin ShowMessage(wtf.AsInteger.ToString); end; end;

As my build machine contains all Delphi versions since XE, I make a simple search for the affected source file and text. I have created a specific search configuration in Total Commander with all the sources folders of the different Delphi installations. That way I only need to specify the file name/pattern and the search text and the time for the search is negligible. This way I can usually figure out which version introduced the change in less than a few seconds. In case the change happened before XE I would have to fire up the old build VM that goes back to Delphi 5, but I rarely have a need for that.

This is actually an error in the Navigation Toolbar Keybindings that are integrated in the IDE since Delphi 10 Seattle. It happens when these bindings are not the first in the bindings queue. This error does exist for quite a while when MMX and Castalia are installed side by side in the IDE. As a workaround, make sure that MMX Code Explorer is uninstalled. Start the IDE, disable the Navigation Toolbar Keybindings and install MMX again. Another approach avoiding the uninstall/install cycle requires a bit of fiddling around with the registry: Open the registry and locate the appropriate BDS key. Open Editor -> Options -> Known Editor Enhancements -> MMX.CodeExplorer and set the Enabled value to 0. That will prohibit the MMX keybindings to be registered. Now the IDE should start. When the IDE is running go to Tools -> Options -> User Interface -> Editor Options -> Key Mappings. In the list Enhancement Modules move MMX Code Explorer to the last (bottom) position and enable it again. Hope that helps. The next release will have a fix that assures MMX not overtaking the Navigation Toolbar Keybindings in the first place.

Perhaps the crucial thing is the 100% on the primary monitor? I remember to have seen problems on other systems with a different setting.

At least that is what I see on my system (with Delphi 10.2.3 and 10.3.1). The IDE always designs with 96 dpi even on a monitor with 144 or 192 dpi. I have one 27" 4k Monitor set to either 150% or 200% and two 24" Full-HD ones (primary on 100%). All forms are stored the same (96 dpi) whether designed on any monitor.

As long as the IDE is fully suitable at higher DPI settings, I tend to overwrite the DPI awareness in the shortcut properties to "System (Enhanced)". Although the icons are still a bit blurry, the text is pretty clear. This way the IDE Form Designer will still detect 96 dpi for a DFM internally even when run on a 4K display set to a higher DPI value.

Yes, that is the way it has to be done.

DesignIntf and DesignEditors. BTW, the ImageIndexMapper makes use of these to replace the ImageIndex properties with the ImageName ones.

I do most of my development like that (my Desktop and Taskbar are plastered with Delphi icons). Some IDEs have their libraries set to English language while others are set to German. If you work for different customers you don't want to end up installing a plethora of components into your IDE to cover all those different projects. Often I have to stick with a specific version of components due to customer demand. Have two customers with disjunct demands and you know what @Vincent Parrett is talking about. That said, I guess I belong to the dedicated target audience for such a tool!

The description in that report are not really detailed steps. Even the short hint in one comment is not what I call detailed steps. A good hint is: If it cannot be reproduced it is most likely that the steps are either incomplete or not precise enough. There is almost no day where I don't get a bug report that goes: Do X and you get Y instead of Z! (sometimes they actually mention the expected). Then when I do X as described I usually get Z and not Y. (Just answering one of these now)

I showed this during EKON last year. Unfortunately I couldn't find the time working on it again. It heavily lacks documentation, but perhaps it can serve as a start. https://bitbucket.org/uweraabe/codecoveragemagician