issue-#180 fixing resource lookup in OleClient.PasteSpecial

User avatar
DGDanforth
Posts: 1061
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, California, USA
Contact:

IsNewInSymFile

Post by DGDanforth »

compiling "GraphicsTool"
IsNewInSymFile
IsNewInSymFile 1664 160
I no longer see the variables that are new.
Version 1.71-b1
Build number 951

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

Re: IsNewInSymFile

Post by Josef Templ »

DGDanforth wrote:
compiling "GraphicsTool"
IsNewInSymFile
IsNewInSymFile 1664 160
I no longer see the variables that are new.
Version 1.71-b1
Build number 951

-Doug
There hasn't been any change with respect to reporting sym file differences.
If there are no changes listed, then there are no changes.
If sym file differences are not shown correctly, I would expect that the same problem existed in BB1.6 and 1.7.

- Josef
User avatar
DGDanforth
Posts: 1061
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, California, USA
Contact:

Re: IsNewInSymFile

Post by DGDanforth »

From Dev/CPT

Code: Select all

	PROCEDURE FPrintErr* (obj: Object; errno: SHORTINT);	(* !!! *)
	BEGIN
		IF errno = 249 THEN
			DevCPM.LogWLn; DevCPM.LogWStr("  ");
			DevCPM.LogWPar("#Dev:InconsistentImport", GlbMod[-obj.mnolev].name, obj.name);
			err(249)
		ELSIF obj = NIL THEN	(* changed module sys flags *)
			IF ~symNew & sfpresent THEN
				DevCPM.LogWLn; DevCPM.LogWStr("  "); DevCPM.LogWPar("#Dev:ChangedLibFlag", "", "")
			END
		ELSIF obj.mnolev = 0 THEN	(* don't report changes in imported modules *)
			IF sfpresent THEN
				IF symChanges < 20 THEN
					DevCPM.LogWLn; DevCPM.LogWStr("  ");
					CASE errno OF
					| 250: DevCPM.LogWPar("#Dev:IsNoLongerInSymFile", obj.name, "")
					| 251: DevCPM.LogWPar("#Dev:IsRedefinedInternally", obj.name, "")
					| 252: DevCPM.LogWPar("#Dev:IsRedefined", obj.name, "")
					| 253: DevCPM.LogWPar("#Dev:IsNewInSymFile", obj.name, "")
					END
				ELSIF symChanges = 20 THEN
					DevCPM.LogWLn; DevCPM.LogWStr("  ...")
				END;
				INC(symChanges)
			ELSIF (errno = 253) & ~symExtended THEN
				DevCPM.LogWLn; 
				DevCPM.LogWStr("  "); DevCPM.LogWPar("#Dev:NewSymFile", "", "")
			END
		END;
		IF errno = 253 THEN symExtended := TRUE ELSE symNew := TRUE END
	END FPrintErr;

So it appears that #Dev:IsNewInSymFile is not being replaced correctly.
I have lost track of how that mechanism works. Does that mean that some Strings file has been corrupted?
-Doug
User avatar
DGDanforth
Posts: 1061
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, California, USA
Contact:

Re: IsNewInSymFile

Post by DGDanforth »

In Dev/Rsrc/Strings I find

Code: Select all

IsNewInSymFile	^0 is new in symbol file
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: IsNewInSymFile

Post by Josef Templ »

There is no such problem with an unmodified version of build 951.
This must be caused by your own modifications.
Check the /USE option.
Check if you have a modified version of Dev/Rsrc/Strings in use.

- Josef
User avatar
DGDanforth
Posts: 1061
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, California, USA
Contact:

Re: IsNewInSymFile

Post by DGDanforth »

Josef Templ wrote:There is no such problem with an unmodified version of build 951.
This must be caused by your own modifications.
Check the /USE option.
Check if you have a modified version of Dev/Rsrc/Strings in use.

- Josef
Indeed I do.
That points up a design failure.
If an application (in this case Robert's Ctls) needs to modify the Strings file then
to preserve the Frameworks Strings one must copy the file to their own /USE version.
BUT that immediately makes it out of step with any future releases of the framework
that modifies (upgrades) the String file.

It is highly unlikely that we (me) can keep track of all the consequences of an upgrade.

What do you do?
-Doug
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: IsNewInSymFile

Post by Josef Templ »

I don't know why the Ctls subsystem needs to modify the Dev/Rsrc/Strings file.
The authors (Helmut, Robert) know more about it, I guess.
The normal approach would be that any resources of a subsystem X are put into X/Rsrc/Strings etc.
This seems to be violated here.
There may be a reason for that and I would also be interested in the answer.

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

Re: IsNewInSymFile

Post by Zinn »

The resources of Form Controls are define in Dev/Rsrc/Strings.
They used by the properties form.
Subsystem Ctls adding some new Controls for the Form.
You can use this new controls without insert its resources in Dev/Rsrc/Strings,
but then you don't see in the property form for what the check boxes are used.
In the CPC Edition this new resources are added already in Dev/Rsrc/Strings file.
- Helmut
User avatar
DGDanforth
Posts: 1061
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, California, USA
Contact:

Re: IsNewInSymFile

Post by DGDanforth »

So we see there is a conceptual problem.
Speculatively one should have a pointer from one's /USE Strings file to the frameworks Strings file
and the framework on execution merges those two files.
That might work for Strings but would not work for Host files which are code and merging would
make no sense.

Any other ideas?
-Doug
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: IsNewInSymFile

Post by Josef Templ »

Zinn wrote:The resources of Form Controls are define in Dev/Rsrc/Strings.
They used by the properties form.
Subsystem Ctls adding some new Controls for the Form.
You can use this new controls without insert its resources in Dev/Rsrc/Strings,
but then you don't see in the property form for what the check boxes are used.
In the CPC Edition this new resources are added already in Dev/Rsrc/Strings file.
- Helmut
There is a simple solution for Ctls, I think.
You can specify all the inspector properties in Ctls/Rsrc/Strings if you remove the "Ctls" prefix.
For example use:

Code: Select all

RealField.Control	     Real Field
RealField.Control.Opt0	Left
RealField.Control.Opt1	Right
RealField.Control.Opt2	Kill trailing '0's
RealField.Control.Opt3	Fixed significant figs
RealField.Control.Opt4	Maximum digits
- Josef
Post Reply