Douglas Stemen on 29/3/02 10:46 PM etched: > On 3/29/02 3:59 AM, "Robert Purves" <robert.purves@...> > wrote: > >> >>> The following toolbox access routines allow the user to directly access data >>> files. They work fine in R6, except when compiled under carbon they create a >>> "function must be defined before using" and other compile errors. >>> >>> FN OPEN(PBlk&) >>> FN CREATE(PBlk&) >>> FN FLUSHVOL(PBlk&) >>> >>> In OS X what is the correct syntax for these routines, if any? >> >> Step 1. Turn on the checkbox: >> Preferences/DBug/Insure validity of PPC toolboxes. >> >> Leave it on always (except, perhaps, for compiling your app's shipping >> version, and even then not a bad idea to leave it on). >> >> >> Step 2. Convert old wrong toolbox names in your project to the correct >> modern >> names. This avoids ambiguity about what you are actually calling. >> >> Old wrong name Correct name >> >> Open, OpenSync, PBOpen PBOpenSync >> Close, CloseSync, PBClose PBCloseSync >> Read, ReadSync, PBRead PBReadSync >> FlushVol PBFlushVolSync >> Create PBCreateSync >> Control PBControlSync >> KillIO PBKillIOAsync >> Status PBStatusImmed >> >> Compilation should be unaffected by this renaming. >> >> >> Step 3. Think: "Why am I using these notoriously incomprehensible ParamBlock >> routines? They hark back to the 1980's. Why am I not using the FB file >> statements: Open, Write #, and so on? For special toolboxery, if that is >> really necessary, why don't I use a FSSpec with FSxxxx routines, which would >> be 1990's code and less conspicuously out of date?" >> >> Macho Mac programmers would do anything, even drink bad beer, to avoid >> PBxxxxx >> calls. >> >> Step 3' Drink another glass of Fine Old Panther Piss. Go to step 3. >> >> >> Step 4. Insert this in your source code, to fix a Release 6 headers bug that >> wrongly makes PBFlushVolSync seem unavailable in Carbon >> >> #if CarbonLib >> toolbox fn PBFlushVolSync(long) = word >> #endif >> >> >> Step 5. Replace calls to PBCreateSync by PBHCreateSync, which Apple says >> is >> (very nearly) an equivalent. >> >> Replace calls to PBOpenSync by PBHOpenDFSync. This is preferred, according >> to >> Apple, over the obvious alternative PBHOpenSync. >> >> >> >> Step 6. Special action is needed whenever a ParamBlock gets its ioRefNum% >> field set to a wdRefNum, as obtained from FB Files$(...). A wdRefNum was a >> workaround introduced by Apple for HFS, to allow old MFS file calls to limp >> along into System 6. Apple discontinued it in Carbon, where no toolbox >> routines can accept a wdRefNum parameter. >> >> PBlk&.ioVRefNum%=Vol% ' this is volume reference number >> // Note: the var named vol% may be wrongly named and commented. >> // If it came from an FB Files$(...) statement, it's a wdRefNum >> >> You *must* call FBWDToPBWD(PBlk&) before supplying the PBlk to any PBxxxxx >> toolbox routine. FBWDToPBWD fixes up the ParamBlock to resolve the obsolete >> wdRefNum. This is an ingenious Andy Gariepy workaround, to help old FB code >> to >> survive into OS X. >> >> >> HTH, >> >> Robert P. > > > > Thanks for the information. This is exactly what I wanted to know! > > > > Doug Stemen > > > > > -- > To unsubscribe, send ANY message to <futurebasic-unsubscribe@...> Me Too Ducking for cover, and dreading the bolts of thunder! -- Pete... (the other one)