corneliusdavid

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.

Sorry, I wasn't clear: Those folders are added to the Windows System Path (outside of Delphi). And after the standard install, Delphi's Library Path should contain: $(BDSCOMMONDIR)\Dcp $(BDSCOMMONDIR)\Dcp\$(Platform) After JCL/JVCL is installed, the Delphi Library Path should additionally contain: <base jcl install path>\jcl\jcl\lib\d28\win32 <base jcl install path>\jcl\jcl\source\include <base jcl install path>\jvcl\jvcl\lib\D28\win32 <base jcl install path>\jvcl\jvcl\common <base jcl install path>\jvcl\jvcl\Resources for Win32 development; equivalent ones for Win64 development. Several source folders were added to Delphi's Browsing path as well: <base jcl install path>\jcl\jcl\source\common <base jcl install path>\jcl\jcl\source\windows <base jcl install path>\jcl\jcl\source\vcl <base jcl install path>\jvcl\jvcl\common <base jcl install path>\jvcl\jvcl\run Hope this helps.

This isn't an official answer and I don't know how helpful this will be but I looked at the Windows Firewall settings on a virtual machine where I use both Delphi 10.4 and Delphi 11.1 and didn't see any specific ports open but several applications that are allowed for in-bound communication: So, only for remote debugging or RAD Server. If anything, it's likely using the standard port 80 (HTTP) or 443 (HTTPS) for outbound calls but you should be able to use it without an internet connection after the initial license verification.

I installed JCL/JVCL after pulling the latest from GitHub and running the supplied install batch files--and it installed fine. If you installed D11 into the default folder, you should have four folders added to your path: C:\Program Files (x86)\Embarcadero\Studio\22.0\bin C:\Program Files (x86)\Embarcadero\Studio\22.0\bin64\ C:\Users\Public\Documents\Embarcadero\Studio\22.0\Bpl C:\Users\Public\Documents\Embarcadero\Studio\22.0\Bpl\Win64

I totally agree. It frustrates me to no end to see and hear about problems in the product but not have any response or idea when they'll get resolved, if a feature is dropped, what the priority is, or ANYTHING. Just someone saying, "sorry it's late, we're working on it but are slammed" or something would be better than silence. So often, I see businesses just trying to pretend everything is OK when customers are clamoring for answers. I always give my customers reasons for being late, even if they've heard them before--they appreciate knowing I'm still alive and are listening to their cries.

Excellent! I like that method much better.

This isn't a "new" version (like 10.4 Sydney over 10.3 Rio), this is an in-place, dot-release update to 11 Alexandria. Yes, it uninstalls your current version 11.0 installation (if you installed it). Strange that the numbering scheme is a little different than the 10.x series (e.g. 10.1 Berlin and 10.0 Seattle).

Sorry I hadn't seen your question from a few days ago but glad you found the solution.

Try putting a TLayer3D on the cube (as a child object) and then adding a TLabel to that. To make the TLayer3D transparent, check Transparency property and make sure the Fill.Kind property is set to None (sometimes you have to toggle that to Solid and then back to None to get it realize it really should be transparent).

I have less experience on the Mac but each app deployed has several sub-folders with different supporting parts like libraries and resources, so with a little study, this should be quite doable.

Start here: https://firebirdsql.org/ Lots of links to documentation, support tools, and community blogs, etc.

Firebird is awesome--works well as either embedded or server, so it can scale with your app. SQLite is small and nimble and available on every single platform. If you have a choice, do not use Access--you will have many problems down the road.

I use this a lot and it works well for a variety of use cases. You can create the component in code pretty easily. GExperts has a nifty tool to do this for you. The TTaskDialog component can be placed on a data module; it can also be called from another unit (or form or data module) to keep your form clean.

I clicked on the link and it can't be found; searched for the title and couldn't be found either.

I have the following: Delphi 11 on Windows 10 and Windows 11 Mac Mini with macOS Monterey 12.0.1 on a 3 GHz Intel Core i5 Platform Assistant Server vr. 13.0.12.0 iPad and iPhone both running iOS 15.1 I've had problems in the linker process trying to get even the simplest bare-bones app to build for iOS. I have no problem with Android or MacOS--it's just iOS. At first, I had an error finding the /System/Library/PrivateFrameworks directory. Looking through the SDK Manager for iPhoneOS 15.0, I found a the Remote Path with that entry and removed it--since it didn't exist on the mace where I found other framework folders. Now I get the following error: [DCC Error] E2597 ld: file not found: /System/Library/PrivateFrameworks/DocumentManager.framework/DocumentManager for architecture arm64 I cannot figure out why it tries to link that file and why, if it expects it, that directory does not exist on the Mac--like I mentioned, other "framework" folders exist. I've removed and re-added the iOS platform looked through the .dproj, and refreshed cached SDK files. I've got this problem on two different computers and have run out of ideas--and patience. Anyone have any suggestions?

A few other pieces of information might be handy to make a good decision. If there are just a few of these corporate customers and the only branding is the logo, getting the logo and building a custom install from your compiled application would be relatively simple to manage--I've done something similar to this. And yes, like @Vandrovnik mentioned, InnoSetup is great for this--either for you embedding a custom logo or with them supplying a logo with the right name and size in the right location so the installer can find it. But if your customers want to do a lot more than just the logo, like customize some labels or options or set colors and distribute a whole "themed" application, then I would suggest building a theme packager (could be as simple as zipping some files) and making it simple for them to create a theme and package it for their own distribution. Your installer would have to look for a theme package and apply it and you'd deploy a basic theme. My experience with any sort of theme or customization is that there will always be little changes here and there after it's "done" and you don't want manage all those for all the customers, so giving your customers the ability to mange those for themselves would be highly preferable. In any case, you want your base application the same between paid and free if at all possible, and some sort of long, encrypted license key or something that unlocks the full power for the paid version.

It's called "Coding in Delphi and Beyond". I changed it to "Just Another Developer Blog" a few months ago because I didn't want people to think it was connected to the books by Nick Hodges. Last night, I found it listed in "begin end" with the original name so just changed my blog's name back to that. Now I gotta go change my signature line here again.