Yeah, that makes sense. I forgot to move them back into the to-be-zipped folder, from what I see in my code. Anyways, it's too retarded to properly copy a folder, so I'm just going to create the root dir, then go through, processing files with resource forks and creating/recursing through folders as applicable.

In what way does dropping folders not work? Does it simply not accept them (i.e. highlight in the Dock/Finder)? If so, I'm not sure if there's a way for me to get around it, but if you hold down apple-option it should work.

Anyhow...still working on the next version. Stay tuned.

orcaloverbri9, on Jan 8 2006, 04:14 AM, said:

Anyways, it's too retarded to properly copy a folder,
View Post

Eh?

orcaloverbri9, on Jan 8 2006, 04:14 AM, said:

In what way does dropping folders not work? Does it simply not accept them (i.e. highlight in the Dock/Finder)?
View Post

The app opens for half a second and closes again. It works if the app is already open though.

Guy, on Jan 8 2006, 03:43 PM, said:

It works if the app is already open though.
View Post

Which puts the usefullness of your app right around the level of Guy's script -- the one that you set out to best.... :rolleyes: Keep working, though, orca! When you get it, it'll be darn sweet.

This post has been edited by Dr. Trowel : 08 January 2006 - 06:00 PM

Guy, on Jan 8 2006, 03:43 PM, said:

Eh?

RB is too retarded to comprehend copying a folder...but copying files works fine. <_<

Quote

The app opens for half a second and closes again. It works if the app is already open though.

s###. That shouldn't happen.

...and I don't see why it would. <_<

Does it create the temp folder? If so, is there anything inside of it?

This post has been edited by orcaloverbri9 : 08 January 2006 - 06:08 PM

Good news! I found the culprit of the quit-when-opening-a-folder-by-drag-and-drop bug. See, I was using the same routine (with different parameters) for processing files and encoding files when processing folders. This routine checked to see if the application was opened by drag-and-drop and the appropriate preference was set to true. So, it's quitting after the first file that it sees that should be encoded. Guy, I think you'll find that turning this preference off will provide a temporary fix.

...anyways, it's been fixed. I'm mostly done with this update. What I've done:
- The above fix
- Folder recursion should now finally work
- Now uses the system temporary folder (still uses the same destination folders, though)
- Should be much faster - a product of upgrading to the new version of RB

Stay tuned, folks.

This post has been edited by orcaloverbri9 : 09 January 2006 - 07:41 PM

Plug-in Archiver v1.0.5 is out!

A quick recap of the changes in this version:
- Upgraded to RB6, so it should go a lot faster.
- The two naming options should have their proper names in the preferences window.
- Should now correctly archive folders when opened by drag-and-drop.
- Folder recursing should now work.
- Now uses the system temporary folder.

As for the whole too-stupid-to-copy-a-folder thing, it seems it's just unable to copy to a folder with a . at the beginning. Regardless, the way it does it at present works (and is probably more efficient) and I'm not about to change it.

Can we get some new benchmarks, Guy?

This post has been edited by orcaloverbri9 : 12 January 2006 - 12:33 AM

Though I am currently busy beta testing a certain game, I have just downloaded this latest version (which at last begins to be satisfying for end-users, not just early-adopters-who-like-to-work-around-bugs) and I'm going to test it extensively. Be prepared for heavy criticism (Guy can vouch for this...) in a few hours - days at most.

Can't test speed yet because...
Processing folders doesn't encode files!
Also, if a zip archive of the same name already exists then it gets blatantly overwritten.

On a side note, I checked out my own script on a Panther machine and got thoroughly confused. I decided the only solution is to remove the app check. So just to satisfy me, see if it works now - it'll probably ask you to locate NutCase on the first launch but I'm sure that'll be okay.

This post has been edited by Guy : 08 May 2006 - 07:49 AM

Can't wait, Zacha.

Umm...doesn't encode files?!? That's not cool. It definitely should not be happening. I'll investigate when I get time.

orcaloverbri9, on Jan 13 2006, 04:29 AM, said:

Umm...doesn't encode files?!? That's not cool. It definitely should not be happening. I'll investigate when I get time.
View Post

Yes, unfortunately it doesn't MacBinary encode files when you ask it to process a folder (whichever way you ask it to do so), however processing a single file is fine (in fact I used it for the tease Rezilla template, in the "Plug development on an Intel Mac" topic). As you can guess the test ended real quick. Unfortunately, contrary to an AppleSript based solution, we can't debug ourselves.

Yeah. I've tested and proved it myself. Now for the real question...

WHY?

EDIT: Okay, yeah, so I'm a ######ing moron. I passed the zip function the original folder instead of the temporary one.

Oh, by the way, I know it overwrites. It didn't seem like a big deal. I can have it take measures to prevent the user unknowingly overwriting if it bothers you.

This post has been edited by orcaloverbri9 : 16 January 2006 - 10:54 PM

Well.

It's failing to ecnode now because for whatever reason it can't create the file in the temp folder. That = bad.

This post has been edited by orcaloverbri9 : 17 January 2006 - 12:58 PM

New version!

- Processing folders now encodes files appropriately
- Added status thingies so you know what's going on (sorry, no progress bar)
- Rearranged the main window to better accomodate status thingies

Get it here.

Can we get some speed tests now, Guy?

This post has been edited by orcaloverbri9 : 19 January 2006 - 11:35 PM

