Alain Vitry wrote:
Thanks for the answer.
But is that by design ?
Let' look at this case (not the best design, but big legacy):
File common.pas:
uses StandardFile, MacWindows;
...
var MaPict: array[WPictWind_1..WPictWind_3] of PicHandle;
File utils.pas:
uses commons, MacWindows, SegLoad, Quickdraw, StandardFile;
...
var PictRect: Rect;
...
DrawPicture(PictArray[i], PictRect);
Compilation:
Utils.pas(316,29) Error: Incompatible type for arg no. 1: Got
"MACWINDOWS.PicHandle", expected "STANDARDFILE.PicHandle"
I know about unit propagation. PicHandle is first defined in MacWindows,
then used in standardfile.
Used or redefined? Does the StandardFile unit also use the MacWindows unit?
The best solution I've found is to suffle units around, altough I find
this approach inelegant.
Renaming every occurence of some types is a better solution, altough
very intrusive.
Shouldn't type A defined in unit X be fixed whether units Y, Z who also
use it are included or not in my program ?
Also when unit Y defines a procedure with type A (from unit X) as
parameter, shouldn't type A still refer to the type A as defined in unit
X, and not become some types like Y.A ?
If I understood you correctly, yes. There is Y.A unless you define such
a type.
It is unclear to me, why this problem occur in the first place (In this
case there is no re-definition of the types, as for oldlinux)
It is unclear to me too.
Vincent.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
