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.
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:
Colin
diff -uNr --exclude=.svn --exclude='*.rst' trunk/fpcsrc/rtl/objpas/classes/reader.inc trunk.w/fpcsrc/rtl/objpas/classes/reader.inc
--- trunk/fpcsrc/rtl/objpas/classes/reader.inc 2008-03-29 21:15:01.000000000 +0000
+++ trunk.w/fpcsrc/rtl/objpas/classes/reader.inc 2008-03-30 12:11:52.000000000 +0100
@@ -658,7 +658,9 @@
begin
G:=AddToResolveList(R.FInstance);
G.Addreference(R.FRoot,R.FPropInfo,Copy(R.FRelative,1,P-1),Copy(R.FRelative,P+1,Length(R.FRelative)-P));
- end;
+ end
+ else
+ raise EReadError.CreateFmt(SResNotFound, [Ref]);
end;
L.RemoveItem(R,True);
R:=RN;
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
