Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 8354 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies
Posted

I have a solution that I develop/maintain on the Mac. I send new files to a user via a CD. I have discovered that when she transfers them to the hard disk, they retain a read only file "property." This is, apparently due to the fact that they were on a CD (Read Only, of course).

Question:

1. Is there a way to transfer the files via FM scripting which will re-set those properties to read/write (so the solution is immediately usable)? I will also need to rename the old and the new files, but I think I can do that via scripting, anyway.

2. Is there a different way to do the above with a simple program, one that the user merely double-clicks?

Right now, I have the user re-name the current files (after saving the data separtely, via scripts). Transfer the new files to the same folder/directory. Remove part of the name on the new files ("NEW"). But the files are still not usable because they are still read only. This seems to be too much manual computer usage for a below average user! crazy.gif" border="0 Ultimately, I would like the whole process automated, of course.

Any help for a poor Mac user would be greatly appreciated! laugh.gif" border="0

Posted

Use a compression software such as StuffIt. When the user clicks to instuff, they will save the file to the hard drive. That way, the Read Only property will be avoided.

Or, they can simply right-click on the icon, select Properties, and uncheck read only.

HTH

Old Advance Man

  • Newbies
Posted

Thanks Steven!

The only trouble with StuffIt or ZipIt is that it would require a download and probably setting of some prefs in the browser/System. frown.gif" border="0 But good to remember for the future.

That right-click method just might work! I need to keep it as absolutely simple as possible. I now know I can change the file names via scripts. But the "properties" thing is strictly a Windows thing. I suppose I could include the info in the ReadMe along with the files. I also will see about adding that on the web page that I maintain with instructions.

Thought just occurred to me. I assume an error will be generated if a script tries to do a "Save as..." on a "read only" file. Anyone know if that is correct? If so, what error number? (I don't have a PC to test this on) Could use an error number trap to alert the user to use the right-click procedure.

On the other hand, if no error is generated, no other user steps are needed. The name changing scripts would setup the "new" files ready for action. laugh.gif" border="0cool.gif" border="0

Jim C.

Posted

...seriously,

We have been using WinZip self-extracting files to distribute FileMaker Runtime packages on CD for about 5 years and it has been working very well with no 'botched' installs. The self-extracting Zip file is set to run the Runtime EXE file (which then registers the runtime extension) after the files are copied. It allows us control of where the files are placed and avoids some of the serious pitfalls in aborted or botched install routines. The WinZip self-extracting file also makes it much easier for users than giving them instructions how to copy the files from the CD and then changing the 'read-only' properties.

  • Newbies
Posted

Thanks for the suggestion about WinZip. Of course, I will need this to be used from my Mac! I will do a search today for it. I do have a MacZip app, it may have that same capability.

Perhaps I overstated the need to "idiot-proof" this solution. That really is a rather harsh term to use. And I am certainly aware of feeling like one sometimes! I guess what I am really trying to do is make things as easy for the user as possible, trying to anticipate problems before (and especially after) they occur. As far as I'm concerned that's the second most important aspect of any solution!

Jim C.

Posted

Stuffit from Alladin Systems has both Mac and Windows versions of Stuffit Expander and Dropstuff. Obviously you will not be able to create a Windows self-extractor on a Macintosh, but at least it is a cross-platform archive format.

P.S. Both Stuffit and WinZip read just about any format (i.e. SIT, ZIP, ARJ, BIN, HQX, .Z, etc.)

  • Newbies
Posted

Please don't take this as an OS attack! I just love it when someone says "you can't do that on a Mac." Sorta like when they say, "You can't do that with FileMaker." crazy.gif" border="0

Anyway, I went first to Alladin and "registered" as wanting to know more about their Installer Maker, which purports to create both Windows and Mac installers. Been a few days and have heard nothing, probably because they don't want to mess with such a small time user!

Then I decided to search at VersionTracker and found "MacInstallerBuilder 2.0.5" Downloaded it and checked it out a little. You can "play" with it for 30 days but any installer will only work on the day you create it. Here is why I downloaded it:

quote:

"...build installers for any Mac, be it 68K/PowerPC,

Mac OS 7.5 to MAC OS X,...build installers for Windows 95, 98, ME, NT, XP."

I just got back from running the installer on a friends PC and can confirm that the ".exe" file works like a champ!

So, you can create installers for either "side" from and with only a Mac! At least two different ways! You probably know how to get to Alladin's site, here's a link for "MacInstallerBuilder"

This looks like exactly what I was looking for to make the users experience easy and simple. cool.gif" border="0

And thanks again for the tips and ideas! laugh.gif" border="0

Jim C.

[ January 07, 2002: Message edited by: Jim C. ]

This topic is 8354 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.