GabrielMoraru

@Lars - Man! You are too calm. By this time I would have already placed an order on Amazon for a couple of grenades to send them to the user 🙂 🙂 🙂 . I have seen projects like this. Once the developers reach 100 warnings, they say that the shit has hit the fan and it is too much work ANYWAY to clean them up now. Then they permanently close the Messages window and never look back. __________ @dormky You need to understand that most warnings translate (sooner or later) to bugs. And nobody likes a "crashy" program. If your program does not crash, please do a batch search and report back how many times the keyword "except" appears in your code. This is why they say, "Treat your hints as waning and your warnings as errors!" Take two days off, take a beer, go to the beach, and clean them up. BUT for god's sake, don't hide them under the rug by manually forcing the compiler warnings off with compiler directives! Do the job properly. Start with the easy ones. You could easily fix the top 90% (easy ones) in one day. Leave the complex ones for the end. It won't be that frightening when you are left with only 20-30, even if those are the "heavy" ones (that require actual code refactoring). _ For 3 of the most complicated ones, I will give you free advice (on this forum or on my blog). But I can put my hand into the fire that other forum participants will jump to help also. Update: Maybe I can do some refactoring for you if your project meets the requirements of this "challenge".

It is magically fixed. Among others, I clicked "Install packages..." and I entered "c:\Delphi\Delphi 13\bin\AIEngine370.bpl" there. No immediate effect was seen. But after IDE restart, the AI menu re-appeared. I also flipped the "ResultDestination" to true but now I put it back to false and the AI chat menu is still there.

I have seen the window in Delphi 12 ("Smart code insight" menu item in the pop-up menu in the editor) but I haven't used it much because I cannot make a diff between my code and AI's code. I want to try it again under Delphi 13 but I can't find it. I have all the settings prepared for Gemini. The "Test connection" button says "ok". I checked: I don't have any packages disabled in the IDE. \\\Registry\HKEY_CURRENT_USER\Software\Embarcadero\BDS\37.0\Known IDE Packages\$(BDS)\Bin\AIEngine370.bpl \\\Registry\HKEY_CURRENT_USER\Software\Embarcadero\BDS\37.0\AI Engine\EnableAIEngine The Help says that the window is there, but don't tell you exactly where to find it: "The AI chat window is an IDE dockable form, which works like any LLM chat window." Any ideas?

Yes. I already clearly said you do have to do that. And that's good because with Library Paths your project does not care where your 3rd party libraries are. The second advantage is that you can link to the DCU files instead of PAS files - if it happens to work with large projects it matters. Your alternative "costs" the same amount of time because you will have to add the paths to the DPROJ files. But in this case, if you change any of your folders you will have to manually edit all your projects! > You still have to handle the location of generated bpls and make sure Delphi can find them. You are very wrong here. You don't. > No custom scripts? You still have to build the projects for all the platforms you use. If you use all of them, good luck manually building from the IDE a gazillion of packages for a gazillion of platforms. Have you ever heard of Build Groups? You will find it into the Project Manager. > You have to build the binaries for both Release and Debug configs, and add the proper folders to both Library Path and Debug Library Path, so when building your own application for Release it won't add debug info from 3rd party libraries, and when building your application for Debug you will be able to debug into the 3rd library code. Please do read my previous posts. It even has screenshots.🙂 Embarcadero solved that with $(Config). So, one single path is enough (see my screenshots). Delphi will take care of the rest automagically. > You want to ctrl+click an identifier from a 3rd party library and have the IDE Code Insight navigate to its source code? You have to add the folders of the source code to Browse Library Path so Code Insight and debugger can properly find the unit you need to open and show it to you. Of course. Your alternative would be to add the source code of ALL your 3rd party libraries to your project: same amount of work but sloppy (IF you work with large projects). >Wrong. Again a generalization. No. It is not. It is backed up by facts. TMS is not using $auto. See: fact. Actually TMS is one of the libraries that makes migration to a new edition of Delphi difficult. >why we created Smart Setup and tried to make it as flexible and fast as possible. I totally understand your motivation here. We exposed both sides of the coin (I also presented tutorials, facts and screenshots). Let people decide what they will choose. No need to argue anymore.

