I think I have that retractable cord mouse. Its good for on the go, but its a little too small for my hand and I hate that creaking noise it makes because its hollow.<br><br>Don't know why I felt the need to tell everyone that, but there ya go.<br><br>
cool set up Hagen!!<br><br>Now, off topic....Does ImageWell strip the resource fork from pictures. I was going to strip the fork from a pic I edited in Imagewell and send it to my PC brother so he wouldn't get two files. I was going to use GrimReeper CM, but the option to strip the fork was not there for the pic I edited in Imagewell. It was there for the original picture.<br><br><br>My Stuff
Loc: New Hampshire
Resource fork? Isn't that pre OSX stuff?<br><br>ImageWell doesn't create a resource fork - it just creates a jpg file.<br><br>[color:blue]My only goal in life is to live forever - so far so good!</font color=blue>
no, it is not pre-OS X. All mac files have a resource fork.<br>If I send a jpg to my brother (windows users) he gets two files. One is the picture, and the other (which he can't open) is the resource fork info.<br><br>Extra info you really don't care to see...hehehe<br><br><blockquote><font size=1>In reply to:</font><hr><p>File Forks<br> Under the Macintosh file system (called HFS, for Hierarchical File System, files are not monolithic and do not consist of one single segment. They may be composed of two pieces, called forks, i.e. a data fork and a resource fork. Only one of these two forks may be empty.<br> The creators of the Macintosh file system chose to put apart what is stored in an unique data stream on most computers. Please note that NTFS also features file streams.<br><br><br><br><br>Data Fork<br> The data fork contains what we generally call a file on the PC, that is the text created by a word processor, the pixels building a picture, etc. When transferring data files between Macintosh and PC, the data fork is generally the only part of interest (the only exceptions are font files, see below).<br><br><br><br><br>Resource Fork<br> The resource fork may contain the code of a program, the commands of a font file, etc. Some programs store a preview picture in the resource fork.<br> The code of programs is stored in the resource fork. Program files often have an empty data fork.<br> Against what is often said, even by knowledgeable persons, the resource fork doesn't contain the signature of Macintosh files (file type and file creator), which is stored in the disk catalog.<br><br><br><br><br>Why a Resource Fork?<br> The resource fork is organised as a data base, which allows a fast access to all components of the stream. This is a big advantage for some applications. It is also possible to change some elements without disturbing the rest of the fork.<br> This explains why it can happen that a program, transferred through channels ignoring file forks and having lost its resource fork, can no longer be executed (error -39).<br><br><br><br><br>The Dreaded "Lost Fork" Syndrom<br> The "lost of the resource fork" is a mythical catastrophe about which many messages are exchanged on all forums handling Macintosh file transfers. One should try to remain sober. The resource fork is not everything. Most of the time, the problem is not a fork problem, but a signature problem.<br> When a Macintosh data file is not recognized any more, for an example after a transfer through another file system, it remains usable. If it is not double-clickable any more, the explanation lies in the lost of the Finder information (signature, and so on). In this case, just launch the application which can handle such files and open the file with File | Open.<br> In the case of programs (applications), things are worse. The classical error message is error -39 (unexpected end of file). This happens because the Finder tries to open the resource fork to launch the program and finds that it is empty.<br> In this case, it is of no use to try to apply a "better" signature to the truncated file. One should redo the transfer using correct media, correct tools and correct procedures. See Installation procedures given for several situations.<br><br><br><br><br>How to Keep Both Forks Together?<br> Two main methods are commonly used to keep together both forks of Macintosh files on communication lines and on servers which don't know anything about forks: the MacBinary standard and the BinHex standard.<br> Our programs MacDisk and MacImage can produce and convert such files.<br> See also our page on Mail Attachments and on our utility MacMail for more information.<p><hr></blockquote><p>Anyway, the resource fork causes a lot of problems when sending documents, jpgs, PDF's etc to PC users.<br><br>I found that after editing a pic with Imagewell, there was no resource fork. Even just dragging the pic into Imagewell, and then dragging it out without doing anything else...will result in a smaller file size, and also, no resource fork.This is a good thing if you are uploading it to the web or sending it to a PC user because it really cuts down on the file size.<br><br><br>My Stuff
Loc: New Hampshire
I haven't seen resource/data forks in the Cocoa documentation so I wouldn't even know how to create one if you wanted one. <br><br><br><br>[color:blue]My only goal in life is to live forever - so far so good!</font color=blue>
Xplain's use of MacNews, AppleCentral and AppleExpo are not affiliated with Apple, Inc. MacTech is a registered trademark of Xplain Corporation. AppleCentral, MacNews, Xplain, "The journal of Apple technology", Apple Expo, Explain It, MacDev, MacDev-1, THINK Reference, NetProfessional, MacTech Central, MacTech Domains, MacForge, and the MacTutorMan are trademarks or service marks of Xplain Corp. Sprocket is a registered trademark of eSprocket Corp. Other trademarks and copyrights appearing in this printing or software remain the property of their respective holders.
All contents are Copyright 1984-2010 by Xplain Corporation. All rights reserved. Theme designed by Icreon.