I am trying to install a 3rd party package and I get a compile error:
[DCC Error] fiile/line : E2003 Undeclared identifier: 'Windows'
which refers to this line:
wnd := Windows.GetFocus;
It seems fairly obvious that I don't have my Unit Scopes right - but which do I need (and is there a general approach to find which use clause I need)?
I currently have
Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;System;Xml;Data;Datasnap;Web;
Soap;Vcl;Vcl.Imaging;Vcl.Touch;Vcl.Samples;Vcl.Shell;Winapi;System.Win
[Update]
interface
uses
SysUtils, winapi.windows, Classes, Controls, ExtCtrls, Graphics, StdCtrls,
Dialogs, IniFiles, winapi.messages, Forms, Math
{$IFDEF DELPHI6_LVL}
, Variants
{$ENDIF}
;
No uses in the impementation section.
[Upate]
I forgot to mention. I failed (in the same way) to install it on one laptop. Then I succeeded on a second. The trouble is that I'd rather have it on my desktop and after a fresh install of XE2 starter I get these problems.
Assuming that your uses names the Windows unit at all, it would appear to do so by naming the unit as Winapi.Windows. And so your code must also do so and be written as
wnd := Winapi.Windows.GetFocus;
When you use a unit by naming the fully scoped unit name, you must also use the fully scoped name in subsequent code in that unit.
Now, if you want to use the name Windows then you must name the unit as Windows in the uses clause and let the unit alias setting do its job. If you imported the unit by naming it Windows then your original code will work.
To be very clear:
uses
Winapi.Windows;
is what you have now but you would need:
uses
Windows;
for your code to compile.
You unit scope looks fine, so try these two options
declare in your uses section Windows instead of Winapi.Windows
or modify your code like so
wnd := Winapi.Windows.GetFocus;
Related
I manage a huge project in Delphi 2007. The target is to upgrade it to Delphi 10.1 Berlin this year. So in the meantime the source is compiled in both versions.
If there is a problem with the new Delphi we want the old version as backup.
My problem in unit dmActions.pas that is a unit inherited from TDataModule.
uses
// VCL
ActnList,
ActnMan,
Classes,
Controls,
Forms,
Graphics,
ImgList,
Menus,
SysUtils,
XPStyleActnCtrls,
Variants,
{$IFDEF BOLD_DELPHI16_OR_LATER}
System.ImageList,
System.Actions,
{$ENDIF}
BusinessClasses;
Delphi IDE don't understand my IFDEF so it automatically insert missing units to this
uses
// VCL
ActnList,
ActnMan,
Classes,
Controls,
Forms,
Graphics,
ImgList,
Menus,
SysUtils,
XPStyleActnCtrls,
Variants,
{$IFDEF BOLD_DELPHI16_OR_LATER}
System.ImageList,
System.Actions,
{$ENDIF}
BusinessClasses, System.ImageList, System.Actions;
But this don't compile in Berlin with this message
[dcc32 Error] dmActions.pas(36): E2004 Identifier redeclared: 'System.ImageList'
[dcc32 Error] dmActions.pas(36): E2004 Identifier redeclared: 'System.Actions'
And of course "System.ImageList, System.Actions" don't compile in D2007.
So what is my best action to solve this ?
You can make use of the Unit Aliases feature of Delphi here - at least as your Delphi 2007 supports dotted unit names in the first place. This allows to use the new unit names like System.SysUtils from Delphi 10.1 Berlin and still compile that project with Delphi 2007.
For this you have to add mappings to the Unit Aliases of the Delphi 2007 project like this:
System.SysUtils=SysUtils
System.Classes=Classes
For units that don't exist in Delphi 2007, like the ones you mention in your post, simply map to an existing unit:
System.Actions=ActnList
System.ImageList=ImgList
As a benefit you end up with uses clauses free of IFDEFs.
As https://stackoverflow.com/users/2916756/nolaspeaker said it works by test compiler version directly. I used an inc-file and that don't work well in this case
But in my case I check Berlin so:
{$IFDEF VER310}
System.ImageList,
System.Actions,
{$ENDIF}
Recently I found some odd-looking (to me) Delphi code and I have isolated it to a separate small project. Here is what I discovered. Unit1 compiles with no errors. Unit2 (which I provide for comparison) does not. The difference is in the way that Classes is used.
unit Unit1;
interface
uses Classes; // difference here
type TThread = class(Classes.TThread)
public
property Terminated;
end;
implementation
end.
Unit2 does not compile. Various errors are produced.
unit Unit2;
interface
uses System.Classes; // difference here
type TThread = class(Classes.TThread)
public
property Terminated;
end;
implementation
end.
[dcc32 Error] Unit1.pas(7): E2003 Undeclared identifier: 'Classes'
[dcc32 Error] Unit1.pas(7): E2029 ',' or ':' expected but ')' found
[dcc32 Error] Unit1.pas(9): E2147 Property 'Terminated' does not exist in base class
So my concern is that this project is exploiting a compiler bug to achieve it's goals. The compiler bug might be fixed in a later release, and then the code won't work anymore.
There is no compiler bug that makes Unit1 compile. It compiles because in the project setting the entry for Unit Scope Names contains at least the item System, which is used to resolve the reference to Classes in the full name System.Classes. As the uses contains Classes, the reference to Classes.TThread also succeeds.
In Unit2 the uses contains System.Classes. Therefore the reference Classes.TThread cannot be resolved anymore. Change it to System.Classes.TThread and it works.
If you uses System.Classes you must also use System.Classes when referring to the classes unit in the code as shown below.
unit Unit2;
interface
uses System.Classes; // difference here
type TThread = class(System.Classes.TThread)
public
property Terminated;
end;
implementation
end.
I'm testing on Delphi 2007 and my groupproject is composed by 2 packages.
PackageRun.bpl
It's marked as "runtime only" and contains a unit named "uMyTestRun.pas" in which is defined an empty TFrame descendant:
unit uMyTestRun;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs;
type
TMyTest = class(TFrame)
private
{ Private declarations }
public
{ Public declarations }
end;
implementation
{$R *.dfm}
end.
PackageDes.bpl
It requires PackageRun.bpl, it's marked as "designtime only" and contains a unit named "uMyTestDes.pas" in which I wrote the following code:
unit uMyTestDes;
interface
uses
Classes,
uMyTestRun;
procedure Register;
implementation
procedure Register;
begin
RegisterComponents('MyComponents', [TMyTest]);
end;
end.
Output directories of both packages are in Library paths (Inside there are bpl, dcp and dcu).
Trying to install PackageDes.bpl (Component, Install Packages..., Add...), I'm getting the following error:
Can't load package C:\<...>\PackageDes.bpl. Impossibile trovare il
modulo specificato.
The last part of the message is in my OS's language, in english it should be something like "Can't find specified module". (My OS is Windows 10 Pro 64bit).
PackageDes.bpl is exactly in the same path shown in the error message (C:\<...>\PackageDes.bpl).
After some tests, I found that the error disappear by removing the following line from uMyTestDes.pas unit:
RegisterComponents('MyComponents', [TMyTest]);
Is there something wrong in my code/projects/environment?
Run Process Monitor from http://SysInternals.com and set the filters to intercept only file operations ( toolbar rightmost buttons ) of your Delphi IDE process (check the process name in TaskManager or shortcut properties (it is bds.exe for Delphi XE2), then add the filter similar to Include / Process Name / Ends With / bds.exe ).
Then clear the log in PM, switch to Delphi and try to load the package, then as soon as error pops up switch back to PM and stop capturing events. Try to do it fast as you can, for example do not waste your time closing error box.
Now you would get a trace of file I/O activity of Delphi loading the package of yours (and some other background activity noise - the faster you do the less noise there'd be). In that trace look for all the errors and see where and which package Delphi tries to find.
You can also try Microsoft Dependency Walker or similar tools to se if your Design-Time BPL has all the DLL-dependency tree resolvable. Personally I usually use Unreal/Total commander with FileInfo plugin or ntCore CFF Explorer.
Easy way to solve this issue is to add a post build action to your run time project:
copy "$(OUTPUTDIR)\$(OUTPUTFILENAME)" "$(BDSCOMMONDIR)\Bpl"
The command above copies your run time file to the default IDE Bpl location.
I had a similar issue. In my case I had the same library name in a different Delphi version BPL path. I found out the solution for my issue looking at the comments above, so this is only a reminder for basic things to check:
BPL path have to be included in your OS path variable;
Search for a BPL module with the same name in other OS path before the right one (mutiple Delphi version installations).
Try to change the register procedure to uMyTestRun unit.
unit UMyTestRun;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs;
type
TMyTest = class(TFrame)
private
{ Private declarations }
public
{ Public declarations }
end;
procedure Register;
implementation
procedure Register;
begin
RegisterComponents('MyComponents', [TMyTest]);
end;
end.
Now, the package will install correctly.
Regards.
A colleague of mine bumped into a constant that had suddenly 'changed value';
Turned out, it was redeclared:
unit Unit1;
interface
const
MyConstant = 1;
implementation
end.
--
unit Unit2;
interface
const
MyConstant = 2;
implementation
end.
--
Uses Unit1, Unit2;
// Uses Unit2, Unit1;
procedure TFrmRedefineConstant.FormShow(Sender: TObject);
begin
ShowMessage('MyConstant: ' + IntToStr(MyConstant));
end;
This shows 2. If you swap the unit order in the Uses statement, it shows 1.
Fine, but why does the Delphi compiler not warn about the duplicate constant name (That would be very helpful)?
Is there anything I can do to enable warnings (does not look that way).
Because of Delphi documented scoping rules. From the Language Guide:
The order in which units appear in the uses clause determines the
order of their initialization and affects the way identifiers are
located by the compiler. If two units declare a variable, constant,
type, procedure, or function with the same name, the compiler uses the
one from the unit listed last in the uses clause. (To access the
identifier from the other unit, you would have to add a qualifier:
UnitName.Identifier.)
This is the expected behaviour since Turbo Pascal 4.0, which introduced units.
I have registered the package TMS Unicode Component Pack in my Delphi 7 containing TNT components.
This package contains a class named TTntCustomComboBox which I use to create my own custom component named Combobox2 :
unit Combobox2;
interface
uses
Windows, Messages, Classes, Graphics, Controls, StdCtrls, ImgList, ActiveX, SysUtils, TntStdCtrls, TntWindows;
type
TCombobox2 = class(TTntCustomComboBox)
...
procedure Register;
begin
RegisterComponents('Standard', [TCombobox2]);
end;
...
I've added this component (TCombobox2) to the package dclusr.dpk.
Compiling dclusr.dpk works but installing the package raises an exception :
Registration procedure Combobox2.Register in package C:\program files\Delphi7\Projects\Bpl\dclusr.bpl raised an exception class EFilererror : A class named TTntCustomComboBox already exists
So, how do I fix that ?
Thanks for help.
The error message indicates that your package is trying to register a component that is already registered, namely TTntCustomComboBox.
It's not obvious from the details that you have provided why this would happen. One possible reason would be if you included the TNT components in your package instead of referencing that in your package's requires clause. Another possible reason would be if your Register function attempted to register TTntCustomComboBox. This could happen if your actual declaration of TCombobox2 was like so:
TCombobox2 = TTntCustomComboBox;
Put {$WEAKPACKAGEUNIT ON} after unit caption.