I have written a code with Delphi 2009 and updated my CodeGear Delphi to XE2. It compiled perfectly with Delphi 2009, but now it doesn't ! It gives me this error instead :
[DCC Error] Incompatible types: 'TFormStyle' and 'TTeeFontStyle'!
I tried creating a new Vcl Forms Application and wrote the command that generates this error :
Form1.FormStyle := FsNormal;
and it compiled perfectly too,I don't know why is this happening, although I believe there's nothing wrong with my syntax, please help, thanks.
This is the code that is not compiling :
procedure TForm1.ApplicationEvents1Message(var Msg: tagMSG;
var Handled: Boolean);
begin
begin
KeyPreview := True;
case Msg.message of
WM_KEYDOWN:
if Msg.wParam = 27 then
begin
form1.Menu:=mainmenu1;
fullscreen1.Checked:=false;
form1.formstyle:=fsnormal;
form1.BorderStyle:=bssizeable;
end
else
if msg.wParam=VK_f5 then
begin
browser.Navigate(memo2.Text);
end;
end;
end;
end;
There is name conflict with some TeeChart module, which is in "use" clause. You can write full-qualified identificator name to resolve this problem:
formstyle := Vcl.Forms.fsnormal;
P.S. Note that I deleted "form1." qualifier also. Normally it is not very useful in the form method body, and sometimes even harmful (imagine that you have multiple instances of TForm1)
In addition to the answer of MBo, I think it is better to use:
Self.formstyle := Vcl.Forms.fsnormal;
When you have multiple instances of TForm1, this will always adjust the instance you are using at that moment.
Qualify the value with the particular enum type that it comes from:
Form1.FormStyle := TFormStyle.fsNormal;
Or even:
Form1.FormStyle := Vcl.Forms.TFormStyle.fsNormal;
Related
I stumbled upon a bug in Delphi 10 Seattle Update 1. Lets take the following code :
procedure TForm1.Button1Click(Sender: TObject);
begin
//----------We crash here----------------
FList.Items[0] := SplitString('H:E', ':');
end;
procedure TForm1.FormCreate(Sender: TObject);
begin
FList := TList<TStringDynArray>.Create;
FList.Add(SplitString('H:E', ':'));
FList.Items[0] := SplitString('H:E', ':');
end;
At first glance, it would appear that TList<T> doesn't properly manage the lifetime of the dynamic arrays it contains, but then again, it works just fine if compiled in 64 bits, it only crash in 32 bits (I understand it doesn't mean the bug isn't present in 64 bits...).
Note that SplitString was used because if was the first function returning a dynamic array that came to my mind. The original problem was encountered with TList<TBookmark> which exhibits the same problem.
It is possible to work around the bug rewriting the procedure Button1Click like this :
procedure TForm1.Button1Click(Sender: TObject);
var MyArray : TStringDynArray;
begin
MyArray := FList.Items[0];
FList.Items[0] := SplitString('H:E', ':');
//----------Yeah! We don't crash anymore!-----------
end;
But going around all my applications modifying them to work around this bug would not really be my prefered option. I'd much prefer find the offending routine and patch it in-memory if possible.
If anyone encountered this problem and found a workaround, I'd be grateful. Otherwise, I'll post mine when/if I find a proper workaround.
Also, please comment if the problem is still present in Berlin.
After all, the bug was still there in 64 bits. It didn't crash for TStringDynArray, but it did for other dynamic array types.
The source of the problem is found in the following code in Generics.Collections :
procedure TListHelper.DoSetItemDynArray(const Value; AIndex: Integer);
type
PBytes = ^TBytes;
var
OldItem: Pointer;
begin
OldItem := nil;
try
CheckItemRangeInline(AIndex);
TBytes(OldItem) := PBytes(FItems^)[AIndex];
PBytes(FItems^)[AIndex] := TBytes(Value);
FNotify(OldItem, cnRemoved);
FNotify(Value, cnAdded);
finally
DynArrayClear(OldItem, FTypeInfo); //Bug is here.
end;
end;
What happen is, the wrong TypeInfo is passed to DynArrayClear. In the case of a TList<TStringDynArray>, TypeInfo(TArray<TStringDynArray>) is passed instead of TypeInfo(TStringDynArray). From what I can tell, the proper call is:
DynArrayClear(OldItem, pDynArrayTypeInfo(NativeInt(FTypeInfo) + pDynArrayTypeInfo(FTypeInfo).Name).elType^);
The procedure being private makes it complicated to intercept. I did so using the fact that record helper can still access the private section of records in Delphi 10. I guess it will be more complicated for Berlin's users.
function TMyHelper.GetDoSetItemDynArrayAddr: TDoSetItemDynArrayProc;
begin
Result := Self.DoSetItemDynArray;
end;
Hopefully, Embarcadero will fix it someday...
My Delphi application has a form that uses the Acrobat Reader ActiveX control for viewing pdfs. When I use the control's functions (LoadFile, gotoNextPage, gotoPreviousPage, gotoFirstPage, gotoLastPage), then close the form, I get the following error: "Access violation at address 6AF5703C. Read of address 6AF5703C". When I run the app, but do not use the control's functions, and then close the form, the app will exit without error.
Anyone know of a fix or workaround for this issue?
My app is written using Delphi 5 (legacy app). I have Adobe Acrobat Reader DC v15.016.20045 installed.
As I said in a comment to Zam, with the current version downloaded today of Acrobat Reader DC , I get the exact same error as you.
Please try this code and let us know whether it avoids the error for you, because it certainly works for me and there is no AV, either in the FormClose or afterwards.
procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
var
Ref : Integer;
begin
Ref := AcroPdf1.ControlInterface._AddRef;
AcroPdf1.Src := '';
AcroPdf1.Free;
AcroPdf1 := Nil;
end;
This is my FormCreate, which contains my only other code.
procedure TForm1.FormCreate(Sender: TObject);
begin
AFileName := 'd:\aaad7\pdf\printed.pdf';
AcroPdf1.src := AFileName;
AcroPdf1.setZoom(200); // <- this line is to exercise the
// ControlInterface to provoke the AV on shutdown
end;
I have absolutely no idea why my FormClose avoids the AV problem, and before anybody else says so, yes, it looks mad to me, too! Hardly something that deserves the name "solution", but maybe it will suggest a proper solution to someone who knows more about COM and Ole controls than I do.
I originally included the Ref := AcroPdf1._AddRef just as an experiment. I noticed that after it, Ref's value was 9. After AcroPdf1.Src := '', calling AcroPdf1._Release in the debugger evaluator returned a value of 4. I was about to see if the AV was avoided by forcing the RefCount down by repeatedly calling _Release but then Presto!, there was no AV after my first trace into FormClose exited.
Update: I have not tested the following exhaustively, but this simplified FormClose also avoids the AV, on my system at any rate:
procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
var
Ref : Integer;
begin
Ref := AcroPdf1.ControlInterface._AddRef;
end;
Obviously, omitting the assignment to Ref shouldn't make any difference.
I'm using Delphi 10 Seattle on 64-bit Win10, btw.
The better solution is to edit the TPDF Object in "AcroPDFLib_Tlb.pas"
Just add the proper destructor to the Code to free the OLE Object:
Declaration
Type
TAcroPDF = class(TOleControl)
...
public
destructor Destroy; override; // <- New Line
...
end;
Implementation
destructor TAcroPDF.Destroy;
begin
FIntf := NIL;
inherited;
end;
This follows on from my answer to this Q:
Can I change the display format for strings in the watch list?
It turns out that at some point between D7 and XE3, the implementation of the IDE's Watch Window changed from using a TListView to a TVirtualStringTree.
Although I posted an update to my answer that works with XE4 by ignoring the VST and getting the watch value from the clipboard, I'd still like to be able to get the watch value from the VST if I can. I think I know how to do that
once I have a reference to the VST but the problem is that my attempt to get one fails.
Following is an MCVE of the code I'm using in my custom package. Hopefully, what it does is self-explanatory. The problem is that the code in the block
if WatchWindow.Components[i] is TVirtualStringTree then begin
[...]
end;
never executes, DESPITE the classname "TVirtualStringTree" appearing in Memo1. Obviously the component with that classname fails the "is" test. I'm guessing that the reason is that the TVirtualTreeView compiled into the IDE is a different version that the one I'm using, v.5.3.0, which is the nearest predecessor I could find to XE4.
So, my question is, is that the likely explanation, and is there anything I can do about it? I suspect if someone can flourish the version of TVirtualStringTree that was used for XE4 from a hat, that might solve my problem.
type
TOtaMenuForm = class(TForm)
Memo1: TMemo;
procedure FormCreate(Sender: TObject);
private
WatchWindow : TForm;
VST : TVirtualStringTree;
end;
procedure TOtaMenuForm.FormCreate(Sender: TObject);
var
i : Integer;
S : String;
begin
WatchWindow := Nil;
VST := Nil;
// Iterate the IDE's forms to find the Watch Window
for i := 0 to Screen.FormCount - 1 do begin
S := Screen.Forms[i].Name;
if CompareText(S, 'WatchWindow') = 0 then begin
WatchWindow := Screen.Forms[i];
Break;
end;
end;
Assert(WatchWindow <> Nil);
if WatchWindow <> Nil then begin
Memo1.Lines.Add('Looking for VST');
for i := 0 to WatchWindow.ComponentCount - 1 do begin
Memo1.Lines.Add(IntToStr(i) + ':' + WatchWindow.Components[i].ClassName);
if WatchWindow.Components[i] is TVirtualStringTree then begin
VST := TVirtualStringTree(WatchWindow.Components[i]);
Memo1.Lines.Add('found VST');
Break;
end;
end;
if VST = Nil then
Memo1.Lines.Add('VST not found');
end;
end;
Btw, I realise that solutions that depend of implementational details of IDE are likely to be fragile, but this is just for amusement (I liked the challenge of getting string data out of a component that goes out of its way to avoid storing any).
May be You can try to use only published properties of embedded into IDE TVirtualStringTree implementation through RTTI methods to do what you want?
Beware of Exit command usage in inline functions! I have been using Delphi XE3 here.
Symptom
In certain circumstances, when a call is made to an inline function that contains Exit command, and the return value of the inline function is used directly in WriteLn(), the compiler reports an error message,
"dcc" exited with code 1.
or even worst, the Delphi IDE terminates without any confirmation.
function ProcessNumber(const iNumber: Integer): Boolean; inline;
begin
if iNumber = 0 then begin
Result := False;
Exit;
end;
// some code here ...
Result := True;
end;
procedure Test;
begin
writeln( ProcessNumber(0) );
end;
begin
Test;
ReadLn;
end.
However, if the return value of the inline function is stored in a variable, and then the variable is used in WriteLn(), the problem does not occur.
procedure Test;
var
b: Boolean;
begin
b := ProcessNumber(0);
writeln(b);
end;
Questions
Is this a compiler bug?
If this a bug, is there a workaround to safely exit from an inline function?
This is certainly a bug. It occurs in all the IDE versions that I tested, XE3, XE7 and XE8. I honestly don't think there's a lot you can do. For me the IDE terminates on compilation every time. I think you'll just have to write the code in a way that does not lead to IDE crashes.
You can use the IDE option that forces compilation to use msbuild. This puts the compilation into a separate process and so ensures that the IDE won't crash. It won't help you much though because although your IDE will not keep dying, you still won't be able to compile your program!
When you build with msbuild, you get an error of this form:
error F2084: Internal Error: GPFC00000FD-004D3F34-0
The GPF stands for General Protection Fault, that is an memory access violation. This presumably is an unhandled exception that is killing the IDE when the compilation is performed in process.
My advice is that you submit a bug report to Quality Portal. That is the only way to get the defect fixed. Although do not expect a fix ever to come to XE3.
One workaround that you could use here is to reverse the if conditional implementation and thus avoid using of Exit command altogether.
So instead of using
function ProcessNumber(const iNumber: Integer): Boolean; inline;
begin
if iNumber = 0 then begin
Result := False;
Exit;
end;
// some code here ...
Result := True;
end;
use
function ProcessNumber(const iNumber: Integer): Boolean; inline;
begin
if iNumber <> 0 then begin
// some code here
Result := True;
end;
else
Result := False;
//No exit needed here as this is already at the end of your method
end;
Someone managed to install InstantObjects in Delphi XE4?
I'm compiling the latest sources who are on svn repository. After correcting some issues as the compiler version, I am stuck in the following code snippet:
procedure TInstantAccessor.SetOnCompare(Value: TInstantCompareObjectsEvent);
begin
if #Value <> #FOnCompare then
begin
FOnCompare := Value;
RefreshView;
end;
end;
Resulting in the error message "[dcc32 Error] InstantPresentation.pas (1580): E2008 Incompatible types" on the line:
if #Value <> #FOnCompare then
But they are the same type: TInstantCompareObjectsEvent
What's wrong?
Maybe casting the procedural pointer to the generic Pointer type can solve:
procedure TInstantAccessor.SetOnCompare(Value: TInstantCompareObjectsEvent);
var
PValue, PFOnCompare: Pointer;
begin
PValue := Pointer(#Value); // Casting the original pointer to an generic pointer
PFOnCompare := Pointer(#FOnCompare);
if #PValue <> #PFOnCompare then
begin
FOnCompare := Value;
RefreshView;
end;
end;
What Fabricio wrote in the comments make sense. I surrounded the code with the directives {$T-} and {$T+} and the code compiled!
Now I'm in trouble in other parts of the code, but that's another story.
procedure TInstantAccessor.SetOnCompare(Value: TInstantCompareObjectsEvent);
begin
{$T-}
if #Value <> #FOnCompare then
begin
FOnCompare := Value;
RefreshView;
end;
{$T+}
end;
Thank you all.