Conversion of Apple's Code
by Gale Paeper
This package contains the Pascal converted code for Apple's HISimpleList sample code
downloadable from Apple's website.
The code shows how to create simple list custom controls using the HIView APIs introduced
with Mac OS X 10.2. The code uses CarbonEvents and RunApplicationEventLoop for all
operations. Menus, windows, and controls are all handled using CarbonEvents.
here to download the source code package for Pascal HISimpleList.
This package is a revised and updated version of the February 2004 HISimpleList sample
code distribution. The source code has been updated to compile using the Mac
OS X Pascal Interfaces Version G
instead of the largely outdated Apple Universal Interfaces version 3.4.2 and has
been revised for common source code compiling with CodeWarrior Pascal and GNU Pascal
(GPC) compilers. Three projects are included demonstrating how to build HISimpleList
with those compilers. The projects are:
- In the "HISimpleList_GPCPlugins"
folder, a CodeWarrior Pro 8.3 project using Adriaan van Os' Microbizz GNU Pascal CodeWarrior plugin
compiler package to
build a Mach-O based version of HISimpleList.
- In the "HISimpleList_Xcode"
folder, a Xcode 2.1/2.2.x project using Adriaan van Os' GNU Pascal Xcode integration Kit to build "Debug" and "Deploy"
Mach-O based versions of HISimpleList.
- In the "CW Pascal HISimpleList"
folder, a CodeWarrior Pro 8.3 project using Metrowerks' CodeWarrior Pascal compiler
to build a Code Fragment Manager (CFM) based version of HISimpleList.
The common source code used in build HISimpleList is located in the "Sources"
Since HISimpleList uses Mach-O only CoreGraphics for drawing, the CodeWarrior Pascal
project uses additional support code to facilitate the source code transparent usage
of Mach-O only CoreGraphics routines from CFM based code. The additional support
code is located in the "CW Pascal Extra Files" folder. Instead of using
runtime generated Mach-O function pointers for calling CoreGraphics routines from
CFM based CodeWarrior Pascal code, an alternative CFMLateImport method is used. The
CFMLateImport code from Apple's CallMachOFramework sample code is used to fix up the application's
weak linked CoreGraphics CFM imports shortly after the application starts up so those
imports resolve to the corresponding Mach-O shared library exported routines and
data. (Although the original CFMLateImport.c couldn't fixup Mach-O external C constant
data imports, I have modified the code so that's now possible.) Using CFMLateImport,
CFM code can directly call CoreGraphics routines just as they're declared in the
Mac OS X Pascal Interfaces files without having to mess around with function types
and function pointers.
To facilitate using CFMLateImport and Mach-O only routines in other CodeWarrior Pascal
CFM based Pascal code, the included CFMLateImportFromMachOBundle unit provides an
easy to use interface and handles all the gory details of supplying the necessary
FragmentInit routine, loading the Mach-O code bundle, and interfacing with C code
For convenience, a weak link CFM shared stub library, MachOCoreGraphicsLateImports,
containing all the Universal Interfaces' CoreGraphics function, procedure, and external
C "constants" is included. A weak symbol link file, MachOCGraphicsLateImport.wke,
is also included. Using MachOCGraphicsLateImport.wke file allows CFMLateImport to
fixup all the symbols that can be found in the Mach-O framework bundle and skip the
symbols that can't be found. (CFMLateImport will stop fixing symbols on the first
non-weak import symbol encountered and return an error.)
A few notes on using CFMLateImport to late import CoreGraphics routines for other
- The necessary files are: CFMLateImport.c,
CFMLateImport.h, CFMLateImport.p, CFMLateImportFromMachOBundle.p, MachOCGraphicsLateImport.wke,
MachOCoreGraphicsLateImports, and MoreSetup.h.
- The files from the list that
need to be included in the project's file list are: CFMLateImport.c, CFMLateImportFromMachOBundle.p,
MachOCGraphicsLateImport.wke, MachOCoreGraphicsLateImports. (The other files are
just header/interface files which just need to be located where the compilers can
find them using the project's access paths.)
- Add CFMLateImportFromMachOBundle
to the relevent uses clause.
- For each of the project's
targets, set the Initialization Entry Point to FragmentInit in the target preferences
PPC Linker preference panel. (If a project needs a more customized CFM fragment intialization,
see the comments associated with the FragmentInit function in CFMLateImportFromMachOBundle.p.)
- Before calling any CoreGraphics
routines or acccessing CoreGraphics external C "constants", the project's
code must call CFMLateImportMachOBundle to fixup the code's CoreGraphics imports.
It is probably best to do this shortly after application startup so the code can
gracefully handle any errors encountered during the fixup process. (See the FixUpLateImports
function in TestHIView.p for an example.)
HISimpleList is largely based on Apple sample code. As Apple's usually practice for
sample code, very little error checking is performed and the user interface has a
few rough spots.
IntelMac Note: Since I
don't have an IntelMac, I've only built and tested the projects for PPC Mac targets.
However, Adriaan van Os was kind enough to build and test the projects on an IntelMac
with the following results:
- The CW/MW project builds on
IntelMac with CW 10 and produces a PPC/CFM app, that runs.
- The CW/GPC project builds
on IntelMac with CW 10 and produces a native Mach-O/Intel app, that runs.
- The Xcode/GPC project builds
on IntelMac with Xcode 2.3 when "GPC_CODESTYLE = -mdynamic-no-pic"
is changed to "GPC_CODESTYLE =". It produces a native Mach-O/Intel
app, that runs.
Copyright © 2006, Gale Paeper