Please Note: The information in this document has just been translated over from the printed version (14-Aug-98) and is being reviewed. There are errors! This notice will go away once all the obvious errors are corrected. From there, this document will be upgraded over time.
After spending many long hours providing assistance to Macintosh owners who purchased either 100duet or WPduet from our club, I have come to the conclusion that Macintosh owners generally do not understand the concept of the ASCII file, nor the fundamental precepts of how Macintosh-based applications handle files. This realization, coupled with the desire to help our Macintosh-using members, prompted me to write this tutorial for inclusion with 100duet and WPduet.
The phone rings and I answer. The voice on the other ends starts out with something like, "Hi Rick. I just purchased (100duet or WPduet) from you and I'm not sure it's working correctly. I followed the directions, I think, and was able to get the files from my Model 100/102/WP-2 computer over to my Macintosh computer but I can't read them. Every time I try to open the file it won't open. I need some help." Right away I know the answer. This person does not understand that the files transferred from the laptop to the Macintosh are in ASCII (American Standard Code for Information Interchange). Furthermore, this person lacks the fundamental knowledge of how Macintosh application programs handle files.
"Well, let me see if I can explain something." I say. "You need to know that files, created with Mac application programs, carry information that tells the Mac operating system what file goes with what program. The 'ownership' information is at the head of the file. When you double click on a data file, the Macintosh operating system looks at the file's header to determine what program created that file and commences to run that program, then load in the selected data file, automatically, once the application is up and running. This is generally called piping."
I continue with, "Granted, it's a nice way to work. Users do not have to understand what files work with what programs. They simply go to the file they want and double click. The file's contents (header) informs the operating system what program to run, then pipes that file into the program's editing buffer where it appears on the screen." Then I ask them a question, "But what do you do when the file you want does not have 'ownership' information in its header?"
At this point they do not have an answer, but I know they are ready for one, so I enter into a step by step, half conceptual, half practical explanation:
Double click on the application program, i.e., Microsoft Word, or MacWrite, etc. Try to open the file as if it were owned by that program. If that does not work, you need to find a message choice that allows you to open "any" file. So, that's the answer. If, when you are in your application, you can not "open" a file (assumed ASCII file) look for "whatever" method that's available for opening "any" file. Sometimes this is called a .TXT file. Anyway, that's the answer.