corneliusdavid

Can you give us some details? Is this a Delphi module or a component or something in the project? What's the specific error message?

Yes, the CE version can build WebBroker apps. You can also use it to build Microsoft IIS or Apache web modules but not Linux or DataSnap. Go here: https://www.embarcadero.com/products/delphi/product-editions and download the feature matrix for details.

I get access violations once in a while in rtlXXX.bpl (almost any version of Delphi). I'm used to older computers where if something was broke, you just rebooted and got back to work. I find this works 99% of the time with Delphi. I wish it was better but it's really not terribly disruptive because I can work for hours or even days in multiple VMs on multiple projects before I see it and in less than a minute, I'm back where I left off without losing anything.

I get this every once in awhile. Just follow the directions and get back to work.

Without describing or posting any part of your project, you can't realistically expect any useful troubleshooting help.

First of all, THANK YOU @Remy Lebeaufor your contributions over the years to the Indy project, both in development and in support on this and many other forums. So do I and to learn there's only one main developer on this project who doesn't even have a working IDE at the moment is quite concerning. I wish I had the time/knowledge to help.

Yes, that's been the standard recommendation for a long time but there's been work to standardize the installs so that either .iso or web install will work regardless of the method used for the previous install--perhaps they just haven't removed that warning. I don't have a "default" method for installs and, in fact, don't even remember which method I used for which version on which computers. I've never had a problem with the installs (I'm pretty sure I've mixed them up at some point) and am actually puzzled about what's wrong with using a different process for an upgrade than the original install used.

Here's what I would try: manually download and install .NET. Since the error messages indicate both 4.0 and 4.7 (from what I gather reading your original post), install both versions. Those installs might include additional files that the standard Delphi install is missing or expects to already be in place. It might work--I don't know, I'm just throwing this out there.

Lots of different reasons why downloads or installs fail (internet, disk errors, network, anti-virus, etc). I downloaded both the .iso and the .exe (web install) onto two different computers. The .iso failed to mount on one of them so I used the web install; the .iso worked fine on a different one. All just depends on the particular arrangement of bits in the ether on a particular day, I guess!

That's good to know. Did the problem just start with Delphi 11?

Thinking about the original question here a little more, I think the problem might be related to the OS: I think most developers run Delphi on Windows 10, which would have all the libraries a typical Windows user would need for a variety of applications. But Windows Server is not an end-user operating system so leaves many things out. It may be that a manual install of .NET or related libraries/tools may need to be done in order for Delphi to work properly on Windows Server.

I find refactoring often broken in that it doesn't work but it (to my knowledge) has never crashed Delphi. Out of curiosity, I moved the "refactoride280.bpl" value to a different key, restarted Delphi, and refactoring was no longer in the menu. Theoretically, that's one .NET package out. However, I noticed there's another one named, "dotnetcoreide280.bpl." That's obviously got something to do with .NET. I tried removing that and now compiling a small cross-platform app in Delphi 11.1 gives me the error, "Object reference not set to an instance of an object." I put the registry key back and it compiles fine.

What version of Delphi? Do you have code in the OnResize events? Can you create a small example program that demonstrates this problem?

This is getting off-topic but... I never use the database-level account feature but use one application-level account to connect to the database then provide a login that checks against a user record for authentication. So if your application is built to require database account credentials before connecting, then you're right, the approach I suggested would not work.

Create/Free are the calls that allocated/deallocate the memory for an object, an instance of TDoSomething in this case. In your original code, the call to Create in Button1Click but the Free happens in a procedure of TDoSomething--that's where the difference in context is. The only reason it didn't blow up is because you don't reference the object (the DoSomething var) after the call to Free. Look at my first example code above where I point out where an ERROR could occur--that's what COULD have happened to you.

I don't think I've ever seen a procedure of a class free the instance of the class it's being called from. Everything in me is screaming DON'T DO IT! This is very bad practice. The object code may still be in memory after the call to Free but it's no longer dedicated to that object and if, per chance, some other operation suddenly uses that available memory, you've got an access violation. And to make an example that shows the problem of the dangling pointer @Attila Kovacspoint out: procedure TForm1.Button1Click(Sender: TObject); begin var DoSomething: TDoSomething := TDoSomething.create; DoSomething.DoSomething; if Assigned(DoSomething) then begin ShowMessage('DoSomething Freed but dangling reference still exists'); DoSomething.DoSomething; // <--- ERROR! end; end; It's better to free the memory outside of the class itself in a try-finally block: procedure TDoSomething.DoSomething; begin ShowMessage('Doing something'); end; procedure TForm1.Button2Click(Sender: TObject); begin var DoSomething: TDoSomething; DoSomething := TDoSomething.create; try DoSomething.DoSomething; finally DoSomething.Free; end; end; This makes it obvious from the calling procedure (the button click event) that the object is freed which lessens the likelihood of using it again because it's right there in the procedure instead of hidden in the class itself.

