Changes in System.sysutils.pas were not reflecting in other unit in Delphi 11

[sp0987 0]

We have introduced a new variable to the interface part and a function to the implementation portion of the Delphi 11 System.Sysutils.pas, in accordance with project requirements. The freshly generated variable is not accessible to me, and when I try to access it, I get the "Undefined Identifier" error. In Delphi 7, the same procedure was effective.

Edited April 30 by sp0987

[Sherlock 663]

I presume you copied this altered version to your projects path...? And it is missing from the other project? Project requirements that require a change to a file which might in turn get changed with every patch/update of the IDE are at least worthy of discussion.

[sp0987 0]

The Path was right. The discussion was not about our project. It's about the working of sysutils.pas from Delphi 7 to Delphi 11. 

[Anders Melander 1783]

There's no difference between Delphi 7 and 11 with regard to modifying sysutils that I can think of. You have most likely not specified the correct project search path.

 

Where have you placed the modified sysutils.pas ?

[sp0987 0]

Scenario 1:

 

I moved the sysutils.pas file to a different location (I'm assuming it's a project folder), and I included the project's folder in the project search path.

Then, during compilation, I received  "[dcc32 Fatal Error] System.SysUtils.pas(35475): F2051 Unit System.Classes was compiled with a different version of System.SysUtils.FreeAndNil".

 

Scenario 2:

 

I placed the  sysutils.pas in the base folder i.e., (C:\Delphi11\source\rtl\sys). Then, during compilation, I received a "Undeclared Identifier"

 

 

[Anders Melander 1783]

4 minutes ago, sp0987 said:

Scenario 2:

I placed the  sysutils.pas in the base folder

Don't do that. Leave Delphi's files and folder alone.

 

4 minutes ago, sp0987 said:

Scenario 1:

I moved the sysutils.pas file to a different location

This should work. Just make sure that the path to that file is before any other place where the compiler might find sysutils.pas or sysutils.dcu

[PeterBelow 238]

3 hours ago, sp0987 said:

We have introduced a new variable to the interface part and a function to the implementation portion of the Delphi 11 System.Sysutils.pas, in accordance with project requirements. The freshly generated variable is not accessible to me, and when I try to access it, I get the "Undefined Identifier" error. In Delphi 7, the same procedure was effective.

If you changed the interface section (bad idea, really) that means that every RTL and VCL unit using system.sysutils needs to be recompiled in addition to your own units and the resulting dcus need to be put in a folder where they replace the dcus that come with the Delphi installation. And remember that said installation has different dcus for debug and release and different platforms, something D7 did not have.

Best reevaluate the original cause for this change in D7 and see wether you can avoid it in D11 completely.

[Sherlock 663]

2 minutes ago, PeterBelow said:

Best reevaluate the original cause for this change in D7 and see wether you can avoid it in D11 completely.

Hence my feeling for the need of discussion.

[Vandrovnik 214]

When I change System.SysConst.pas or Vcl.Consts.pas (to translate some messages), I always put them to the folder where my app is and I also use Project, Add and manually add them.

But I always keep the interface part the same as in original file, otherwise all dependent units have to be recompiled.

[sp0987 0]

1 minute ago, Anders Melander said:

Don't do that. Leave Delphi's files and folder alone.

 

This should work. Just make sure that the path to that file is before any other place where the compiler might find sysutils.pas or sysutils.dcu

It didn't work. I have placed the folder path as first option in project search path. Is there any other areas i have to change i.e., library path in Delphi IDE-> Tools-> Options.

[Anders Melander 1783]

The project search path has precedence.

 

Post your .dproj file if you can.

 

...or you could explain what your end goal is; Why do you need to modify sysutils.pas? We might help you with a better solution.

[sp0987 0]

1 minute ago, Vandrovnik said:

When I change System.SysConst.pas or Vcl.Consts.pas (to translate some messages), I always put them to the folder where my app is and I also use Project, Add and manually add them.

But I always keep the interface part the same as in original file, otherwise all dependent units have to be recompiled.

I've heard on a few blogs that it's best to leave the sysutils.pas file interface alone. However, the issue is creating a new variable that needs to be utilized in several sysutils.pas routines.

[Sherlock 663]

Once this issue is resolved, take a look at class helpers. Perhaps this could help get around the need to change RTL/VCL units.

[Brandon Staggs 278]

1 hour ago, Sherlock said:

Once this issue is resolved, take a look at class helpers. Perhaps this could help get around the need to change RTL/VCL units.

