PeaShooter_OMO

Pointers should not be avoided and I highly suggest programmers should learn to use them properly and embrace them. They can make life so much easier.

At home I am still on a very old version of Delphi. I hardly ever make money from Delphi privately and most utilities I create I give out for free to those I create it for. My best friend does make some money but not even enough to surpass the limitation of CE. He also is still on an old version of Delphi. There are only two reasons why I have not gone over to the CE and I reckon many might see them as lame reasons; 1. The limited Source Code. I constantly go into the source code to see what is being done and I alwys go into the source code the moment I come across some strange behaviour in my applications that I do not have an explanation for. I want access to source code. 2. The irritating thing of having to reinstall CE after a year and being forced to use the latest CE to do that with. Like most will testify to, reinstalling is a pain. I created a custom installer for my Delphi installation. It installs Delphi, copies all required 3rd party libraries and sets up multiple registry entries. So I just run it and sit back and as soon as it is finished I am ready to go without having to do any additional setup. It makes my life so easy but it is linked to the version of Delphi it is installing. Yes, I know its a lame excuse. But apart from that I believe CE to be quite valuable. Considering that we are part of an ecosystem that uses an IDE that by reason of its smaller community is being forced to be charged for to keep existing I would say that CE will help a lot. I have to pay for my lunch and I do not blame others that have to make a living too. Anybody that uses Delphi and complains about the price of it and at the same time complains about CE needs to remember that free hardly ever is completely free and time is money and quality takes time. That person would probably not use Delphi if they believed other IDEs/tools to be better in anyway so if you like it pay for it or use CE. We all know the issues with the versions we have and we all know it is expensive but most of us like using Delphi ( I assume) and I surely do not wan't to use another tool.

I removed the standard Indy from Delphi 11. I used the Clean_Alexandria.cmd batch file and also went through all files and folders on my PC to remove any Indy*.bpl, dclIndy*.bpl, Id*.dcu, Id*.pas files that may exist. I removed all previous Library and Browsing Paths. I then downloaded Indy from the Git repository (Commit: b994412). I opened the project group for Delphi 11 (280) and changed each package's "Unit Output Directory" to (one for each, related to its functionality - System, Core, Protocols): ..\..\..\Delphi 11\DCU\System\$(Platform)\$(Config) or ..\..\..\Delphi 11\DCU\Core\$(Platform)\$(Config) or ..\..\..\Delphi 11\DCU\Protocols\$(Platform)\$(Config) I made sure to enable "Explicit Rebuild" for all packages. I made sure the DPK files did not get corrupted and that they looked the same as the originals after changing project options. I did also try with the {$IMPLICITBUILD OFF} directive. I then built and added Library paths, Browsing Paths and Debug DCU paths for Win32 and Win64 to Delph Options: Debug DCU: c:\<..........>\Delphi 11\DCU\System\$(Platform)\Debug c:\<..........>\Delphi 11\DCU\Core\$(Platform)\Debug c:\<..........>\Delphi 11\DCU\Protocols\$(Platform)\Debug Library: c:\<..........>\Delphi 11\DCU\System\$(Platform)\Release c:\<..........>\Delphi 11\DCU\Core\$(Platform)\Release c:\<..........>\Delphi 11\DCU\Protocols\$(Platform)\Release Browsing: c:\<..........>\Source\System c:\<..........>\Source\Core c:\<..........>\Source\Protocols I obviously copied all *.pas and *.inc files to the related Source folders I added to Browsing paths. I also copied all the *.res files to the related DCU folders I outputted the units to just for incase. When I create a blank project and add a IdTCPServer to the form and run it works fine. The moment I enable "Use Debug .DCUs" and try to build it gives the F2051 error: [dcc32 Fatal Error] Project11.dpr(5): F2051 Unit IdThread was compiled with a different version of IdGlobal.IdDisposeAndNil I am sure I am missing something here. I have upgraded Indy many times before in Delphi XE3 but this one stumps me.

Point #1 Before I started with the upgrade I seached for all Indy related files and and I searched all my drives. Before each Indy build I would also go and delete all DCUs, DCPs and BPLs. Point #2 You made me think about what was happening so this weekend I realized that because I use a Build Group and each project in the Project group first builds the Debug then the Release I realized that because after each build per $(Config) the DCPs and BPLs are replaced. I am not sure which carries the signatures for the units. So obviously what would happen is that for instance IndySystem's DEBUG gets build then its RELEASE. So when it is IndyCore's turn its DEBUG gets build but references IndySystem's RELEASE DCP/BPL. Thats when the problem starts. So now I first finish building all the DEBUGS for all the projects first then I build the RELEASES for them and it works perfectly. Thanks for your help and thanks for injecting some perspective here to guide me to the answer.

@Dalija Prasnikar and @David Heffernan thank you for the answers.

Which route would you then go if you could/wanted to re-write?

@David Heffernan May I assume your company is also "stuck" with Delphi (not sure if that is the correct question, though). I always wondered which IDE you consider to be great and which one you would migrate to if you had to re-write your company's flagship software.

I like Jetbrains, at least for the little I worked on it. They are really pumping it. Do you have a project on it that is bigger than your largest Delphi project? For which language? If so, how does that IDE behave with that project?

