Berocoder

Yes, I corrected spelling. Anyway even if that guy is in charge of Delphi. I doubt he is reading this or other forums that people complaining about how things are handled. I think it is better to try do something concrete about it. I made an empty document here https://docs.google.com/document/d/1uxa9u09hE7tLEMau1Ld9OELJoTCTvxEyst6JY3yevzo/edit?usp=sharing Anyone can add and edit the ideas. What changes do we want from Embarcadero ?

I just wonder why not people using VmWare or similar virtualisation for Delphi? Then you never have to move to a new computer and this problem is gone. A VM have also other advantages.

Yes our big legacy codebase of around 4 mloc take one minute to build. And we don't build from dcu's so that would be a nice improvement.

I recently switched from Win7 and D2007 to Win10 and Delphi 10.1 Berlin. I use VmWare workstation VMs. Many new things to explore. But I noticed one thing. To open projects and forms is much slower now. I Googled it and found an older post claiming that rename livebinding bpl could improve speed. I am sure we will never use livebinding in our code. Any comments how to improve speed i the IDE?

I cannot find a link to create new account. Luckily I already have one...

I found http://docwiki.embarcadero.com/RADStudio/XE2/en/Classes_and_Objects#Forward_Declarations_and_Mutually_Dependent_Classes I try to create 2 classes. Each of those have a reference to the other. unit TestA; interface uses TestB; type // TTestB = class; TTestA = class public M_TestB: TTestB; end; implementation end. unit TestB; interface uses TestA; type TTestB = class M_TestA: TTestA; end; implementation end. Got [DCC Error] TestA.pas(6): F2047 Circular unit reference to 'TestA' What is wrong here ? If I remove TestB from uses and add TTestB = class; I got this instead [DCC Error] TestA.pas(9): E2086 Type 'TTestB' is not yet completely defined

This is just an experiment, a proof of concept. The real model have about 460 classes. The relations between them can be - One to one - One to many - Many to many. In this case a new association class is used. So in reality this is two relations. Many to one association class. one (from association class ) to many. In some cases the relation is navigable only in one direction. In some cases in both. In some cases a class have a relation to itself. That's the situation now and it works. I just want to remove usage of inc-files for storing code to make development easier. Disadvantages with inc-files - Codeinsight in IDE don't work - Many tools to analyze source don't handle inc-files well. - IDE (bds.exe) tends to lock inc-files sometimes, This is random. So restart is required before project can be compiled. In spite of that we used the current solutions in fifteen years.

Make a small testcase to demo the bug so others can confirm it or point to error in code.

I investigated more now and unfortunately I don't get this as I want Declaration of TestAbstractB happen in unit TestA. I want to move it to unit TestB as there can be many classes that have references to that class. But then again I got [DCC Error] TestA.pas(6): F2047 Circular unit reference to 'TestA' as TestB have a reference to TestA. So I don't know. Using interfaces need huge changes in framework and insert Abstract classes don't work as I expected. So maybe we continue with original implementation with inc-files 🙂 [EDIT] Simple solution to that was to store abstract declarations in own unit. So far so good 🙂

Hm ok. Thanks for the advice 🙂

Btw, that means I have to typecast every access to the concrete class ?

The code I posted here is heavily simplified. I agree that cyclic dependencies is not good. But basically one class is one table in database for most cases. There is also some transient classes that reside only in memory. So this is about relations between classes. Many times I want to navigate both from class A to B and from B to A. For example class TPerson have a relation to TAddress. So to find the address: vAddress := aPerson.Address,AsString:; But to find the person who live at an address make also sense vName := aAddress.Person.AsString; So one way to break dependency is to use interface. But there are many questions left to work with as the whole framework now assume direct access. So I want to work with IAddress and IPerson instead of TAddress and TPerson. But at some point I must deal with the concrete class anyway. About abstract classes, that is a good point. But what happens with the inheritance chain. TObject TBoldMemoryManagedObject // inherited in framework TBoldFlaggedObject // inherited in framework TBoldSubscribableObject // inherited in framework TBoldElement // inherited in framework TBoldDomainElement // inherited in framework TBoldMember // inherited in framework TBoldObject // inherited in framework TBusinessClassesRoot // Dummy TAmObject // basic info TAmStateObject // have states TPerson // concrete class This is the inheritance tree for TPerson. Is it even possible to use a TAbstractPerson somewhere ?

See https://stackoverflow.com/questions/53980032/how-to-avoid-using-inc-files-for-code-with-delphi for more details. But I now believe that interfaces is the correct solutions instead of direct references between the classes.

Ok so basically it is not possible to have direct references in both directions between two classes if they are stored in separate units...

Seems like links are not clickable https://github.com/mikerabat/mrmath http://www.mrsoft.org/home/downloads.html

Look at https://stackoverflow.com/questions/4652958/is-there-a-way-to-log-every-gui-event-in-delphi. It try to intercept all events. Advantage is that you need much less modifications of your code. Disadvantage is that not all your methods is logged.

New book next year that could be interesting. http://interpreter.analogmachine.org/

How can I get updates for new posts in this forum on the phone? With the old Google+ forum I used the Google app for that.