this is D2010. not sure if it applies to other versions. and it's not a bugreport (not for madCollection, at least)

short problem: mad* packages required by other installed packages will result in those packages cannot be found error on IDE startup.

As I've been able to dig into it, I saw that the design time packages are loaded "first" (as in before other needed stuff, whatever that is, probably environment options; and during add-on loading) and from using sysinternals process monitor I noticed that there are only 2 sets of path that are being searched for, for required packages (maybe the first set is composed of multiple sets, I have no idea, just guessing, but it's a short set):- some internal "delphi" paths (which include the %BDSCOMMON%\BPL and %WINDIR% and %SYSTEM32% and alike (I've done this research a few weeks ago and I'm quoting from memory so don't be surprised if I get some of these paths wrong)- the actual %PATH% system variablenow, for someone who knows the internals of the delphi IDE and what dirs it uses and so on, this probably is not a complete and fully correct information, but it's what I noticed and deduced.

The thing is that the IDE library path is NOT used. Thus, mad* packages are not found (actually, any 3rd party package that is required by a design time package installed and enabled in the IDE which stores its BPLs in some other location; which makes this post not a bugreport against madCollection)

now, the key issue here is that I've set up my packages in a way that they require mad* packages (no way around this, unfortunately). And I *think* I've done this a little while back, in D2009 (which I used last year). I know the packages were setup up like this during D2009 dev, and the mad* dependency was added a bit later, but I don't remember if that later was during D2009 or after I switched to D2010 (and I don't have the time resources to setup a vm with d2009 and test if it works there or not).

what I am interested in, and asking you since I figure you know better, is where are these paths (used during package loading) read from? Is this some "raw" environment which later gets updated with EnvOptions.proj? If so, where is it read from? I have a "hack" batch file that loads my project group into the IDE, setting %PATH% prior to that to include tha mad* packages, but that's just a hack. I'd like to get a real solution to this

This usually occurs if you have installed your own packages, and the update to a newer madCollection version. In that case your own packages are being loaded first, and since the mad* packages are not loaded yet, Delphi complains. What I'm usually doing in this situation is this:

(1) Close all Delphi projects.(2) Go into the list of loaded packages.(3) Check the required mad* packages.(4) After that check your own packages.(5) Done.

Doing this will restore the correct loading order. Unfortunately you'll have to do that once every time you install a new madCollection version.

Not sure about how to handle this better. I'm trying to avoid storing my packages into the system32 folder, I think that would be an awful solution.

ah, now I understand where my issue is coming from. I wrote an automatic build ... "script" (more like a library) and one of the things this does is that it "registers" the known packages. Unfortunately for me, this was placing madexcept as the last thing to load. This script is pretty old but it worked fine when I wrote it because none of the packages actually depended on madexcept. Time for a rewrite

you're right, placing in system32 is a bad idea however you might want to try fiddling with the [HKEY_CURRENT_USER\Software\CodeGear\BDS\$(DBS_VER).0\Known Packages] registry key and just placing the madexcept entries as first below the delphi packages (I know, for non-bds it's another key and you'll probably have to write delphi version dependent code but that's just the ugly part of things).Another idea is to have the installer "save" the original place and insert the entries in the same position. That way upgrades won't break things.

It just happened again and completely forgot about this issue. Good thing with google

So my quick solution, given that this now happened with another project, was to close delphi, export the Known Packages key to a file, delete all the keys in it (except default), open the export file and move the madcollection packages rig after the delphi ones, and before "my" packages, then import the file.