Are BPLs and/or DCPs constructed based on which build config is selected? I have an issue where the outcome is different based on the build order of the Build Configs. In this case when I build Indy the order in which I build (Debug then Release or Release then Debug) it will affect where a a test project using Indy will fail; Release or Debug: Error F2051 - Compiled with different version of IdDisposeAndNil

Debug Builds then Release Builds If I build the Indy projects' Debug Builds first then the Release Builds then the test project will fail to build on its Debug Build with "Use Debug .DCUs" is enabled. Release Builds then Debug Builds If I build the Indy projects' Release Builds first then the Debug Builds then the test project will fail to build on its Release Build Inline Directive If I remove the inline directive from IdGlobal.IdDisposeAndNil then the test project will build and run successfully on both of its Debug and Release builds and also stepping into the code will work if "Use Debug .DCUs" is enabled. The inline directive is used in many places in the code and I do not want to remove them just to get this working. How can this be fixed then? Surely there is a way because the standard Indy that is shipped with Delphi works 100%. I cannot just go back to the standard Indy with Delphi because I need to check if a newer release of Indy has fixed certain bugs.

What is the solution to this if one would like to keep LivePreview? Can the packages be rebuilt? (Happened to me on Delphi 11)

TMethod in System is a record with a Code and Data pointer. Would it be possible to browse Delphi's source code to find any source code to verify Event types' structure or is the knowledge about Event types found in documentaion only?

Did you search for the error on the web? SetMethodProp needs TMethod which can be setup.... Have a look at How to set a procedure (function) to an event in delphi 7?

What are the symptoms? Errors?

What is inside SetDefaultEventHandlerIfEventExists2?

I was wondering the same thing. Is it not automatically considered to be MDI the moment you have resizable/movable forms as child windows inside a "main" form? For instance programs like Photoshop have multiple documents but the moment you "undock" it from the Tab interface it becomes an uncoupled form outside the main form. Firefox acts similarly but an uncoupled document becomes another instance of Firefox. We made programs that have multiple forms inside the main form but they never were "documents" but rather functionality forms and they never were movable/sizable and had no caption bars. I suppose I digress from the topic here.

How would this code behave differently between Debug and Release? Do both compile?

Did the recruiter provide any links to a job spec? I regularly get "recuiters" messaging me in Linkedin talking about a great job but as soon as I ask for a proper job spec they ghost me.

Stack Overflow is and has always been valuable to me and I assume its moderators have a great hand in that. I agree that it can happen that a moderator is harsh sometimes even towards a newcomer to the site. I personally prefer strict moderation. It is wise to just adapt to its style. Delphi developers on SO can be glad to have contributors like David, Remy, Andreas, Rob, Ken, Mason, Uwe, etc on there as well as here.

Why? Do you also expect to move all your furniture into the blueprint of a house? No, you would use the house's blueprint to build one or multiple instances of an actual house, then you would move into one of them. The class declaration and all its related code is the blueprint and the instance is the actual house. You design a class and then when you need to do something with that class you would create an instance of it and use it. Remember to at least free/destroy that instance. You are the only one living in it and nobody else will buy your vacant spot and vacant spots lead to bad neighbourhoods (memory leaks). There are ways to do the above but I don't want to send you down a dark hole. Get to know Delphi and basic Objects/Classes a bit better first and learn to manage the objects properly first. About the game and its development; Whether you were recruited to do development on this project or whether you got involved voluntarily it will be the same... it seems you don't understand Delphi principles yet and your approach to the problem and how you reacted here was not top-notch. I follow the philosophy that it is always my fault if something does not work out the way I wanted in the code I am involved with unless it is proven otherwise. It helps me to feel responsible for it and forces me to investigate properly and whats even cooler is that I just usually fix the issue even if someone else is to blame for it. It saves time and I just learned a whole bucket load and it sharpens the most critical development skill anyone can posess: Debugging. Learn to appreciate source code. If you don't know how something works then go and read the source code. You will get the understanding for it and you will learn again. I suspect most guys here might have had some idea in their heads that made them cringe on working on a project along with another coder that attacked the tools first instead of trying to understand first. If you want people to join the project or lend a hand then the environment for the collaboration should be inviting and free of nonsense.

You can always set the Memo to a default height upon creation and then allow it to be changed dynamically as soon as the contents change. Or you can add some sort of text afterwards to force Memo1ChangeTracking but I strongly believe in first figuring out why this is happening so that you can make an informed decision about how to approach the issue. You say your skills are too low to solve this problem. I disagree with such a statement. It is exactly the reason and opportunity for you to learn and acquire the skill. Put your head down and go through the source code and follow the breadcrumbs. Don't give up.

It is possible that the ContentBounds might not have been updated yet if you call Memo1ChangeTracking in the same code scope as where you created the Memo. Some controls do some updates and calculations on their paint cycle which has not yet occured while in the Button1Click procedure. Inspect the source code for the TMemo and possibly TEdit and check how ContentBounds gets populated and where it gets updated. That will probably give you an idea about whats happening here

I am no C++ expert but shouldn't the asterisks of the parameters be immediately following the types and not precede the parameter names?

Have a look at Clipping Regions.. Here is a little example (Obviously this for the Windows platform): https://docwiki.embarcadero.com/CodeExamples/Sydney/en/ClipRect_(Delphi)

I have used WMI in multiple simultaneous threads before but always created and kept the WMI Objects local to each thread. Are you sure there is no other API/way to do what you want? WMI generally is slow.