After upgrading Devexpress VCL from 18.2.5 to 19.1.2, in order to use the latest functions and especially the new grid Excel filtering mode,
but unfortunately, the compiler didn't recognize some constants and properties, like the dxDefaultFilterPopupWindowMode constant and
.Filtering.ColumnPopupMode property of DBGridViews.
In spite of putting dxFilterPopupWindow in the uses clause.
Any help ?
Today I upgraded from version 18.1.2 to the most recent version of the DevExpress VCL library,
which is version 19.2.4 dated 22 January 2020 and adapted an existing minimal cxGrid
project to use the new Excel-style filtering. It compiled and executed without any error.
Here's what I did:
1 My existing Devex install folder (the one you tell the installer to use) is D:\DevExpress VCL
2 I renamed D:\DevExpress VCL to D:\DevExpress VCL Prev
3 I ran the 19.2.4 installer, giving D:\DevExpress VCL as the install folder to use.
You mention the compiler complains about the identifiers dxDefaultFilterPopupWindowMode and
ColumnPopupMode. You say "In spite of putting dxFilterPopupWindow in the uses clause.
dxDefaultFilterPopupWindowMode is declared at line 50 of dxFilterPopUpWindow.Pas
const
dxDefaultFilterPopupWindowMode: TdxFilterPopupWindowMode = fpmClassic;
and ColumnPopupMode is declared at line 3361 of cxGridTableView.Pas:
TcxGridTableFiltering = class(TcxCustomGridTableFiltering)
[...]
published
[...]
property ColumnPopupMode: TdxFilterPopupWindowMode read GetColumnPopupMode write SetColumnPopupMode default fpmDefault;
end;
I strongly suggest that you install version 19.2.4 in the way I've described above, then check that your
project's search path includes the path to the Devex sources. Of course, if you follow the method I've described, the project search path should not need changing, if it compiled previously.
If the compiler still complains about
not being able to find dxDefaultFilterPopupWindowMode and ColumnPopupMode, then assuming you are
not compiling your project to use run-time packages, the only possible cause I can think of
is that the compiler is finding earlier versions of dxFilterPopUpWindow.Dcu and cxGridTableView.Dcu that
somehow have later date stamps than the corresponding .PAS files - in that case I would delete all instances
of the Devex Dcu's from my system and try again. A way to ensure that the compiler is compiling the
version of the Devex source files that you think it is is so edit cxGridTableView.Pas to add a "compiler stopper"
such as an exclamation mark at the very top of the file: If the compiler does not complain about this
when trying to compile your project, you'll know that it's finding and using another version of the
cxGridTableView .Pas file or .Dcu.
Finally,
This error occurred because I left the path of the previous version in the Delphi library path, and it was before the path of the new version.
So, I deleted the 1st one and I kept the new one.
Et voila, all things runs well now :):):)
Related
I've created a package which contains several templates (TFrame descendants).
These templates has been added to the palette.
In other packages, I'm trying to use these templates but each time I add one of them, a message appear:
The following unit: %s, is needed in your project to create the
template. Do you wish to add it?
mrYes:
Source file is added to the project.
Furthermore, it causes the following error on compiling:
E2200 Package '%s' already contains unit '%s'
mrNo:
It's ok, but the question is asked each time I place one of my
templates. Me and my collegues will use these templates alot of times and I really would like to avoid that message.
Update 1:
Here are steps to observe the described behavior:
Create a package project named Package1.
Add a TFrame descendant named MyTest.
Add TMyTest to palette (Structure window, right click, add to
palette).
Set project output directories to .\out
Build the project.
Add \out to library path.
In the same projectgroup, create a package project named Package2.
Add Package1, to "requires" (in Package2.dpk).
Add a form.
Add a TMyTestTemplate to the form.
Update 2:
I'm looking for a solution which works with Delphi 2007 and Delphi XE7.
A bit more work but one that should fit your needs:
Create Package FooRuntime(Mark RuntimeOnly), add your TMyFrame
Create Package FooDesignTime(Mark DesigntimeOnly), requires FooRuntime, Registers your frame
Install FooDesignTime
Link your other project to FooRuntime
Without the packages the IDE seems to fail to recognize the units.
Hi I use interop to call C# code in Delphi.
C# code has a binary and in Delphi 5 Menu: Project-->Import Type Library
Click Add to add the tlb file: XXXX.tlb
Unit dir name: input the path where the delphi XXX_TLB.pas file is generated.
If the C# dll, tlb and delphi XXX_TLB.pas has already been there. Now I add one more function in C# code and hope Delphi can call this function as well. I need to recompile c# and regenerate delphi XXX_TLB.pas file. But by following the above steps, I see the newly generated XXX_TLB.pas includes my newly added function, but looks like the functions order in XXX_TLB.pas is totally different from before.
For example, in my C# binary I have function:
func1();
func2();
func3();
func4();//newly added
In the old XXX_TLB.pas, the function order is:
func1();
func2();
func3();
Now XXX_TLB.pas is like this:
func1();
func3();
func4();
func2();
The XXX_TLB.pas can still be used, looks like no functionality difference, but when I check in to tfs, I see it changes a lot from pervious version. Is there a way to keep this new XXX_TLB.pas the same order as before but add my function as well? How to do that? Thanks!
You cannot hope to keep the changes to a minimum unless you start writing the .pas file yourself. That sounds like a worse option.
Probably what is happening is that you have changed version of either one of your compilers since the last time you imported. Otherwise one would expect minimal differences.
Just check it in with a comment stating which versions of compiler and .ocx/.dll were used.
You can't, as far as I know.
I most cases, I'm able to consider them as a sort of "black box" anyway, and only occasionally have to peek in them to find a specific declaration.
I am using Delphi 2010 and GExperts stable release 1.35
I am testing the "Replace Components" expert.
I add a main form and a secondary form. Each has three TEdits on it.
I use the Replace Components Expert to replace all TEdits with TRzEdit. I Check the Replace all components on all forms of the project.
It works, it replaces them all. However, it doesn't do anything to the DFM file. How do i make it replace those instances.
If i save, compile, or rebuild, i get errors.
If i try to view the form as text after replacing, i get errors.
Can someone explain to me the steps to make this work?
Thanks
I just tried it with Delphi XE and GExperts 1.35 and it does indeed crash now even after a single "Replace Selected". (It used to work fine in the past).
It seems that using the hidden menu Project | Clear Unit Cache just after Replace Components then doing a full build before trying any Save/Compile/View As Text... fixes the problem.
I think this menu is surfaced with cnPack. I don't have it and cannot guarantee, but you can easily do it yourself by adding the following unit in one of your installed packages:
unit FGEnableHiddenMenus;
interface
procedure Register;
implementation
uses
Classes, Forms, Menus;
procedure Register;
var
Comp: TComponent;
begin
//Make a hidden menu item visible
Comp := Application.MainForm.FindComponent('ProjectClearUnitCacheItem');
if Comp is TMenuItem then
TMenuItem(Comp).Visible := True;
end;
end.
Source: Brian Long's old goodies
Update:
I had to replace a couple of TEdit by TDBEdit on our main project at work and this trick worked.
But on a new Project with 3 Forms, it failed consistently to write/commit/save the changes on the last Form (same environment).
FYI, I tried with and without DDevExtensions 2.5 and IDEFixPack 4.6.1
Update2:
Went digging in the GExperts forum as suggested by Ulrich and finally found a possible explanation. The new property Touch does not like being copied from one component to another when the source is destroyed (causing the AV).
The suggested workaround is to do a bidirectional mapping in the Expert Settings to disable the copy for this property:
You might be running into this bug while trying to copy the Touch property from the old to the new component, but it has a workaround you can fairly easily test:
http://tech.groups.yahoo.com/group/GExpertsDiscuss/message/3994
Details:
There is a limitation/bug in Delphi 2010 and XE where if you assign a
Component.Touch property from one component to another and destroy the
original component that the new component becomes corrupt (it isn't
like component/interface references, where they either auto-correct
themselves or are reference counted).
For the moment, you can assign a bi-directional replace component
property map from TPanel.Touch to TGroupBox.Touch (use the two components being replaced in your specific case) that is marked as
a disabled property map, and that will work around this problem. Our next release
will not try to assign that property any longer.
GExperts 1.36 is also now available and includes a workaround for this issue. The workaround has been in the GExperts version control system and in testing for several weeks already.
I am using Delphi 2007 with all patches and updates.
I have a file which is used by two different projects. In that file is a procedure, which I will simplify as follows:
procedure MyProcedure;
const
UniqueValue: integer = 0;
begin
//some code
Inc(UniqueValue);
//some more code
end;
The Inc() command should fail, because you cannot assign to a constant. In one project, I get an error to that effect (I'll call that project "Accurate"). In the other project, I don't get any errors (I'll call it "Bogus"). I also don't get any warnings. I can't figure out why the compiler lets this incorrect code through.
Here's what I've tried in project Bogus:
1 - Introduce an obvious error, like typing "slkdjflskdjf" in the middle of a line
Result: I get an error,which proves that it is really trying to compile this file.
2 - Delete the .DCU, and rebuild the project
Result: The .DCU is re-generated, again proving that the project is truly compiling this erroneous code.
Does anyone have thoughts on why this behavior would occur? And more specifically, why it would occur in one project but not another? Is there some obscure compiler option to permit assigning to constants?
One final note: Both projects are converted from Delphi 5. Under Delphi 5 with similar code, they both compile fine.
Edit: Thanks for all your help. After changing the assignable typed constants directive, I can get consistent behavior across both projects. I learned something new today...
There is an option for this called "Assignable typed constants" in Compiler Options. It can also be enabled with "{$J+}" in your code.
Could it be that those projects differ in the setting of the $J compiler directive?
I'd suggest to check the Project Options, section Compiler and see if you can spot any differences. Maybe you have option Assignable typed constants enabled in the Bogus project.
As others have said it's almost certainly the {$J+} directive.
If you have a diff tool you can compare the project files to see how they differ - they're just text files - to solve similar problems in the future.
I'm getting the error: wintypes.dcu not found several times a day in the Delphi 2009 IDE, after this error code completion stops working, also I can't open any unit's source code with Ctrl + Click, then I have to reopen the IDE to fix it.
Anyone has a clue about what can be causing this?
The only IDE extension I have installed is GExperts.
wintypes.pas and winprocs.pas has been replaced with windows.pas (since a long time). You should use Unit Aliases to replace all wintypes with windows.
You must be still using the ancient (pre-Delphi 2) names for what is now the Windows unit. I recommend that you search and replace all your uses lists and replace WinTypes and WinProcs with Windows.
Alternatively, you can make sure you have "WinTypes=Windows" and "WinProcs=Windows" in the Unit Aliases section of your project options, but still, after all these decades, I'd move on to the 32-bit world! (16-bit being the prime limitation that meant WinTypes and WinProcs were two separate units.)
Open Project - Options, Delphi Compiler ,into Unit aliases insert:
WinTypes=Windows;WinProcs=Windows;DbiProcs=BDE;DbiTypes=BDE;DbiErrs=BDE
Do you use the Decision Cube component? So look for references on the unit MXQEDCOM.pas in your sources.
On BDS 2006, is the only reference for Wintypes and Winprocs I found.
By the way, make sure that the Unit Aliases included the values that Barry Kelly wrote.
Why wintypes.dcu cannot be found any longer, I do not know. But the other two are obvious follow up errors: if Delphi cannot compile the code due to syntax errors (and a missing file is considered a syntax error), it stops code completion and cannot locate source code any longer using Ctrl + Click.