issue-#18: Adapting Dialog.version for future center release

[Josef Templ]

I have created issue-#18 as a request for updating Dialog.version.
See http://redmine.blackboxframework.org/issues/18.

In order to resolve this issue once and forever, I would like to propose to generalize
Dialog.version from a 2-digit INTEGER number to a string that can hold any version name.
That string can then be set automatically to the System property 'appVersion'.

It needs to be discussed if it is required to set it to the 'major' version number only (e.g. 1.7)
as defined in the documentation of Dialog.version or to the full version name (e.g. 1.7.2, 1.7-a1).
My preference would be to use the full version name.
Is anybody using Dialog.version for a specific purpose?

Updating Dialog.version is CPC change list number 62.

- Josef

[DGDanforth]

Using GftSearchFiles on the directory Mod I find

Location
Host/Mod/Registry.odc
Dialog.version [1]
Host/Mod/Windows.odc
Dialog.version [2]

where

Code: Select all

		Dialog.appName := name$;
		Dialog.version := 16;
		Dialog.Call("Startup.Setup", "", res);
		ReadMeasure
	END Init;

BEGIN
	Init
END HostRegistry.

and for HostWindows

Code: Select all

		IF Dialog.appName = "BlackBox" THEN
			str := Dialog.appName$;
			ver := " x.y";
			ver[1] := CHR(Dialog.version DIV 10 + ORD("0"));
			ver[3] := CHR(Dialog.version MOD 10 + ORD("0"));
			Append(str, ver);
			Dialog.ShowStatus(str)
		END;

[Josef Templ]

There is also the option to ADD a new variable 'appVersion'
and to LEAVE 'version' as it is, i.e. as the major version number
expressed as an integer number.
This would have the advantage that it does not change anything but only add a new feature.
appVersion would be a string and it could be used instead of version for displaying
the current BlackBox version in the status bar after starting BlackBox.

in Dialog:

Code: Select all

  version*: INTEGER;
  appVersion*: ARRAY 32 OF CHAR;

in HostRegistry.Init:

Code: Select all

   Dialog.version := ... extracted from System property appVersion
   Dialog.appVersion := ... extracted from System property appVersion

in HostWindows.CreateMainWindows:

Code: Select all

   Dialog.ShowStatus(Dialog.appVersion);

Any comments?

Please note that this issue should be resolved BEFORE continuing with
more changes form the CPC 1.7 change list in order to avoid merge conflicts.

- Josef

[Josef Templ]

A proposal for issue-#18 has been added to the topic branch issue-#18.

I tried to be fully compatible with all existing programs and therefore I
added the new variable Dialog.appVersion, which holds the full version information
according to the System property 'appVersion'.
The only visible change is the status bar message after start-up of BlackBox.
If an unstable release such as 1.7-a1 is started it displays 'BlackBox 1.7-a1',
which is more informative than displaying only the major version number
as it was done previously. In addition this simplifies the creation of the status bar message
and it removes the restriction of using 2-digit version numbers.
Dialog.version is set automatically to the integer xy if appVersion follows the pattern "x.yz"

Please have a look at the differences in
http://redmine.blackboxframework.org/pr ... 91b914d590

- Josef

[Zinn]

Josef,
your solution about appVersion works perfect. A new version of BB deliver an other entry in the System/Rsrc/Strings.odc.
I like this solution. But now I have a problem with it.
Changing the language uses another Strings files in the directory System/Rsrc/xx/Strings.odc
where xx is the directory of the chosen language and probably the wrong version is displayed.
Who can suggest a solution about this kind of problem?
- Helmut

[Josef Templ]

This problem will also appear in the About dialog when the multi-language feature is added.
So it is not strictly related to the automatic handling of the version information.

A possible approach would be to introduce the multi-language feature similar to Java resource bundles,
where there is always a default language as a fall-back and incrementally there may be more specific
resource files for more specific languages. In Java there is even a hierarchy of such refinements
- language
- country
- variant

In order to solve the problem at hand it would be sufficient to support
one refinement level: the default is always stored in System/Rsrc/Strings,
a translation for language x is stored in System/Rsrc/x/Strings.
If a key is not found in System/Rsrc/x/Strings the search continues
with System/Rsrc/Strings. The same principle is applied to all subsystems, of course.
I have not looked into the implementation details.
It will probably be more complicated but the advantage would be that it also supports
a partial translation of resources.

A detailed discussion should be done in a separate topic for the multi-language feature.

- Josef

[Zinn]

Right this is one solution: If we left out in the language directories xx in the Strings files
the entries of appVersion, buildNum & buildDate then it works in the CPC edition.

I have no solution if you start BlackBox like D:\BlackBox\BlackBox.exe /use "D:\Project"
and in Project\System\Rsrc\ is a Strings.odc file.

Helmut

[Josef Templ]

This means that it already works this way in principle.
As you mentioned, there is a bug when using /USE D:\Project.
The bug, however (or is it a different bug), appears when
there is a file in Project/System/Rsrc/xx/Strings.
The available languages are not detected correctly, i.e.
xx is simply ignored.

By the way: HostDialog.CollectAvailableLanguage should be a plural word.

- Josef

[Josef Templ]

My mistake. I used the /USE option incorrectly in my test
(I forgot to put double quotes around the directory name).
As far as I see the language detection works correctly.

Regarding your test case with /USE D:\Project:
If you overwrite the System/Strings file in the /USE directory,
then you get what you put into the new System/Strings file.
There is of course no incremental merge of the two files
and there is no need to do it.
(BTW, did you put the double quotes around the directory name in your test?)

Regarding the handling of the version information, I think we can
safely ignore the multi-language issue.

- Josef

[Zinn]

Yes, I'm agree. We can leave it as it is. I used the double quotes in my tests.