Uwe Raabe

No, they probably don't read this Forum. Not sure if they actually read their own one. They read Quality Portal, though

If you can still reproduce it, you should dispute the resolution with detailed steps to reproduce.

A for-in-loop doesn't guarantee some order. Any order seen just relies on the implementation and may be subject to change in the future. (Latest when we compile for quantum computers) I remember someone asking for a backwards for-in-loop, but that request is based on a false assumption in the first place.

Perfect! Then it is actually a regression, which pushes the probability of a timely fix. Now we only need that regression bug report. As the report claims to be fixed in 10.1 Berlin, can someone check if it was introduced in 10.2 Tokyo or one of its updates or in 10.3 Rio?

It is my experience that issues with the installation are usually targeted quickly. I know what you mean, but if we stop filing bug reports to notify them about existing stuff not working they will have more time to add unwanted features. Even if the chances for a filed bug to be fixed are pretty low, they are still higher than those for a bug not filed at all. After all 10.3.1 fixes more than 150 reported bugs, which were probably still not fixed if they weren't be reported in the first place.

What about filing a bug report?

Build 2289 available: fix: missing images in Entity Insight toolbar fix: scaling problem in About screen fix: problem sending email from support link

I am happy with a certificate from ksoftware since a couple of years now.

Seems like this is a relic of former Windows versions. I will skip that check.

It is not the wrong method: ShellExecute(0,'open',PChar(Link + S),nil,nil, SW_SHOWNORMAL); but rather a missing registry entry: if reg.OpenKeyReadOnly('HKEY_CLASSES_ROOT\mailto\shell\open\command') then begin Result := (reg.ReadString('') > ''); reg.CloseKey; end;

Let me guess: Your DPI settings are at 125%? The version label is positioned on top of the image. The scaling moves the label, but leaves the image as is.

Perhaps people tend to prefer talking about things that don't work.

I got it working now! First I changed the path setting back to the old value (on my machine it is "c:\Users\Uwe\AppData\Roaming\Parnassus OU\Common"). Then I copied the new DLL into that folder and renamed it to ParnassusCoreEditor_XRio.dll It seems that the DLL loader logic first looks for the "XRio" DLL and has a fallback to the original name. That way the different DLLs can coexist in the same folder and the XRio renaming allows for future version, too.

Would it help to change the registry setting to "$(BDS)\\Experts" and make sure that the correct DLLs reside in the proper places?

The road map mentions 10.3.x, so I guess we can expect at least a 10.3.2 in the next months.

If you want to keep your settings you should answer NO. The question is about removing the settings.

Thanks for this blog post. Instead of just ranting about GetIt you start taking real actions. I appreciate that very much. Some ideas came already to my mind while reading, but I need to think a bit about them first. Regarding the design time components, I had tried to get this covered with my Package Magician mentioned in this blog post: There Can Only Be One – At a Time! While it works in the majority of cases, it heavily relies on the packages to be unloaded cleanly - sometimes not even standard Delphi packages can guarantee that. Unfortunately some of the big players in the package market seem to ignore that their packages my be unloaded and reloaded in the IDE. If you are interested I am open to contribute the code to your project. BTW, the link to the GitHub repository is broken.

The more subtle cases are when code requires to switch that off to work properly and someone compiles with that switch on: if (something <> nil) and (something.someinstanceaccess) then

The compiler switch makes it evaluate either all parts, which is perfectly valid in the first place, or evaluates from left to right, which is exactly what we want when writing Result := Condition or Result; So whatever that switch is, Condition is evaluated first.

Make the function a static class function of a record: type TMyPassHandler = record public class function Pass<T:record>(const Value: T): Boolean; static; end; class function TMyPassHandler.Pass<T>(const Value: T): Boolean; begin Result := False; { do whatever is needed } end; Most of the time the compiler should be able to infer the proper type, so a call would look like: TMyPassHandler.Pass(myRec);

That is a valid approach for the Result := Condition part, but in the original example Result is a string while Condition is a Boolean;

if Condition then Result := True; Result := Condition; These are not the same! What if Result is true before that line in the first and in the second case?

Write your own procedure: procedure MPC(var Result: string; const Value: string; Condition: Boolean); // MPC stands for Mike's Preferenced Condition begin if Condition then Result := Value; end; ... // call MPC(Result, 'N', Property = 'A'); You can even make it a function, but then you must provide a value for the false condition, too.

Lars also showed a valid approach in his blog post. There is nothing wrong with using variables. As always you have to know what you do.