The actual state is, that with relatively minor tweaks the UI´s can be compiled for Classic Mac OS (Olle) and also for Mac OS X (Rolf). After Jonas made some changes to the compiler with respect to the resolution of external names, I was able to produce a running NIB based Carbon application completely with Free Pascal within Xcode. NIB means that the user interface is built by Interface Builder and not with ResEdit.
Olle suggested to continue the discussion at the fpc-devel list, so after giving to you (the group) this short summary, I continue with the discussion.
Olle,
I am with you to keep the number of changes to the PInterfaces as small as possible. However, I would like to make a distinction between buggy or misleading parts of the PInterfaces and those parts which simply belong to another flavour (presumably the Mac one).
A. I advocate for debugging the UI´s and not to accommodate
for bugs in the Free Pascal mode -Mmacpas.B. I advocate for improving the Free Pascal mode -Mmacpas in order
to allow all Pascal Mac developers a smooth transition.C. I advocate for maintaining and improving the PInterfaces
as time goes by since Apple will not do it anymore.
Examples for A:
IMHO the active LongDouble routines in fp.p and the use of the term "object" at several places belong definitely to category A. In fact, your example "SetDeskCPat" is deactivated with the {$IFC CALL_NOT_IN_CARBON} directive. IT IS the policy of the UI to activate/deactivate not used parts for different platforms/targets - by this way the interfaces became universal.
I doubt that the term LongDouble was ever used by Mac Pascal Programmers. LongDouble was known as extended. So, I suggest not to care about the LongDouble routines, but simply deactivate them for Mac OS X by encapsulating them with the conditional directive {$IFC TARGET_CPU_PPC AND NOT TARGET_API_MAC_OSX}.
I consider "object" to be a reserved word for Mac Pascal. So it is a bug to use it as record field names or in routine declarations as parameter names. There is no other way, "object" must be renamed in the UI´s.
In CFStrings.p compared to CFStrings.h the declaration of CFSTR is simply missing, but many other parts of the UI´s rely on it. So, there is no other way, the following declaration should be added at line 158:
function CFSTR(cStr: ConstCStringPtr): CFStringRef; external name '___CFStringMakeConstantString';
Example for B:
{$LibExport+} belongs definitely to category B. It might be a good idea to let Free Pascal accept this directive in -Mmacpas in the future, even if it does nothing special but simply ignor it.
Example for C:
The changes to the type declaration of CStringPtr/ConstCStringPtr from Ptr to PChar belong to category C. After thinking about it, I aggree with you that this more specific change is better compared to the more general change of Ptr from ^SInt8 to PChar.
It might be a good idea to surround changes of category C with the conditional compiler directive {$IFC NOT UNDEFINED FPC}.
This would mean in the given case that in MacTypes.p:
CStringPtr = Ptr;
CStringPtrPtr = ^CStringPtr;
ConstCStringPtr = Ptr;
ConstCStringPtrPtr = ^ConstCStringPtr;should be changed to:
{$IFC UNDEFINED FPC}
CStringPtr = Ptr;
{$ELSEC}
CStringPtr = PChar;
{$ENDC}
CStringPtrPtr = ^CStringPtr;
ConstCStringPtr = CStringPtr;
ConstCStringPtrPtr = ^ConstCStringPtr;If we follow these rules then no change of either category will break compatibility to old Mac compilers or different targets.
I aggree with you that it would be great if Apple would allow us to distribute a patched version of the PInterfaces. In the meantime we have to go the diff and patch way.
Best regards
Rolf
__ InstantWare ______________________________________________________ Dr. Rolf Jansen * Stephanienstraße 19 * D-76133 Karlsruhe * Germany
http://InstantWare.bei.t-online.de/ _____________________________________________________________________
_______________________________________________ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