You asked a simple question and we really deviated. I apologize. So, let's answer your answer concretely. If you don't want to be depended on your 3rd party library and make it work with all Delphi versions, you need to set these 3 simple things: In your 3rd party package (Spring4D): 1. Let Delphi choose the correct output folder by using modern environment variables: What it does: This will put the DCUs in the: "Spring4D\22.0_Win32_Release" folder - for Delphi 11 "Spring4D\23.0_Win32_Release" folder - for Delphi 12 "Spring4D\37.0_Win32_Release" folder - for Delphi 13. 2. Let Delphi choose the automatic BPL versioning using modern environment variables: What it does: This will make Delphi to output a BPL that has a suffix based on the Delphi version number. This way you can have one unique BPL for each Delphi version. Example: Spring4D_370.bpl (for Delphi 13), etc 3. Add your Spring4D path to the "Library Path" (not "Search Path"!): c:\YourProjects\Spring4D\$(ProductVersion)_$(Platform)_Release <-- Add here your REAL path instead of "YourProjects" What it does: This lets the compiler find the precompiled DCUs. This way you won't have to compile Spring4D (which is not small at all) every time you compile your project. That's it. Advantages: 1. Maximum fast because your compiler will find the precompiled libraries. 2. Your projects (observer the s) will not care where Spring4D is installed. So, no need to mess up the "Search Path" of every project you have with hard-coded paths. You can easily move Spring4D folder without having to open all your projects and update the "Search paths" to reflect the new location of Spring4D. 3. When you install an new Delphi edition, all you have to do is to right click Spring4D and choose "build".

So, from what you say, I guess those 3rd party libraries also don't use $Auto. Right? It is so sad. The moment Embarcadero introduced the $Auto, it revolutionized packages. With it, you can have one single package (DPK file) for all Delphi versions (since Auto was introduced). A true game changer. No. Unless you have large amounts of code (could also be waived, if you don't mind waiting 1 extra minute to compile the 3rd party libs with code. Some have patience...🙂).

Ok. I guess, if you really want to keep the 3rd party libraries up to date, by the clock... Usually, I am happy with the stability of my 3rd party libraries... I only update them once per year 🙂 Some of them have my own bug fixes so I prefer to keep my current version 🙂 I general I rather write my own code than depending of 3rd party code. So, I don't have much of those.... which makes MultiIstaller of less use, for me 🙂 ---------------- Anyway, I like your setup. I don't see any -r atrocity in there 🙂

I agree with you, except the last point: why would you need to redownload Delphi dependencies when you upgrade Delphi? Most small packages out there do support all Delphi versions without much or no changes (if they use $(Auto)). All you need is to recompile the 3rd party packages. No custom scripts, no -r hocus/pocus, no virtual machines, no condas, no registry editing, no messing around with IDE's settings . Just right click and "Build all". Honestly: Cannot be much simpler than that! __ TMS and other proprietary mammoths like this need to be indeed re-downloaded 😞 They haven't heard yet of $Auto.

I got this crash in the IDE and there I see the stack (this is not new). I guess this is what I was supposed to see (in Delphi 13) for my own projects.

So, I guess (I guess only) you deliver the external dependencies (packages) without your project... For small projects, under 2 mil lines, could work. Still, against the way Delphi was built 🙂

[deleted]

Hard-coded paths like this can also be modernized by replacing it with $(Auto) and $(ProductVersion). Next time when you install a new Delphi version, you won't have to change the paths AT ALL, just recompile your libraries.

Not only that I don't agree, I recommend the opposite and for a good reason:🙂 Scenario Imagine you have Project1 that uses Library1 (Spring4Delphi or something else). 1. If you give your project to someone else and you have the DCU paths (for Library1) in the DPROJ file, you FORCE that person to install the dependent library (Library1) in exactly same place as you have it on your computer. If the user already has Library1 installed in his computer, he will have to change project's options. So, it is clear that this way of using paths is not portable. 2. If you use the IDE "Library paths" then the the information about the Library1 is not included in your project. If the user receiving your project already has Library1 installed (and he was smart enough to use IDE "Library Paths") then Project1 will compile in his computer without any modifications. This is the exact purpose of "Library paths": to keep the external libraries/dependencies separated from your projects!!!! - Delphi's help: Spring4D is a package! _ This is exactly what Delphi does: when you create a new project you don't have to specify where Vcl.Dialogs or System.SysUtils DCUs are for that project. The project can already find them because they are in the Library Paths. Why reinventing the wheel? _____________________________________________ This could also be bad advice if you have truly large projects. Why adding another few seconds to your already-2-minutes-long-compilation-time when you could use precompiled DCUs? Again, this would be counter-Delphi-way: When you start a new project in Delphi, you don't compile the Vcl.Dialogs.pas or System.SysUtils.pas. Your project will find and use the precompiled DCUs. _____________________________________________ I think paths are one of the least understood parts of Delphi, and therefore the most abused. I upgraded several large projects to use precompiled libraries and I showed off really big amounts of times from the compilation time, with no downsides. For most of my personal programs, the project (DProj) "Search Paths" are empty. God gave use Library Paths for a good reason. Let's use them. 🙂

https://docwiki.embarcadero.com/RADStudio/Florence/en/What's_New#NameOf_Instrict_Function > So maybe that was a feature they planned but didn't release but the still had it mentioned in the press release.  Could be....

The documentation for D13 mentions that: This feature, if it is what I think it is (not as was tricked with NameOf), would be cool. But it does not work for me. I looked in the IDE option under "Debug" page to flip a switch. There is nothing there...