F2051 Error unit was compiled with different version of X

[Greg]

I now realize I did something very stupid: I was trying to create a
descendent tCategoryButtons component, but a number of the methods I needed
to use were private. I went in to the original source code of the
CategoryButtons and changed the methods from private to protected.

However, when I went to compile my main program, I started to get an error
"F2051 Unit ColorGrd was compiled with a different version of
Menus.TPopMenu" next to where "ColorGrd" is listed in Uses. If I comment
out "ColorGrd", then the same F2501 error comes up in my Asphyre (3d pty)
units stating that a certain Asphyre unit was compiled with a different
version of Graphics.TGraphic.

I have tried reversing the changes I made to CategoryButtons and removing
the new descendant of tCategoryButtons I created, but I still cannot compile
without hitting these errors.

From reading posts I now realize that I should not have messed with the
original source files, but do not know how to correct this.

Does anyone know how I can reverse this?

[Maris Janis Vasilevskis]

Hi Greg,

If unit A refers to unit B, A.dcu contains references to unique unit and procedure identifiers in B.dcu.
If you recompile B, the identifiers, in general, are regenerated, and references in A are not acceptable until you recompile A.

Therefore, if you recompile CategoryButons, you should recompile everything which depends from CategoryButons.
And everything which depends from these dependents, and so on.
You cannot do in for Borland units because Borland does not provide dpk's.
(Of course, you also are not allowed to do it due to Borland license).

It seems that you have recompiled something else.
Maybe, your library path contains some Borland source directories? Delete them immediately, pascal files are for browsing path only, without any exceptions.

If you made backup of Borland or have some another access to original DCU's, try to restore them.
Look in Borland Lib directory and check DCU dates.
The only way to get a working system - find original versions of all DCUs you have changed.
Also, check whether you have not another copies with the same names as Borland units in your library path.

OK, I hope you will return to a working Delphi.
But your requirements to TCategoryButtons remain.

Probably, you should search for some witty workarounds.
You can easy access private variables, but I do not know a good way how to access private methods.
Except special cases - exposed interfaces, messages etc.

I know one method allowing access any private method, but to use it, you should deploy your program together with vclxx.bpl (you did not mention your Delphi version, xx depends on it).

Probably, the best way in your case - get CategoryButtons.pas, rename the unit and all classes, build and install.

There exists also a way to crush "compiled with a different version". Of course, if you have not changed prototypes.

I never changed Borland units.
But a month ago, I had to add Unicode support to some 3rd party package set.
I had sources for most units, but some were available only as DCUs.
So, after I rebuilt the PASs, these DCUs became unusable.
To solve it, I wrote a program with automatically changes stamps in DCUs, and I got a working package set.

Best regards,
Mahris

[Greg]

Mahris,

Thanks very much! I did have a Borland source directory in my library path.
As you recommended, I removed the recently compiled DCUs from the source
code directory (the originals were still in the library directory), removed
the source code directory from my library path, and no more conflict! You
are a life saver!

Regarding the descendant of tCategoryButtons, I have copied the
tCategoryButtons into a new file (which I can safely modify) and renamed the
file and the class tExtCategoryButtons.

Best regards,

Greg

"Maris Janis Vasilevskis" <mah...@myself.com> wrote in message
news:4889D579...@myself.com...