Compatibility with 2bytes characters (unicode...)

Before submit a report via the technical support, I wanna listen to your opinion.
(I can't speak english very well.. I hope your generous evaluating.)

First issue.
When there are 2bytes characters in Command Editor, can't put cursor in correct position.
For example...when used this command, can't only point cursor but also write a word at the correct position.
(Type backspace at the end of line, you can see what happen ..)
Go "C:\Users\Opus\Documents\★★ Best ★★"
or
Go "C:\Users\Opus\Documents\새 폴더" ("새 폴더" means "new folder")

Second issue.
This is a very complex problem.
If there are 2bytes characters(Korean, Japanese, Chinese, special characters...) in the folder or file name, all MS-DOS Batch Function does not work properly.
so I should change all Unicode folder name to english or give up to use Dopus DOS commands.

I've tested some files with this command. (Attached sample files)
Folder : best
Files : 1-test.txt
2-☆ test.txt
2-☆ test ☆.txt
2-☆☆ test ☆☆.txt

@NOFILENAMEQUOTING
Select all
Echo #EXTM3U>"{sourcepath$|nopath|noterm}.txt"
Echo {file$}>>"{sourcepath$|nopath|noterm}.txt"

First two Echo commands works fine but last lines missing some characters.
and if there are 2bytes characters in folder name... temp bat file shows odd words and mixed up.

It doesn't happen in English OS because (i guess...) non-ansi characters ignored and replaced with questionmarks("?").
I've tried various chcp using @codepage, but it was not solved.
Should i ask advice from technical support?
Test_Files.zip (1.19 KB)

The first problem isn't due to two-byte characters (all UTF-16 Unicode characters are two-byte, except ones which are even longer).

I think it's due to font linking being required to display those star characters, and ending up using characters from a font whose width is different to all the others. (Or something like that.)

The button editor expects to be using a monospaced font but those characters mean it effectively isn't.

Might be worth reporting to GPSoftware to see if they can fix it.

The second problem is somewhat inherent with anything that calls out to MS-DOS. MS-DOS isn't a Unicode environment so you have to use a DOS codepage which can represent all the characters you want to use.

For a given codepage, Opus will attempt to convert characters from UTF-16 into the chosen codepage when writing the .bat file, but that's only possible if the codepage can represent them.

Also note that loading .bat files into Notepad is expected to show the wrong characters unless Notepad is set to convert them from the same codepage. That's nothing to worry about.

Thanks for your advice.
I'll report First problem via technical support...
and second one..

Codepage 949 (ANSI/OEM-KOREAN) is default in Korean OS and DOS shows all the korean characters (and the stars ★) exactly.
Everything is OK if i fix dopxxxx.bat file manually that Opus converted and run it(added cut offed quote, characters at the end of line).

presumably codepage does not matter but Opus doesn't get the file path except first two lines of command.
(screenshot #3) Two Echo commands are fine, but next line cut offed 1 character(quote), next one missed 2 characters(t") and next 4 characters(txt")...if there are more files, it continuingly happened (t.txt") (est.txt")

I'm actually using Notepad2 and just used window notepad for screenshot in vmware(Eng Win7 installed). The wrong characters are still the same in other codepage.
I couldn't reproduce this problem on eng OS, so it's too hard to explain.

You can override the DOS codepage that Opus uses using the @codepage modifier.

Try @codepage 949 on a line at the top of the command/button.

didn't you see the screenshot? chcp 949 > null already there...korean OS uses DOS codepage 949 by default so it's not necessary to add another modifier.
and this is not a codepage problem but the directory recognition of Opus.
Of course, I know that few asian users seem to be buying Opus but I hope generous offer for non-english fans. :frowning:

[quote="nelly"]didn't you see the screenshot? chcp 949 > null already there...korean OS uses DOS codepage 949 by default so it's not necessary to add another modifier.
and this is not a codepage problem but the directory recognition of Opus.
Of course, I know that few asian users seem to be buying Opus but I hope generous offer for non-english fans. :frowning:[/quote]

Open a command prompt via the start menu and then run the chcp command. Which codepage does it report? It may not be 949. If it's something else, try putting that at the top of the command using @codepage.

Opus adds a chcp command to make the DOS codepage match Opus itself*, using 949 in your case, but that may not be the same as the default codepage for DOS on your machine.

GUI programs and DOS tend to have different default codepages.

(* Opus is a unicode app so codepage is usually irrelevant, but it becomes important when Opus has to convert text from UTF-16 into something else, such as when writing out a .bat file.)

Oh leo please~ I wasn't born yesterday, you know.
Here is screenshot. There's no mistaking that Active code page is 949.

Ocne again, It's no use to using @codepage xxx. i've tried all the codepages.

Of course Opus supports unicode....(I think it doesn’ t look perfect). In addition there's more compatibility issue like MP3 plug-in.
I labored for weeks on this dos command. How do you conclude that is not problem of Opus itself?
Just how is it possible that Opus unable to handle such a simple command.
echo test-message>>"123.txt"

Sorry, looking at it again I see I misunderstood what was going wrong.

Yeah, there's definitely a bug there with multi-byte characters. (That is, ones which take up two bytes even after conversion into the DOS codepage, where they're usually one byte.)

I wanted to hear that.
I appreciated your concerning.

Regards,
nelly.