BlackBox Framework Center

Josef Templ wrote:I did not have the time to look into the details of the implementation yet,
so I really don't know what version 0 or 1 or 2 means. Anyway, I am surprised
that this issue has not been fixed in CPC 1.7.

- Josef

The only difference between 0 and 1 is that version 1 is storing "close state" of link. This "close state" (v.close) regulates the behaviour about closing or not closing the document after link is pushed. So using of 1 instead of 0 for leftSide link not only simplify export, but also make the import faster. In case of 0 it should be calculated by analysis of link content, in case of 1 — it is simply read.

Ivan Denisov wrote: 0 - default behaviour: close window if shift is down, never close if link contains ShowTarget (not storing v.close);
1 - unusual behaviour: always close window or never close (storing v.close state);
2 - always storing v.close state and storing v.cmd as widechars;

The question is: Need we state 0 really ?

When the answer is no we can simplify the export by using state 1 and 2 only.

When the answer is yes then our solution is wrong, because we need 4 states:

0 - default behaviour: close window if shift is down, never close if link contains ShowTarget (not storing v.close);
1 - unusual behaviour: always close window or never close (storing v.close state);

2 - always storing v.close state and storing v.cmd as widechars;
3 - same as 0 except storing in widechars

regarding the version 0 'optimization':
I would follow Chris' suggestion here: make changes only if you solve a problem.

This is a subtle change that needs a lot of thinking in order to verfiy that
it does not change the observable behavior.
Nevertheless, it changes a .odc file even if there is no change in the contents.
This means that git would show a change but a text comparison does not show any changes.
In addition, this is a change that is not related to supporting unicode characers.
It may be true that the change is only a problem for very old BB versions, but is it worth
to spend our time on such optimizations?
A lot more cosmetic changes could be made in this module but what for?

- Josef

I agree with Josef, that this reduction does not related with bugfix and also will change binary files. So I can roll back after some more discussion.

Nevertheless there is strong desire to make code more simple by cutting rudimentary stuff. This can be done after all known fixes applied. For example old Ctl bindings or this 0 version...

Zinn wrote:The question is: Need we state 0 really ?

When the answer is no we can simplify the export by using state 1 and 2 only.

When the answer is yes then our solution is wrong, because we need 4 states:

0 - default behaviour: close window if shift is down, never close if link contains ShowTarget (not storing v.close);
1 - unusual behaviour: always close window or never close (storing v.close state);

2 - always storing v.close state and storing v.cmd as widechars;
3 - same as 0 except storing in widechars

For me the answer must be yes.

Is there a difference between 2 and 3 that can be observed by the user?
If no, why do we need them?
If yes, can you give an example?

- Josef

We are running in a circle with this discussion.
So let me start again from the beginning:

The Externalise of Link in BB 1.6 has the following structure: I change this in the CPC Edition to Iwan analysed it and said that the CPC solution is wrong. The hasWideChars comparison must be come first: Now I said when Ivan's argument is right then this can be simplified to and my question was: Need we the comparison with some rules and version = 0?
If this answer is yes Ivan's solution is wrong too.

Helmut
Turing S Spain on my motor bike with a small tablet, so can't really concentrate on this. But isn't the issue the same as the changes we suggested for StdStamps. The new code should be able to read old 8-bit, but always write 16_bit without testing if it needs to?

Robert, yes it is. With your rules the result will be

Roman found the Oberon/F distribution
ftp://ftp4.gwdg.de/pub/languages/oberon/OberonF
(Mac version also there)

Oberon/F 1.1 beta supports links and can open files from 1.6 version well.
There are no sources available, however I am sure that it uses 0 version.
So we can keep 0 version for back compatibility with Oberon/F 1.1 beta

The rules are simple and follow from the history:
version 0: no close flag stored, Ascii-Cmd
Version 1: close flag added, Ascii-Cmd
Version 2: Unicode-Cmd instead of Ascii-Cmd, close flag REMAINS as in version 1.

The applied strategy in BB1.6 is that although it supports version 1 it stores it as version 0 if possible.
This is for the sake of compatibility. As long as the version 0 behavior is sufficient it is not
used in the storage format and older BB versions can still read the document.
The same principle applies to our current release. It falls back to storing version 1 or even 0
if the new version 2 feature (Unicode) is not needed.

I think Ivan's first version (without the simplifications) is right.
There is no need to introduce another version with Unicode-Cmd but without the close flag.
Why? Because they would behave in the same way. There is no observable difference
and introducing another version code would only complicate things (correct me if I am wrong here).
There is no need to think about backward compatibility in case a Unicode-Cmd is used
because this is incompatible anyway. Having a version 3 would also be
strange in the sense that we would introduce two new versions (2 and 3) at the same time.

If anybody worries about code replication of the HasWideChars procedure:
this could be put into Strings and be reused in StdLinks etc.

- Josef