BlackBox Framework Center

http://redmine.blackboxframework.org/issues/57

If you select some Unicode text and call for interface from popup menu in a case with unexisting module the error message will have wrong encoding. The proposed fix is simple conversion:
http://redmine.blackboxframework.org/pr ... rowser.odc

The version for testing:
http://blackboxframework.org/unstable/i ... a1.172.zip

Dear Ivan.
I propose to add the following changes to the MODULE DevBrowser too:

1. In the PROCEDURE Browse
exchange line
ELSE str := mod$; str1 := ident$; title := "";
against
ELSE Kernel.Utf8ToString(mod$, str, res); Kernel.Utf8ToString(ident$, str1, res); title := "";
and

2. In the PROCEDURE ShowCodeFile
exchane line
str := mod$;
against
Kernel.Utf8ToString(mod$, str, res);

I hope that helps.
Helmut

Thanks, Helmut, I added these changes.
http://redmine.blackboxframework.org/pr ... 5&type=sbs

New version for testing:
http://blackboxframework.org/unstable/i ... a1.173.zip

Please use Strings.Utf8ToString/StringToUtf8 everywhere instead of Kernel.

- Josef

Josef Templ wrote:Please use Strings.Utf8ToString everywhere instead of Kernel.

Josef, in this module Kernel.Utf8ToStrings used everywhere...
Are you sure, that we need to change all of this entries?

It's a cosmetic change without any difference in the behavior.
But Kernel should not be used unless required. And here we have well-documented
high-level operation in Strings, so why should we dive into undocumented Kernel operations?
(my fault, I should have looked more carefully into the code in issue-#19).

BTW, this issue refers in reality to issue-#19.
I am not sure if it is correct to introduce a new issue number
in case of fixing something that already has a well-defined issue number.

- Josef

Josef Templ wrote:It's a cosmetic change without any difference in the behavior.
But Kernel should not be used unless required. And here we have well-documented
high-level operation in Strings, so why should we dive into undocumented Kernel operations?
(my fault, I should have looked more carefully into the code in issue-#19).

I did not understand, should this "cosmetic change" be performed or we can leave as it is?

Josef Templ wrote:BTW, this issue refers in reality to issue-#19.
I am not sure if it is correct to introduce a new issue number
in case of fixing something that already has a well-defined issue number.

I thought about this, the #19 was the feature, and now it is the bug in the feature implementation, so it is better to make new number. Or it will mean that every member can continuously improving features without voting. This is new code, so it should be accurate voting again. Each voting is better to has separate issue number.

Josef Templ wrote:It's a cosmetic change without any difference in the behavior.

Except for linking. Kernel is in the link list anyway, but you have to add Math and Strings when you introduced Strings in your module.

Here is an example: In BB 1.6 I can link
DevLinker.Link Abgleich.exe :=
Kernel$+ Files HostFiles HostPackedFiles StdLoader
1 Applogo.ico 2 Doclogo.ico 3 SFLogo.ico 4 CFLogo.ico 5 DtyLogo.ico
6 folderimg.ico 7 openimg.ico 8 leafimg.ico
1 Move.cur 2 Copy.cur 3 Link.cur 4 Pick.cur 5 Stop.cur 6 Hand.cur 7 Table.cur

But in BB 1.7 I have to add Math and Strings in the above list because HostPackedFiles uses Strings instead of Kernel.

Here is an open point for discussion. I'm not sure which way to prefer - using Kernel or String. It is an internal translation.

Ivan Denisov wrote:I thought about this, the #19 was the feature, and now it is the bug in the feature implementation, so it is better to make new number.

Without #19 this bug does not exist. The bug is the result of an incomplete implementaion of #19. So the solution beyond to #19.

It make no sense to vote yes for #19 and no for #57, because I won't have an incomplete errornous implementation.

With 'everywhere' I mean everywhere in DevBrowser.
This issue is about DevBrowser, isn't it?
Now we have mixed usage within DevBrowser.

- Josef