issue-#180 fixing resource lookup in OleClient.PasteSpecial

User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#180 fixing resource lookup in OleClient.PasteSpec

Post by Josef Templ »

There is one remaining small question with DevInspector now.

The current resource lookup strategy of DevInspector differs slightly from OleClient and HostDialog, etc:
It uses a key without the subsystem when looking in a subsystem other than Dev.
Technically, there is no problem, but you may find it confusing to have different conventions.

I have not seen this feature used anywhere (except in a future 'Ctls'), probably because it is not widely known
and it is only relevant for controls that use the standard inspector dialog as a property editor.
Therefore it may be possible to align this behavior, i.e. to use a fully qualified key, including the subsystem,
for DevInspector properties.

Is this DevInspector feature used by oberoncore or anybody else or n other CPC packages?

- Josef
Zinn
Posts: 476
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main
Contact:

Re: issue-#180 fixing resource lookup in OleClient.PasteSpec

Post by Zinn »

The only other sample I know is subsystem Coco with

Insert into the procedure "Setup" of the module System/Mod/Config.odc the following lines:
Converters.Register("CocoConv.ImportAtg", "CocoConv.ExportAtg", "TextViews.View", "atg", {});
Converters.Register("CocoConv.ImportFrm", "CocoConv.ExportFrm", "TextViews.View", "frm", {});
and compile

Coco/Rsrc/Strings.odc
STRINGS
CocoConv.ImportAtg Coco/R Attributed Grammar
CocoConv.ExportAtg Coco/R Attributed Grammar
CocoConv.ImportFrm Coco/R Frame
CocoConv.ExportFrm Coco/R Frame

But I think it is not the same situation.

By the way Robert's Rich Text Converter CasketRtfConv based on HostTextConv BlackBox version 1.5 and have not the the changes from HostTextConv 1.7

- Helmut
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#180 fixing resource lookup in OleClient.PasteSpec

Post by Robert »

Josef Templ wrote:... but you may find it confusing to have different conventions.

I have not seen this feature used anywhere (except in a future 'Ctls'), probably because it is not widely known
and it is only relevant for controls that use the standard inspector dialog as a property editor.
Therefore it may be possible to align this behavior, i.e. to use a fully qualified key, including the subsystem,
for DevInspector properties.
From a users perspective I think it is more consistent and less confusing to keep the subsystem name as a prefix everywhere.

The start of my Ctls Strings file is

Code: Select all

STRINGS
Buttons2.Property	StdCmds.OpenToolDialog ('Ctls/Rsrc/ButtonInspector', 'Button Views Inspector');
Figures.Property	CtlsFigures.InitInspector; StdCmds.OpenToolDialog ('Ctls/Rsrc/FiguresInspector', '(Ctls)Figures Inspector')
UnitField.Property	CtlsUnitField.InitDialog; StdCmds.OpenToolDialog('Ctls/Rsrc/UnitFieldInspector', 'UnitField Inspector')
so I guess consistency would have the prefix also added to these Property types.

(To be honest it is many years since I worked on these modules, and can't immediately remember what these lines do.)
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#180 fixing resource lookup in OleClient.PasteSpec

Post by Josef Templ »

Robert wrote: The start of my Ctls Strings file is

Code: Select all

STRINGS
Buttons2.Property	StdCmds.OpenToolDialog ('Ctls/Rsrc/ButtonInspector', 'Button Views Inspector');
Figures.Property	CtlsFigures.InitInspector; StdCmds.OpenToolDialog ('Ctls/Rsrc/FiguresInspector', '(Ctls)Figures Inspector')
UnitField.Property	CtlsUnitField.InitDialog; StdCmds.OpenToolDialog('Ctls/Rsrc/UnitFieldInspector', 'UnitField Inspector')
so I guess consistency would have the prefix also added to these Property types.
I see.
Not only DevInspector but also StdCmds.ShowProp uses the convention that the subsystem is omitted.
There are multiple occurrences of such keys in several Strings files.
This means that it cannot be changed easily as I thought before.
Therefore I think that it is better to leave the existing conventions unchanged.

- Josef
Post Reply