On Sun, 30 Mar 2008, C Western wrote:
> Michael Van Canneyt wrote: > > Indeed. It completely short-circuits the idea of trying to locally resolve > > references before trying globally :) > > > > Anyway, your hint gave me the idea where to look. > > I fixed the issue properly. The error was in another routine altogether. > > > > Hopefully now 11060 is really fixed. > > > Things now seem to work for me after a little adjustment. I don't know if it > is intentional, but the order in which references are satisfied seems to have > been reversed in the current version, which revealed a minor error in my code. > I suspect I won't be the only one, so it might be kind to reverse the list to > avoid similar problems. Nono, it's good that you fixed your bug. You should never rely on the loading order. For forms, for instance, it is dependent on the creation in the IDE. A simple cut and paste could change the order. Relying on this would be bad practice. > > The other thing that struck me is that unsatisfied references do not throw an > error - shouldn't they? (It would have made fixing the error a little easier) > How about the following patch: Delphi doesn't throw an error either, and it should definitely not do so at the end of local reference resolving; At most this could be done after all loading is done, and you don't know when that is: forms can be created at any time... Michael. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