Unfortunately, since they broke the most truly useful feature of class helpers by removing the ability of the helper to access private members of the class, they don't work so great as an alternative to editing source files directly. Now you have to write a RTTI monstrosity to accomplish the same thing.

[Anders Melander 1783]

18 minutes ago, Brandon Staggs said:

Unfortunately, since they broke the most truly useful feature of class helpers by removing the ability of the helper to access private members of the class, they don't work so great as an alternative to editing source files directly. Now you have to write a RTTI monstrosity to accomplish the same thing. 

I can't recall when I last had the need for editing the source files. There are almost always other ways to solve a problem.

[Brandon Staggs 278]

4 minutes ago, Anders Melander said:

I can't recall when I last had the need for editing the source files. There are almost always other ways to solve a problem.

It depends on the scope of your project and whether or not you run into one of the thousands of unfixed bugs in the RTL or VCL or FMX source. There are literally thousands of bugs that can only be fixed by editing source code. If you expand your definition of bug to include "design flaw" there are hundreds more issues that can only be addressed by editing source code. For example, the fundamentally flawed canvas locking scheme that precludes any serious multi-threaded development (that involves bitmaps) in FMX can only be fixed by editing source code.

Edited April 30 by Brandon Staggs

[Anders Melander 1783]

4 minutes ago, Brandon Staggs said:

For example, the fundamentally flawed canvas locking scheme that precludes any serious multi-threaded development (that involves bitmaps) in FMX can only be fixed by editing source code.

I've not done any serious FMX development so I can't speak to that, but given how much code I write and the number and size of projects I work on, I do think I have had more than my fair share of problems with almost all areas of the RTL and VCL over the years. Editing the source files has never been an option I would consider.

[Brandon Staggs 278]

2 minutes ago, Anders Melander said:

Editing the source files has never been an option I would consider.

Fair enough, it's a last resort for me. Nevertheless, if you browse through the bug reports, you will see all kinds of issues that are fixed by correcting the bug in the source file. If the bug is in a private method, or if you need to access a private field to work around it, or if a method that should be protected is marked private, etc, you can only choose to avoid the bug by not using the offending code at all, or change the source code. Class helpers used to be an excellent way to avoid editing the source files, but that was neutered and we were told to use RTTI instead, which is so obtuse that editing a local fork of the source file is much preferred on our team.

[sp0987 0]

2 hours ago, Anders Melander said:

The project search path has precedence.

 

Post your .dproj file if you can.

 

...or you could explain what your end goal is; Why do you need to modify sysutils.pas? We might help you with a better solution.

Please find the .dproj .

SampleApp.dproj

[Anders Melander 1783]

1 minute ago, sp0987 said:

Please find the .dproj .

Assuming you have saved sysutils.pas to "C:\Testprojects\SampleApp\system" that part is okay.

Now you just need to add the path of all the VCL/RTL units that use that unit so you can avoid "F2051 Unit XXX was compiled with a different version of YYY" - or make sure that you don't modify the interface section. I'm guessing the compiler options used to compile your sysutils copy might also have importance. Maybe someone else knows that.

 

...or solve the problem in some other way...

[sp0987 0]

2 minutes ago, Anders Melander said:

Now you just need to add the path of all the VCL/RTL units that use that unit

It means the path which contains all System.XXX.Pas files (C:\Delphi11\source)?

[Anders Melander 1783]

Yes.

[Dalija Prasnikar 1396]

15 hours ago, Anders Melander said:

I can't recall when I last had the need for editing the source files. There are almost always other ways to solve a problem.

Even with class helpers available, I had to edit VCL source code in few places. And I still had to make a completely new implementations for plenty of stuff. Now, with time some things get fixed, some get improved, but there will always be things for which you would either need class helpers, which are no longer available.

[David Heffernan 2345]

What you seem to be in denial of is the need to recompile every rtl/vcl unit because you made a significant change to the interface of SysUtils. 

 

Are you really prepared to recompile everything? 

 

I bet there's another way to solve your problem. If only you'd tell us what the actual problem was.

Edited May 1 by David Heffernan

[Dave Nottage 557]

22 hours ago, sp0987 said:

...in accordance with project requirements

I've never seen a project requirement that says something like: "the interface section of SysUtils must be modified in this way" - usually it's more like: "functionality X is required", and it may turn out that the most expedient solution to the requirement is to modify the source. Your description sounds a lot like: "we have SysUtils added to the uses clause of (almost) every unit in the project, so let's change that to avoid having to create another one of our own".

25 minutes ago, David Heffernan said:

I bet there's another way to solve your problem. If only you'd tell us what the actual problem was.

Amen.

Edited May 1 by Dave Nottage