Leaderboard

That is not what can be read in that comment. I cannot see anything about licenses being invalidated or not being able to compile old code. Even the question does not imply that. It is only about downloading the setup files, isn't it? If my business were founded on the fact to be able to download old Delphi installation files I would do something wrong in the first place. I suggest to install old Delphi versions inside a VM and have a good backup strategy for those - like many people I know are already doing for years now. In case someone is worried about not being able to register a valid license later, the solution can be to convert the Named User license into a Network Named User license. That requires an ELC server installed somewhere in the local network, but it simplifies registrations a lot. License bumps are no longer necessary with that. Moving a Delphi installation to a new machine boils down to installing it and importing a slip file. My own situation covers quite some of your points. I have old software that has to be maintained (if at all) with old Delphi versions. Some of my customers are stuck with an old Delphi version, so I am regarding their projects. I see no problems in any of those. Even if Embarcadero would be hit by a comet, I would be able to work for plenty of years. No! If anyone would be affected there are ways to prepare for it and be safe. No problem and I think it is fair. There is plenty of other software where it is impossible to get old installation files now. I can still remember times when software was delivered in CD or even Floppy disks. We were used to make backup copies of those in case they will break and the vendor would charge for a replacement CD - if even offering that at all. One can do something similar for ISO images. Having that said, the other points are just meaningless.

That part sounds fair enough to me.. More troubling is that the New Embarcadero Licenses and Download Portal still has no method of handling license bumps as outlined by the post above yours. As it sits now I can be responsible and burn an ISO or make backups but I can't find a legal way to move my installation..

Excellent job, excellent application ! 🙏 Original ITE, ETM was really very disappointing sometimes (being sarcastic here 😑). I think Embarcadero (currently owns the RAD Studio) should hire you for this excellent work, you are really covering up their a.. Like me, very old fans of Borland's Delphi and C++Builder (my favorite) do still like and write codes with this wonderful tool but sometimes it disappoints us in the very simple-stupid corners of programming life. And you, my friend today you are my number one savour of the day. Thanks a lot for your great work. Sincerely,

https://lmgtfy.com/?q=GDPR

I've given this quite some thought. I've made a list once here (it's in Dutch though) what you should do if you want a full fledged account management platform with login, and that's even before GDPR, and not handling what's available from other platforms, e.g. with OAuth or identity services from cloud providers that are available nowadays. I haven't worked with IntraWeb or TMS Web Core, but I've dabbled with a Delphi-(compiler-)based web-platform of my own, with an explicit emphasis on speed, security and portaility (between hosting environments), so yes if you want to build something serious you need user control and it takes some work. For a first big xxm application/website of my own: tx I for now stick to this list I created of everything I think a website with user accounts should have. But for new websites it's increasingly interesting to skip the hard work and make your website depend on a number of options you can expect your users to have an account with: Google, Facebook, Twitter, Microsoft, and if your public is somewhat tech savvy Github. (I should check if reddit has an OAuth api...)

It seems like a simple factory class could solve your issue. Let it have bunch of class methods like CreateItemsFrame, CreateUsersFrame etc. Let it know about your TProjectDataType enums that will get passed to corresponding factory methods. Main form only needs to know about this factory class. If there is some actions that needs to be taken based on what type of frame is displayed on main form, then let the frames to expose some event that main form can subscribe to and trigger this event when required.

While your approach makes a little sense, many of us learned very painfully that centralized collections of things become a huge, ugly mess over time. If you're using OOP, the notion of "encapsulation" carries over to other things besides classes. Classes are contained in things, and those things are contained in things, and so forth. Put stuff in the unit that manages it. Use some form of dependency injection to pass objects into others that need them, and Factories to request things you need from common locations.