No over ride

[DGDanforth]

Folks,
I would like to start a discussion of what it would take to have the BlackBox Framework isolated from the users.
Currently System/Rsrc/Strings and System/Mod/Config do not satisfy that condition. One must copy those files and modify them to
add functionality. If one replaces those files without copying the contents then the old functionality is lost. That is wrong.

Or is it?

-Doug

[Zinn]

One problem is that we have different converter and different file extension.
The same file extension may open with different converter
and a converter can be used for more than one file extension.
Which is the best way to organise this?
Maybe we should select the converter separately and not via extension.
I would like to here other opinions about this topic.
- Helmut

[Josef Templ]

Folks,
I would like to start a discussion of what it would take to have the BlackBox Framework isolated from the users.
Currently System/Rsrc/Strings and System/Mod/Config do not satisfy that condition. One must copy those files and modify them to
add functionality. If one replaces those files without copying the contents then the old functionality is lost. That is wrong.

Or is it?

-Doug

There is already an isolation: use the /USE option.

- Josef

[Josef Templ]

Folks,
I would like to start a discussion of what it would take to have the BlackBox Framework isolated from the users.
Currently System/Rsrc/Strings and System/Mod/Config do not satisfy that condition. One must copy those files and modify them to
add functionality. If one replaces those files without copying the contents then the old functionality is lost. That is wrong.

Or is it?

-Doug

Why do you want to change System/Rsrc/Strings?
If you need new mappings then use your own Mysubsys/Rsrc/Strings.
If you really need to change it then you have to use the /USE option.

You can copy the Config source file to your own subsystem or any other directory and then modify and compile it.
The resulting files will be put into Code/ and Sym/ as opposed to System/Code and System/Sym,
where the original version is.
The newly produced files take precedence over the original version (if I remember correctly).
Thereby you can experiment with your own Config file without loosing the original.
If you detect a problem with your Config file simply remove it from Code/ and the original version will be used again.

- Josef

[DGDanforth]

I use /USE all the time. My initial desire to augment System/Rsrc/Strings was based on an incorrect understanding of how registering a converter in the Config
file worked. I wasn't seeing the entry text for my additions of "c", "h" and "csv" that I had added to my Config file. I would see "Text", "Text", and "Text" without the paring "(*.c)", "(*.h)" and "(*.csv)". That lead me to assume I needed to modify the Strings file. It seems I was wrong. When I now compile Config under CPC BB1.7 I now correctly see "Text (*.c)", "Text (*.h)", "Text (*.cvs)".

My gripe still rests on the need to create my own Config file and compile it.
If I had a Config file that functionally "merged" my converters with the System's converters then that might be better.
In that case I would not have to copy the System Config file.
Also, changing the Config requires that BlackBox be restarted for the changes to take effect. Why?
I would have expected (without thinking deeply) that converters should be dynamic and not static.

On Helmut's comment about different converters for the same extension: Haven't run into that case and need to think more about it.
-Doug

[Josef Templ]

My gripe still rests on the need to create my own Config file and compile it.
If I had a Config file that functionally "merged" my converters with the System's converters then that might be better.
In that case I would not have to copy the System Config file.
Also, changing the Config requires that BlackBox be restarted for the changes to take effect. Why?
I would have expected (without thinking deeply) that converters should be dynamic and not static.

Are you sure that it is static?
I would expect that it is already possible to add new converters any time later and in any modules.
My experiments seem to confirm that. There is no hint in the docu that it is static.

Please test this and report your findings.

- Josef

[DGDanforth]

Are you sure that it is static?
I would expect that it is already possible to add new converters any time later and in any modules.
My experiments seem to confirm that. There is no hint in the docu that it is static.

Please test this and report your findings.

- Josef

That's lovely!
I inhibited the Config versions I had been using (also had to delete the .ocf files) and created the command
MyConverters.Install.
I first checked what file types were listed by BB and then ran Install and checked again.
Indeed my added extensions were appended to the BB list.

Now, I don't thing very many people know about that. In fact here is what the BB documentation for Converters says

"The standard document converter is already installed by the BlackBox core. Other converters may be installed in the Config module, e.g., converters for ASCII files, Unicode files, or picture files. Config is executed upon startup of BlackBox to allow the establishment of custom configurations, such as the set of available converters."

From that one does not expect to be able to dynamically install from an arbitrary module other converters, but one can.
If one can install then one should be able to uninstall but I do not see any way to do that.
Later (it 5:30AM my time. I need to go to sleep) I will look into the source code of converters.
-Doug

[Josef Templ]

"Other converters may be installed in the Config module, e.g., converters for ASCII files, Unicode files, or picture files. Config is executed upon startup of BlackBox to allow the establishment of custom configurations, such as the set of available converters."

-Doug

This is misleading indeed.
What about this formulation:

Other converters are typically installed in the Config module, ...

Detail question to the native speaker:
Is the phrase "to allow" in the next sentence correct here or should it be
"in order to allow"? Or is there a difference between british and US english?

- Josef

[Robert]

Detail question to the native speaker:
Is the phrase "to allow" in the next sentence correct here or should it be
"in order to allow"? Or is there a difference between british and US english?

"to allow" is best. "in order to allow"? is ok, but it sounds a bit long-winded.

[DGDanforth]

I just posted a new topic in Features called Converters that shows the changes I think need to be made.

I, dearly wish I had known years ago that one could add converters without modifying the Config file.
I had several paying customers that used special file extensions that needed to be handled by BB.
In order to create an .exe file that could do that I had to kludge modifications of the Config file
by first copying Config.ocf file to a back up version and then compiling the user specific config
and using that file to generate the .exe after which the backup file was recopied to the
Config.ocf file.

All of that can now be removed and the user specific installation of converters done in any module
before access to the user specific files are needed.

Here is a list of subsystems in my BlackBox17 directory that have a Config file

Code: Select all

EarsConfig.odc	C:\Dgd\BlackBox17\Audio\Mod
Config.odc	C:\Dgd\BlackBox17\Fetal\Mod
MainConfig.odc	C:\Dgd\BlackBox17\Fetal\Mod
PackerConfig.odc	C:\Dgd\BlackBox17\Foo\Mod
BbConfig.odc	C:\Dgd\BlackBox17\O3\Mod
Config.odc	C:\Dgd\BlackBox17\O3\System
Config_min.odc	C:\Dgd\BlackBox17\O3\System
DiceConfig.odc	C:\Dgd\BlackBox17\ODesk\Mod
DiceConfigWas.odc	C:\Dgd\BlackBox17\ODesk\Mod
SelfConfigWas.odc	C:\Dgd\BlackBox17\Pac\Mod
Config.odc	C:\Dgd\BlackBox17\Tracking\Mod
Config.odc	C:\Dgd\BlackBox17\Usb\Mod
MainConfig.odc	C:\Dgd\BlackBox17\Usb\Mod

Notice the O3 and Pac (which I didn't create) uses a Config file.

Comments?
-Doug