santiago

I was able to figure out the correct download link (by looking at the first alpha download link. 🙂 The correct link is: https://download.dummzeuch.de/GExperts/1.3.19_2021-11-26_for_Delphi11-Patch2/GXRS11_1.3.19_ALPHA2_experimental-twm_2021-11-26.exe

Hi there, I have the following interface and two simple classes. A base class and a derived class (super class). IMyInterface = interface ['{34408757-240F-4B63-A1CA-4B1FC3BF5072}'] procedure DoesNothing; end; TMyBaseClass = class(TInterfacedObject, IMyInterface) procedure DoesNothing; end; TMyClass = class(TMyBaseClass) end; and wrote the following test method. I would like to understand why we get the EAccessViolation with the hard (unsafe) cast. procedure TMyDebugUnitTestCase.Test_MyTest1; var MyObj1: IMyInterface; MyObj2: IMyInterface; MyObj3: IMyInterface; Obj: IInterface; begin Obj := TMyClass.Create; CheckTrue(Supports(Obj, IMyInterface, MyObj1)); MyObj1.DoesNothing; MyObj2 := Obj as IMyInterface; CheckNotNull(MyObj2); MyObj2.DoesNothing; MyObj3 := IMyInterface(Obj); CheckNotNull(MyObj3); MyObj3.DoesNothing; // EAccessViolation -> Access violation at address 00000001 in module 'CoreTests.exe'. Read of address 00000001 end; The problem also happens if I declare the derived class as follows: TMyClass = class(TMyBaseClass, IMyInterface) end; Is it necessary to explicitly list interfaces already declared in base classes in the super class? To me this just seems redundant. Am I correct here? I have heard from other developers saying that this is necessary, but being unsure as to why, Thank you!

Wow Remy! Thank you for such a detailed answer. 🙂 It is now crystal clear to me. I never use those types of casts with interfaced objects, but since I had seen them since day 1 when I got started with Delphi I assumed it was legit. And oddly enough they have been working fine for many years!! That is why I got so confused when I removed a redundant interface declaration and suddenly it stopped working. In the meantime I have already replaced several of the unsafe casts with safe casts.

Great! Thank you! Understood now. 🙂 This means that we need to change all the locations in our legacy code that perform such casts. I am just surprised as to why we have not had any problems before that. They have been in there for ages.... And some are called rather frequently.

Am sorry David, but I don't quite follow. Variable Obj is an instance of TMyClass and is declared as IInterface. TMyClass does implement IMyInterface. So it should be a valid cast. However when we call a method the access violation occurs. We have some legacy source code that does such things: IWhatever(SomeVariable).AMethod; It has been running fine for years. The other day it broke because I removed an Interface declaration from a derived class, since the interface was already implemented in a base class. So basically we had: TDerivedClass = class(TBaseClass, ISomeInterface1, ISomeInterface2, ISomeInterface3) and I changed it to: TDerivedClass = class(TBaseClass, ISomeInterface2) because TBaseClass already implements ISomeInterface1 and ISomeInterface3. And suddenly ISomeInterface1(AVariable).SomeMethod; resulted in an access violation. Thank you!

Thank you Kas. What do you mean exactly by "managed types"? If I understand correctly it is not safe to use such casts with TInterfacedObjects that implement many interfaces. What puzzles me though is that in our source code we have several locations where we do precisely that: IWhatever(SomeVariable).AMethod; This has been used in our software for many years, way before I got started with Delphi. The other day I removed a redundant interface declaration from a derived class. The interface was already listed and implemented in a base class. And all of the sudden some tests started failing. The reason was that such unsafe casts which had been working properly so far, no longer did. Am I correct in saying that we must always use Supports or as when dealing with TInterfacedObjects and unsafe casts should be avoided unless you really know what you are doing?

Marco, do you have an estimate when this patch will become available? I would like to give 10.4.1 another try. Currently we are still on 10.3.3.

I use 10.3.3 with IDE Fix Pack and have not had that issue to such an extent. It has happened though that Code Insight has stopped working. If I remember correctly it works after a while or just by restarting the IDE. These incidents have been very few and far between, so for me it has not been much of an issue. I will pay more attention next time it happens. But I do use 10.3.3 + IDE Fix Pack on a daily basis on a very big project.

I cleaned up one project (40K lines of code, ca. 80 units, depends on 21 projects). I cleared the 'Unit Scope Names' from the Project Options to be empty. I had to fix many compile errors (in 47 units) by using the full scoped name (e.g: System.SysUtils, instead of just SysUtils). Delphi Rio 10.3.3 (WITH IDEFixPack) Before the changes this project compiled in ca. 8 seconds After the changes it improved slightly to: ca. 7.7 seconds Delphi 10.4.1 Before the changes: ca. 11.5 seconds. After the changes: 8.7 seconds. Delphi Rio 10.3.3 (WITHOUT IDEFixPack) Before the changes: 18.1 seconds After the changes: 14.5 seconds Ideally you should always use the fully scoped names. I would have never had thought that this would have such an impact on compile time...

Now I follow you 🙂 This is very actually very interesting. This is how the 'Unit Scope Names' settings look for our projects. If I understand correctly, the fewer unit scopes that are defined here, the faster the project will compile. Correct? I am certain we don't need all those entries. I guess no one has ever looked into it until now. Anyhow, I will try to eliminate the need for using Unit Scope Names.

This is how it looks like for me (Delphi Rio 10.3.3). Unit Aliases is something I have never needed to use so far.

This is how I disabled it (Might be wrong, as I did not find any documentation on this): SET IDEFixPack.DisabledPackages=Compiler.UnitScopeNames In our case it had no impact.

I did some quick tests with our project. 2.1 mio lines of code. (1 group project, consisting of 24 projects). 10.3.3 =1.08 min Disabling the UnitFindByAlias patch, makes it 20 seconds slower. This is similar to the build time using 10.4.1 In the Delphi Compiler Options, UnitAlias is empty.

How do you activate/deactivate individual patches? -- EDIT -- nevermind. I see you attached a screenshot on how to do it. Thank you!

Lets say over 100 Units.

Same here. Still on Rio... Does (can) any one actually use 10.4.1 for large desktop projects?

The way the Ctrl+Tab shortcut works in the Delphi IDE was always very inconvenient for me. Actually the Delphi IDE is the only program I can think of that does not navigate open documents based on the order in which they were last activated but instead on the order in which the tabs are arranged in the editor. So if you are were working in DocumentPrevious and switch to DocumentNext, I am used to going back to DocumentPrevious by hitting Ctrl+Tab. But in the Delphi you will navigate to whatever document is on the right side of DocumentNext. This has always been very annoying for me. Anyhow I made plugin that makes Ctrl+Tab behave to what I am used to from other programs, like Visual Studio for example. Might be of use for some. https://github.com/santiagoIT/DelphiCtrlTab Precompiled binaries are available for Delphi Seattle, Rio and Sydney.

I was not even aware of the 'Buffer List'. But yes indeed, the 'Buffer List' provides the same functionality. But is not as convenient to use. However, if you are used to the way the Ctrl+Tab shortcut works and behaves in different development IDE's you will not be very happy with the 'Buffer List'. I would have still developed the Ctrl+Tab plugin if I had been aware of the 'Buffer List' before.

@Mike Torrettinni Am happy the plugin is of use to you. Great suggestion 🙂 Modified files are now marked with an asterisk. I think that works well enough.

Hello, In DUnit we make heavy use of dynamic Tests. For example, we have a test that loads a file from disk and performs some actions. All of the files are kept in a directory. The TestSuite is built at runtime by searching for all relevant files. For each file a Test is displayed in the Test Runner. This is very handy when you want to test/debug just one specific file. The alternative would be to have a single Test, such as TestAllFilesOfTypeXx... But then it is not straightforward at all to troubleshoot a specific case.

@Vincent Parrett Great! I took a quick look and it seems to be exactly what I was needing. I hope I can get back to working on this soon. Thx!

Hello @Stompie, unfortunately I have not been able to look further into this. Let me know if you get that to work. Eventually, at some point in time I will have to pick this up.

Check your project options and make sure that the 'Generate console application' is unchecked.

Issue has been solved. 🙂

Definitely not intentional. Will have a look. Thx for reporting. 🙂