I still use Delphi XE4 (newest compiler I use of multiple Delphi compilers) and need a specific workaround for the fact they completely hid FClients in TBasicAction in this version. I connect/disconnect clients runtime while setting enabled/disabled (to avoid flicker with ~100+ actions and ui elements) thus this workaround for XE4:
Here's my naive attempt and simply returning the field.
TmscBasicActionCrack = class(TBasicAction)
end;
{$IFDEF mymsDELPHIXE4}
TmscBasicActionHelper = class helper for TBasicAction
public
function Helper_Get_Private_FClients: TList<System.Classes.TBasicActionLink>;
end;
{$ENDIF}
{$IFDEF mymsDELPHIXE4}
//------------------------------------------------------------------------------
function TmscBasicActionHelper.Helper_Get_Private_FClients: TList<System.Classes.TBasicActionLink>;
begin
Result := Self.FClients;
end;
{$ENDIF}
However, I get error
E2003 Undeclared identifier: TList<>
I must admit I never go around to using generics with Delphi since I initially heard of stability problems + I need to maintain compability with Lazarus/FreePascal.
I am aware the most recent versions Delphi has altered class helpers again, but I am for now mostly interested in getting this to work with Delphi XE4
The error is indicating that the TList<T> type is unknown to the compiler. To use it you must include System.Generics.Collections in your uses clause.
In a Delphi XE7 64-bit VCL program, the unit Vcl.OleAutocannot be found:
[dcc64 Fatal Error] Unit1.pas(33): F1026 File not found: 'Vcl.OleAuto.dcu'
While it works without problems in a 32-bit program:
uses
Vcl.OleAuto;
...
FSWbemLocator := CreateOleObject('WbemScripting.SWbemLocator');
So how can I use CreateOleObject in a 64-bit program?
Although the source code for Vcl.OleAuto is still supplied, the 64 bit lib directory does not include Vcl.OleAuto.dcu. Instead you are expected to use System.Win.ComObj and/or System.Win.ComServ. Note that the source for Vcl.OleAuto marks that unit as being deprecated, and tells you what to use instead.
If we look through the source for Vcl.OleAuto we can find some 32 bit asm code that has not been ported. Presumably Embarcadero decided not to port this to 64 bit because the unit is deprecated.
My old Delphi 7 application is using IdStreamVCLWin32 unit in one pas file. This unit is located at following location.
C:\Program Files\Indy 10 for Delphi\Source\System\IdStreamVCLWin32.pas
When I am running same code in my Delphi XE4 environment, I am getting error IdStreamVCLWin32 not found.
Note: Delphi 7 is using Indy 10 but Delphi XE4 is using Indy which comes default with it. I have not installed indy explicitly in Delphi XE4 environment.
I searched my entire C drive where Delphi XE4 is installed but found no IdStreamVCLWin32.pas file.
How to get rid from this error?
From what I can tell, you were never meant to include that unit directly. The unit IdStreamVCL would delegate to either IdStreamVCLDotNet or IdStreamVCLWin32. And so it appears to me that IdStreamVCLWin32 is an implementation detail that you are shielded from by using IdStreamVCL.
These units have, nowadays, all been coalesced into IdStreamVCL. And so you could include that. However, it's not clear to me that you should even do that. Take a look at IdStream:
unit IdStream;
interface
{$I IdCompilerDefines.inc}
uses
{$IFDEF DOTNET}
IdStreamNET
{$ELSE}
IdStreamVCL
{$ENDIF};
type
{$IFDEF DOTNET}
TIdStreamHelper = TIdStreamHelperNET;
{$ELSE}
TIdStreamHelper = TIdStreamHelperVCL;
{$ENDIF}
implementation
end.
It seems pretty clear that you are meant to use IdStream and let the compiler work out whether that implementation is provided by IdStreamNET or IdStreamVCL.
So, the answer to your question is probably that you should replace your use of IdStreamVCLWin32 with IdStream. Note that the functionality in IdStream is implemented differently now. You no longer instantiate an instance of a stream class. The modern Indy offers you a helper class TIdStreamHelper which contains class functions. So you end up writing code like this:
BytesWritten := TIdStreamHelper.Write(Stream, Bytes, Count);
However, I cannot be sure that's the right approach since I don't know what you actually use from IdStreamVCLWin32. It's quite plausible that your code uses nothing from there and the use of IdStreamVCLWin32 is simply a stray hangover from some older version of your code.
So my advice is:
Remove IdStreamVCLWin32 from your uses.
Deal with any subsequent compiler errors by studying the code and working out the right way to do it with the current Indy code.
In Delphi XE UxTheme unit there is the following declaration
function DrawThemeTextEx(hTheme: HTHEME; hdc: HDC; iPartId: Integer; iStateId: Integer;
pszText: LPCWSTR; cchText: Integer; dwTextFlags: DWORD; pRect: PRect;
var pOptions: TDTTOpts): HResult; stdcall;
external themelib name 'DrawThemeTextEx' delayed;
My Windows XP Professional with SP3 does not have such function in the uxtheme.dll (checked with dllexp.exe from http://www.nirsoft.net/utils/dll_export_viewer.html)
It seems like my application does delayed loading of the procedure and fails runtime with the following error:
Project mtgstudio.exe raised exception class EExternalException
with message 'External exception C0FB007F'.
The issue was encountered in JVCL as well but resolved there as per http://andy.jgknet.de/blog/2009/09/once-upon-a-delayed-jvcl-time/
I need UxTheme fixed because they are used by the DevExpress components as well.
Is there a way to patch/fix the UxTheme.pas DrawThemeTextEx declaration to be non-delayed?
The fundamental problem is that this API was introduced in Vista and is not available in XP.
The whole point of the delayed keyword is to allow functions like this to be made available easily to developers who want to take advantage of newer API functions. But to do so the developer typically must also provide fallback implementations for older OS versions, which DevExpress appear to have failed to do.
The bug is therefore not in UxTheme.pas, but in the DevExpress component that calls an API that is not implemented on the platform. The fix is to re-work the DevExpress code to avoid calling this API on XP.
I suggest you contact DevExpress who quite probably already have a fix in their latest versions.
I'm testing a non visual ActiveX control based on a registered .ocx
which I import into Delphi using the provided wizard.
Then, I simply put the generated component on the main form of a new VCL application.
Under old Delphi versions (D5 and D2007), when i launch the application, this raise an AV
during the component initialization.
with Delphi 2009 : no problem, the application starts smoothly.
My questions are :
Are there known enhancements of ActiveX management in recent Delphi versions which
can explain this difference ?
Can I suspect a bug in the ActiveX control, or can I consider the origin of the
problem is from old Delphi versions ?
I need to use this component (if tests OK) in D2007.
Do you think that it is possible to correct the AV problem under D2007 by modifying the D2007 generated .tlb file (for example by trying to use the D2009 generated one)
PS: the ActiveX control is not named, because my question is a general question about Delphi and ActiveX, not about a specific ActiveX control.
Edit :
With D2007, the error (an Access Violation) appears during Application.CreateForm(TForm1, Form1);
and more specifically when the Olecontrol is created :
procedure TOleControl.CreateInstance;
var
ClassFactory2: IClassFactory2;
LicKeyStr: WideString;
procedure LicenseCheck(Status: HResult; const Ident: string);
begin
if Status = CLASS_E_NOTLICENSED then
raise EOleError.CreateFmt(Ident, [ClassName]);
OleCheck(Status);
end;
begin
if not (csDesigning in ComponentState) and
(FControlData^.LicenseKey <> nil) then
begin
// ON THE LINE BELOW : the call of CoGetClassObject raise an AV
OleCheck(CoGetClassObject(FControlData^.ClassID, CLSCTX_INPROC_SERVER or
CLSCTX_LOCAL_SERVER, nil, IClassFactory2, ClassFactory2));
LicKeyStr := PWideChar(FControlData^.LicenseKey);
LicenseCheck(ClassFactory2.CreateInstanceLic(nil, nil, IOleObject,
LicKeyStr, FOleObject), SInvalidLicense);
end else
LicenseCheck(CoCreateInstance(FControlData^.ClassID, nil,
CLSCTX_INPROC_SERVER or CLSCTX_LOCAL_SERVER, IOleObject,
FOleObject), SNotLicensed);
end;
As far as I remember there were major enhancements to the ActiveX/TLB import in Delphi 2009 (related to Unicode support) - that might explain it.
In my personal experience Delphi 7 and Delphi 2007 repeatedly failed to import some Windows 7 type libraries (various new interfaces to work with new taskbar), but Delphi 2009 managed that without any problems at all.
As for using Delphi 2009 generated file in earlier versions - beware of Unicode issues. Plus it won't help if the defect is in RTL... Try to make a wrapper ActiveX in Delphi 2009 and use it in Delphi 2007 - that should work.
Sorry to barge in so late after the battle (5 years later as a matter of fact), but I wasted so much time on this precise issue that I thought I should share what I've seen and what I've done to solve it :
2 machines (win7 64 / win 8.1) same delphi 7 (same version same build), same activeX (MapX to name it) with identical .lic files containing the key made of 59 characters :
uQnZi2sFw22L0-MRa8pYX-1E2P8065-5N5M3459-3C934220-04969-6562
same import producing 2 slightly different TLB.
The one working : (on win 8.1) contains this in procedure TMap.InitControlData :
const
CLicenseKey: array[0..61] of Word = ( $0075, $0051, $006E, $005A, $0069, $0032, $0073, $0046, $0077, $0032, $0032
, $004C, $0030, $002D, $004D, $0052, $0061, $0038, $0070, $0059, $0058
, $002D, $0031, $0045, $0032, $0050, $0038, $0030, $0036, $0035, $002D
, $0035, $004E, $0035, $004D, $0033, $0034, $0035, $0039, $002D, $0033
, $0043, $0039, $0033, $0034, $0032, $0032, $0050, $0030, $002D, $004D
, $0030, $0034, $0039, $0036, $0039, $002D, $0036, $0035, $0036, $0032
, $0000);
which translates to a 61 char key
uQnZi2sFw22L0-MRa8pYX-1E2P8065-5N5M3459-3C93422P0-M04969-6562
The TLB that does not work (win 7 64) contains this instead:
const
CLicenseKey: array[0..2] of Word = ( $0050, $004D, $0000);
which translates to a 2 char key
PM
Replacing one const with the other and recompiling the component solved my issue. I don't really know what happened. I just know the Import/TLB produced a bad .pas file that can be corrected manually.