Okay, it seems to work now and I can also test the recursion
Source: "EV Nova 1.0.9" (184.9MB)
Plugin Archiver: 1:30
Plugin Archiver Deluxe: 1:03
Plug-in Archiver: 6:39
Must have had less processes running this time. Doesn't seem to be a noticeable improvement.
Whoops, something must be wrong with your encoding. After expanding the archive the EV Nova app does not work - the data fork is too small (though of course people are unlikely to be including apps in their plug distribution).
And sorry to make you eat your words but the music file also does not work because it was not encoded and the codes were lost (my script is guilty of the same thing :rolleyes:).
Your app .bins Icon files while my script doesn't but I when expand either archive, neither show the folder icons.

(EDIT): One other odd thing I noticed - the resource ID it's reading usually seems to start from the bottom and go constantly up to the top but sometimes it goes up and down (within the same file and same resource type). Is this expected?

This post has been edited by Guy : 20 January 2006 - 04:44 PM

Guy, on Jan 20 2006, 04:21 AM, said:

Okay, it seems to work now and I can also test the recursion
Source: "EV Nova 1.0.9" (184.9MB)
Plugin Archiver: 1:30
Plugin Archiver Deluxe: 1:03
Plug-in Archiver: 6:39
Must have had less processes running this time. Doesn't seem to be a noticeable improvement.

Ah well. That's the price you pay for having built-in .bin support. You may have noticed that it takes a while when "Writing encoded file...".

Quote

Whoops, something must be wrong with your encoding. After expanding the archive the EV Nova app does not work - the data fork is too small (though of course people are unlikely to be including apps in their plug distribution).

I'll look into it, but it's not a high priority.

Quote

And sorry to make you eat your words but the music file also does not work because it was not encoded and the codes were lost (my script is guilty of the same thing :rolleyes:).

True, but in that post what I really meant was that it wouldn't .bin on Windows because it won't preserve the creator and type codes of a file without a resource fork.

Quote

Your app .bins Icon files while my script doesn't but I when expand either archive, neither show the folder icons.

Are you sure that's not just OS X? Often, it doesn't refresh the icon until you modify the folder. Try moving it or creating a file in it.

Quote

(EDIT): One other odd thing I noticed - the resource ID it's reading usually seems to start from the bottom and go constantly up to the top but sometimes it goes up and down (within the same file and same resource type). Is this expected?

shrugs It's just the order the resource manager (or ResEdit) put them in.

orcaloverbri9, on Jan 20 2006, 11:16 AM, said:

Ah well. That's the price you pay for having built-in .bin support. You may have noticed that it takes a while when "Writing encoded file...".
View Post

Actually no, that flashed by in a split second. What I did notice is that it slowed down as it progressed through file. The misns would at first flash by really quick but they gradually got slower.

orcaloverbri9, on Jan 20 2006, 11:16 AM, said:

Are you sure that's not just OS X? Often, it doesn't refresh the icon until you modify the folder. Try moving it or creating a file in it.
View Post

Hm, nothing I do will make it appear in the Finder but if I open the folder with an icon app then it shows the icon. Meh, doesn't really matter.

orcaloverbri9, on Jan 20 2006, 11:16 AM, said:

shrugs It's just the order the resource manager (or ResEdit) put them in.
View Post

Okay, I was just worried it might be reading the same resources twice.

Guy, on Jan 20 2006, 09:21 AM, said:

Your app .bins Icon files while my script doesn't but I when expand either archive, neither show the folder icons.
View Post

Maintaining folder icons is completely impossible for .bin.zip archiving; for the interested, that's because, just like files, folders have Finder Info data associated to them, and one flag in this data is "has custom icon". Contrary to files, there is no way in heck to have the folders ".binned" or some other such thing to keep the Finder Info for folders, Sorry. That's one point where .sitx is still superior.

Guy, on Jan 20 2006, 06:22 PM, said:

Actually no, that flashed by in a split second. What I did notice is that it slowed down as it progressed through file. The misns would at first flash by really quick but they gradually got slower.

That's probably because it stores the resource fork in memory, so it can use upwards of 15MB.

Odd, though...it takes longer to write the .bins than anything else for me.

Zacha Pedro, on Jan 20 2006, 08:47 PM, said:

Maintaining folder icons is completely impossible for .bin.zip archiving; for the interested, that's because, just like files, folders have Finder Info data associated to them, and one flag in this data is "has custom icon". Contrary to files, there is no way in heck to have the folders ".binned" or some other such thing to keep the Finder Info for folders, Sorry. That's one point where .sitx is still superior.

So...I should have it ignore the icon files, since they don't have any real point?

This post has been edited by orcaloverbri9 : 20 January 2006 - 09:02 PM

Aha. Though the reason my script doesn't .bin the icons is because most applescript commands ignore invisibles.

orcaloverbri9, on Jan 21 2006, 01:51 AM, said:

Odd, though...it takes longer to write the .bins than anything else for me.
So...I should have it ignore the icon files, since they don't have any real point?
View Post

Well, this isn't a big problem, so you might as well leave it as it is. In fact, if you fire up ResEdit (oh, my, still ResEdit... I wonder how we'll be able to live without it), do "file/folder info" on the expanded folder, and check "use custom icon", it will appear.

I tested it, as so far it works great, if a little slow. I have packed rEV with it, unpacked it with Stuffit, and compared files. For data fork-based files (ReadMes and such), it's easy to compare at the binary level with HexEdit. However, for resource files they are not identical on the binary level, but in fact resources are just in a different order and using Rezilla I have been able to confirm they are identical. Now, I have a question: why do you extract resources one by one from resource forks, to put them back in a .bin file, in a different order most of the time? Can't you just get access to the resource fork as a whole, raw stream of bytes, to put it in the .bin file? This would likely be faster, and more reliable. But RealBasic might not allow you this.

As for the matter of Nova Music, keep doing what you're doing for now. That is, don't .bin it. I will decide on the best way to act later.