C-Command Software Forum

can I edit files outside of EF?

I keep my important web pages that I edit in a folder.
I made an alias of it for my finder side bar for easy access.

Can I make an alias of that folder (which is now inside EF) and edit the files like I usually do by going directly to them from the alias to the folder, and EF upate them properly with them being edited outside of EF?

Do you know if EF would garble any characters of BBEdit or Taco?

thanks
kim

Yes, you can edit the files directly from the alias/folder using your favorite editor.

There is one thing you should be aware of if you use EagleFiler’s Verify feature. If you edit the files using EagleFiler’s editor, EagleFiler will automatically update the checksum when it saves the file. If you edit the files outside EagleFiler, when you use EagleFiler’s Verify command, it will notice that the file has changed, and it won’t know for sure whether this was because you changed the file or because the file was damaged. You can then click the Update Checksum button tell EagleFiler that you changed the file on purpose. If you don’t use the Verify command, then this won’t affect you at all.

EagleFiler will auto-detect various Unicode encodings using the BOM (Byte Order Mark), and if there is no BOM it will assume the file is UTF-8. So, provided that you use a Unicode encoding or ASCII, everything will be fine. If the file is in another encoding such as MacRoman or Latin-1, the ASCII characters will display properly, but others might display garbled. The actual file would remain intact unless you edit it from within EagleFiler, in which case EagleFiler will save any changes that you make using UTF-8.

Verify, updating checksums, and the error window

One of the libraries that I’ve started keeping contains documents that people send me upon which they would like comments, and my usual method of doing this is opening the file in the external editor (generally, Word), inserting whatever comments I have, and then sending the file back to people.

After editing, though, I have to come back, hit verify (knowing that it’s going to fail), click OK on the resulting error window, usually move the tags window out of the way so it doesn’t obscure the error window, and then hit update checksum, move the tags window back, and then click back on the library window. It seems like a lot of clicking to do, though I like to perform the verify step just so that the checksums in the database are not out of sync.

Would it be possible to have an update checksum button that one could drag to the toolbar and just hit directly (bypassing the verify step)? I would assume that this wouldn’t be a very coding-intensive addition, but it reduce the steps from 5 to 1 for each document I comment on.

I might also vote for having the verify button provide feedback in non-modal way, though right now there isn’t a place for such feedback except in the error window.

And, now that I think about the error window, I have two more suggestions:

First, a clear button (so I can if I choose clear out old errors to make it more obvious which errors are new).

And second, when a checksum fails and update checksum is hit, updating the error message in the error window to reflect the fact that the checksum, though it had failed, has now been fixed, would be great. I often find myself hitting Update Checksum a couple of times because the visual feedback on the button click is not very visible, and I’m sometimes not sure if it “heard me” or not.

Yes, that’s on my list.

What do you suggest? I agree with the general idea, but I don’t think it belongs in the Errors window. It could throw up a non-modal “message” window, but I don’t think that’s common behavior among Mac apps except for Growl.

You can press Delete to clear the selected error, or use Customize Toolbar to add a Delete button.

Sounds good—thanks.

Well, you could post a Growl event for it, since EF is Growl-savvy anyway. And, actually, the only time that it wouldn’t be appropriate to put this information in the error window is if verification passes (although the modal window also contains the more global information about how many files were verified).

This may not really fit in with your UI vision, but you could put a little badge on the Verify button after verification happens (like on the Mail or SpamSieve icons in the dock). The badge might have a number that signifies the number of files checked, green if they all passed, yellow if some failed (and the failures will be in the error window). The badge should disappear, presumably, on the next action (selecting something in the library, an import from outside that causes a display update).

Ah, I hadn’t seen that. It doesn’t let you delete more than one at a time, but there aren’t usually a lot of errors in the window. The main case in which a lot of errors get thrown is when I import a folder of stuff that contains some duplicates, that was what I had in mind when I was thinking it would be nice to be able to clear them in one fell swoop. But the Delete button works fine for now.

What I was thinking was something like this (but with the badge either yellow or green, not red). And perhaps placed a bit higher. Perhaps while the badge is displayed, the checkmark should be grey rather than green.

http://www.bu.edu/linguistics/UG/hagstrom/pix/icon-badge.jpg

I’m not sure. It seems just a little bit weird as a way to provide feedback, since badges are usually used to encourage one to push a button, rather than to display information about what happened last time you pushed a button. Perhaps that’s too inconsistent.

I’ve added an Update Checksum menu command in EagleFiler 1.2, and if you wish you can use the Keyboard pane of System Preferences to assign a keyboard shortcut.