issue-#180 fixing resource lookup in OleClient.PasteSpecial

IsNewInSymFile

Postby DGDanforth » Fri Oct 27, 2017 2:38 am

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
DGDanforth
 
Posts: 1061
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, California, USA

Re: IsNewInSymFile

Postby Josef Templ » Fri Oct 27, 2017 8:07 am

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
Josef Templ
 
Posts: 2038
Joined: Tue Sep 17, 2013 6:50 am

Re: IsNewInSymFile

Postby DGDanforth » Fri Oct 27, 2017 9:33 am

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

Re: IsNewInSymFile

Postby DGDanforth » Fri Oct 27, 2017 9:37 am

In Dev/Rsrc/Strings I find
Code: Select all
IsNewInSymFile   ^0 is new in symbol file
User avatar
DGDanforth
 
Posts: 1061
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, California, USA

Re: IsNewInSymFile

Postby Josef Templ » Fri Oct 27, 2017 10:34 am

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
Josef Templ
 
Posts: 2038
Joined: Tue Sep 17, 2013 6:50 am

Re: IsNewInSymFile

Postby DGDanforth » Fri Oct 27, 2017 10:56 am

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
DGDanforth
 
Posts: 1061
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, California, USA

Re: IsNewInSymFile

Postby Josef Templ » Fri Oct 27, 2017 3:05 pm

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
User avatar
Josef Templ
 
Posts: 2038
Joined: Tue Sep 17, 2013 6:50 am

Re: IsNewInSymFile

Postby Zinn » Fri Oct 27, 2017 8:34 pm

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
Zinn
 
Posts: 472
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main

Re: IsNewInSymFile

Postby DGDanforth » Fri Oct 27, 2017 10:38 pm

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
DGDanforth
 
Posts: 1061
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, California, USA

Re: IsNewInSymFile

Postby Josef Templ » Sat Oct 28, 2017 2:42 am

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
User avatar
Josef Templ
 
Posts: 2038
Joined: Tue Sep 17, 2013 6:50 am

Next

Return to Resolved (Bugs)

Who is online

Users browsing this forum: No registered users and 1 guest

cron