There's no one perfect way that everyone should use. Personally, I use two different approaches: If a program uses a database, I keep all the configuration settings in there except for the path/server/port of what is needed to connect to the database and those are set in an .INI file in the same folder as the application during installation. The installer has admin rights so it can create files under Program Files, and the database settings should never be changed--except by an administrator. In this case the INI filename is simply: ChangeFileExt(Application.ExeFilename, '.INI') If a program doesn't use a database and has several options to configure when the program is in use by regular users, the INI filename is: FAppDataPath := TPath.Combine(TPath.GetPublicPath, ChangeFileExt(ExtractFileName(Application.ExeName), EmptyStr)); ForceDirectories(FAppDataPath); FAppConfigFilename := TPath.Combine(FAppDataPath, ChangeFileExt(ExtractFileName(Application.ExeName), '.ini')); This puts the file in a folder under %ProgramData%\MyApp making it global for any users on the computer.

That's not the whole command line; the project file is missing and it looks like an option is cut off. The command-line run by the IDE is likely several lines long as it lists all the library, include, search, resource, and output paths specified in your Delphi environment.

Here's a better page that provides links for deploying the files for various platforms using the ToGo license you get with the Architect Edition: https://docwiki.embarcadero.com/InterBase/2020/en/ToGo_Quick_Start

Deploying InterBase requires different files on different platforms. Is this a Windows-only solution or mobile? You might be able to use your IB ToGo license. Start here (it gets complicated): https://interbase.com/deploy/

I'm a relatively new MVP and have been reading this thread without saying much (partly because I've been away from the computer and partly because I'm new and just listening). The title, at least in my case, was awarded in recognition for what I already do--support the Delphi community. I have been the coordinator for the Oregon Delphi User Group for many years and have been keeping it active. I was also blogging once in a while and was in the middle of writing a book about Delphi. There aren't many hard-and-fast requirements, just keep doing what I'm already doing but maybe a little more frequently; I'm also encouraged to help with beta testing and support forums such as this which I do as I'm able. Yes, we're supposed to be cheerleaders, and I'm happy to do--that but I don't do it blindly and I don't consider myself a paid shrill. I know there are problems with Delphi--I've encountered access violations, refactoring doesn't always work, I miss the Parnassus plugins, etc. There are problems in virtually every piece of software under the sun and if you visit forums for other products, even Microsoft tools, you'll find complaints and frustrations aired there as well (I've read horror stories about trying to develop cross-platform .NET apps with Xamarin; and did you ever write a major app in Visual BASIC then want to upgrade to the latest version? Good luck!). Perhaps there are an inordinate number of major flaws with Delphi but I still seem to be productive--and positive. Maybe it's because I don't do much with high DPI yet or haven't encountered major debugger flaws or some of the other things mentioned as deal-breakers for people--I don't have good answers for them. I do find discussing work-arounds, reporting bugs, and voting for the issues important to me, and yes, talking positively about the features of Delphi or products from Idera and Embarcadero I find really cool, to be much less stressful. I don't profess to know what goes on behind the scenes of Embarcadero but I've worked for enough companies to know corporate decisions often are the cause for features released too early, yet policy heavily restricts what can be said--and that's often very, very little. So I agree that we need to keep discussing the issues and keep reporting/voting for issues on Quality Portal but I hope my humble perspective is helpful to someone. Oh, and for the record, I have a paid Enterprise subscription.

Oh, that's right--I forgot about that! I often prepend the filename with the application's path in which case the above scenario I described happens.

There are lots of other good suggestions here but I'll just add one thing to check. By default, Delphi projects set their Output directory to .\$(Platform)\$(Config) meaning that while your project (and possibly your .INI file) are in a folder like \MyProject, the .EXE would be in \MyProject\Win32\Debug (for a Win32 app compiled with the Debug configuration). When it runs, it's running from \MyProject\Win32\Debug and therefore doesn't see the .INI file two folders up. When you specified the full path, it likely saved it (as @Attila Kovacspointed out) so that next time it ran, it found the second copy of the .INI file. This has caught me a few times and now I always check the project's Output directory setting. The possible reason you haven't seen this before is either you had set the Output directory (and forgot about it) or you were using a much earlier version of Delphi (before multiple platforms) that left .EXEs in the same folder as the project.

Excellent! Me too.

There's really nothing more than the standard web ports I mentioned earlier. You can run the IDE to build apps without internet connection. Today's modern software is delivered over the internet so it's to be expected that you'd need an internet connection for installation, updates, and to get add-on styles and libraries through GetIt (which uses a REST API over HTTPS). But after that, I can't think of any special ports or addresses required for normal use of the Delphi IDE. If you could please list specific error messages you're seeing, that would help.