At 9:13 PM -0500 on 4/5/02, mckernon wrote:


>I've found that all of my eDocs that make up the FB^3 reference materials
>are being misunderstood by OSX. When I first drag the eDocs from the
>FutureBasic CD to my Mac, I can double-click them and they open fine.
>
>However, when I try again later (probably after a reboot), OSX thinks
>they're documents and can't find an application to open them.
>
>I'm sure this has something to do with OSX's being fairly brain-dead
>about file types, but the FutureBasic eDocs are the only ones I've found
>with this problem. I'm using OSX 10.1.3.
>
>Anybody have any suggestions?

MacOS X is pretty weird with it's file associations, especially considering Classic

I found a few things that work.

1. Go to the System Preferences, start Classic and rebuild the Classic Desktop.  Reboot  This worked for me including Classic applications like the compiler

That should work but if not:

2. Select one of the help documents, do a Get Info and select 'Open with application', select the eDoc Reader.  If it gives you the option click on 'Change All'  Reboot

The first two should work for files that a file type.  For other files that have file types like '????' or are blank you need to add an extension then use that to associate the file to the application that owns it.

One of these days we'll get an eDoc reader, FB editor and compiler that are carbonized.

Might be awhile though, the eDoc reader is 68k, is still at vers 2.1.1 (released 3 years ago) and it doesn't look like a PPC (let alone Carbon) version is in the works.  Maybe it's time to abandon eDoc.  Maybe Bowerbird can come up with something better, it is an eBook after all.

The FB editor is 68k as well, I hope that Staz is working on a Carbon version.  Is it still built with FBII?  I see a lot of code resources in there but no FCOD resource.

The compiler shouldn't be as hard, at least it's PPC.  Is it even an FB application?  It doesn't appear to be since the PPC code fragment is in the data fork not a code resource and it doesn't contain the tell-tale runtime fragment.

Okay so give it up, the FB3 compiler was built with CodeWarrior wasn't it?  If it was Carbonizing should be pretty easy, unless it uses some older code.

BTW, I was browsing around the resource fork of the compiler.  I found a STR# resource with a list of Cpu names.  While I'd expect it to say Macintosh 68k, PPC, and FAT, I was surprised to see JAVA Application, DOS, and Windows95.  Staz, Andy, anything you guys want to tell us?