Script, UI, etc

[B2C]

1)
Script running will reset the column settings of the default Folder Compare view.
Before script running:

After script running:


2)
I use a script to rename files in a ZIP archive. It works very well with BC2.
Now to work with BC3, I converted the encoding of the script file to UTF-8, right? But there still has some problem:
If RENAME operation encounters double-byte characters, the relevant files will always be corrupted. Though they look like having been renamed correctly, I will get a failure when trying to unzip them.

3)
Hope the position of the script window can be remembered like BC2 does.

4)
In script window: Cannot scroll the text with the mouse wheel if the focus is not in Log tab. (No such problem in Script tab.)

[Aaron]

1) Could you send a copy of your script to [email protected] ?

2) If rename finds a double byte character in the name of the file, or if the output would have a double byte character. I see an error message in the log when I attempt to use some chinese double-wide characters. Would you be able to email an example of this (perhaps a zipped file already containing a double-wide character)?

3 & 4) Thanks for the suggestions. I will look into this behavior.

[B2C]

Here's a simple sample that can reproduce both issue 1 & 2.

Only one DBC [－](U+FF0D | ANSI:A3AD) is used. (More DBCs tested, same result.)

After the script job finished successfully without any error message in BC's log, only one file ( [email protected] ) can be extracted from BC3.zip.

Stuff & Descriptions:
original.zip
BC3.zip (Processed by BC3, corrupted.)
BC2.zip (Processed by BC2, OK.)

script_BC3_U8s.txt

load "E:\test\BC3.zip"
#filter "*.*"
select left
rename regexpr (^[^a-z\d]) +$1
rename regexpr (^[a-z\d]) －$1

[Aaron]

Hello B2C,

The BC3.zip is already corrupt; I assume you want the script run on the original.zip. For me running your script on original.zip works fine, and does not change the Columns of the default Folder Compare.

Are you running the newest version of BC3? Are you able to email your support package to [email protected] ? It may be related to a specific setting configuration.

[B2C]

Today I updated BC3 from 3.1.2.10221 to 3.1.3.10374 and found issue 1 fixed.

Issue 2 still exists.
I ran BC3 with all Factory Defaults, but got the same result.
Anyway, my support package has been sent.

Yes, BC3.zip is corrupt. It's the result processed by BC3. I submitted BC3.zip for I thought you could compare it with the correct result in Hex view to find the reason. I compared them and found that:
When writing into the zip archive, BC3 marked the wrong length of the file names by miscounting the length of a DBC as 1 byte. For example:
+－－－.txt (including 3 DBCs)
BC2 marked as 0B (in Hex).
BC3 marked as 08 (in Hex).
(Please look into test_new.zip.)

"For me running your script on original.zip works fine."

Did you try extracting the files after script running?

I think it's also related with this:
http://www.scootersoftware.com/vbull...ead.php?t=3720

Another related issue:
I hope the right (ASCII) area of BC3's Hex view can display Unicode characters as BC2 does.

[Aaron]

Hello,

Yes, WinRAR has a handy "Test" function, and I've tried extracting them.

Let me go over what I'm doing and maybe that will help.
You have 3 files: original.zip, bc2.zip, and a corrupt bc3.zip
The script refers to bc3.zip, which is already corrupt. So any function on it will result in a corrupt file.

I edit the script to point to e:\test\original.zip instead, and run it. I then Test/Extract e:\test\original.zip and it seems to function correctly.

Did you intend for the script to function on the BC3.zip?

[B2C]

I'm sorry I didn't describe my procedure step by step:
Copy original.zip to E:\test\ and rename it as BC3.zip. Then run the script.

(My BC3.zip and BC2.zip I submitted are already my script results and only for comparing.)

So our procedures were actually the same thing.
I checked all the things again and confirmed that I did NOT run the script on a corrupt file.

Now I'm more puzzled why I got the incorrect result. Is a DBC (like U+FF0D) always 2 bytes on different OSs?

[Aaron]

B2C,

I talked with one of our developers, and I was able to reproduce this once I changed my system code page. I've created a tracker entry so we can figure out what may be causing this issue.

Thanks for your patience while we troubleshot this.

[B2C]

So glad you found the reason. Thank you.
Let me know if more info is needed.

Could you please give a reply on this issue?

Another related issue:
I hope the right (ASCII) area of BC3's Hex view can display Unicode characters as BC2 does.

[Aaron]

Could you send in a pair of screenshots demonstrating the issue you are running into?

[B2C]

Sorry. My description about the Hex view was not correct. The ASCII area of the Hex view can not display Unicode characters. What I see in BC2 are ANSI double-byte characters according to my system default code page.

As the screenshot shows, in BC2, I can recognize some of the text. This is helpful.

But BC3's Hex view always displays ASCII using CP-1252, ignoring the user's system default code page.

Do you have any plan to add more choices in the Encodings dropdown in Hex view? If no, I think it would be better to display ASCII using the system default code page.

[Aaron]

Thanks, B2C.

I've added this to our wishlist.

[B2C]

Rename issue in a zip folder if double-byte characters are involved

About the Rename issue:
Later I tested to rename files manually in zip folders. The issue also occured. It proved that the issue had nothing to do with the script function. So please bother to move this thread to the proper forum if you think it should. And I think the subject should be:
Rename issue in a zip folder if double-byte characters are involved
And I hope this issue will be fixed soon.

[Aaron]

Thanks, B2C. I've added your notes to the tracker entry.