Having this:
procedure Foo;
begin
end;
function Bar: TProcedure;
begin
Result := Foo;
end;
The following compiles:
var
tmp: TProcedure;
begin
tmp := Bar();
tmp();
...but the following doesn't compile in Delphi:
Bar()();
Is there a reason for this "limitation"? Does Bar()(); syntax compile in some other "flavour" of Pascal? Would Bar()(); syntax compile in some other context?
Simply call as
TProcedure(Bar());
I don't think there is a limitation in the grammar of the language. The statement Bar()() should be valid. So, I believe that this is a compiler bug in older versions of Delphi. This program compiles in Delphi 2010 and later:
{$APPTYPE CONSOLE}
uses
SysUtils;
procedure Foo;
begin
end;
function Bar: TProcedure;
begin
Result := Foo;
end;
begin
Bar()();
end.
It is quite possible that the compiler bug was fixed before Delphi 2010, it's just that's the version that I have to hand. It seems that the bug is still present in Delphi 7, and fixed by Delphi 2010. So the bug appears to have been fixed somewhere in between those two versions.
Update 1
Marco reports that the Free Pascal compiler accepts Bar()().
Update 2
Rudy has done some testing and reports that the bug is still present in D2007 so the fix was either D2009 and D2010. My instincts tell me that Embarcadero would have discovered the problem themselves when adding the anonymous methods feature and that would have been the trigger for the fix to be made.
Related
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;
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;
I have created a procedure in a dll that opens a form and then prints a report.
This procedure works perfectly from an exe.
I have wrapped the unit that contains this procedure and forms in a dll and exported the procedure as follows:
{$R *.res}
Procedure PrintTopSellers; stdcall;
begin
Form1 := TForm1.create(nil);
GetMonth := TGetMonth.create(nil);
Form1.PrintTopSellers;
end;
exports PrintTopSellers;
begin
end.
Now I call this procedure PrintTopSellers from an exe as follows:
procedure TForm1.Button5Click(Sender: TObject);
type
TRead_iButton = function :integer;
var
DLL_Handle: THandle;
Read_iButton: TRead_iButton;
Begin
DLL_Handle := LoadLibrary('c:\Catalog.dll');
if DLL_Handle <> 0 then
begin
#Read_iButton:= GetProcAddress(DLL_Handle, 'PrintTopSellers');
Read_iButton;
end;
application.ProcessMessages;
FreeLibrary(DLL_Handle);
end;
The call to the procedure works perfectly. However, after I close the calling exe, I get an access violation - "Access violation at address 00BAC89C. Read of address 00BAC89C."
Appreciate any assistance. I am using Delphi 7.
Thanks
You are creating Form1, a windowed control, in the DLL. But you never destroy it. Then you unload the DLL which unloads the code that implements the window procedures for all windows created by the DLL. Presumably when the process shuts down, the window procedures are called, but there is no code there anymore.
Fix the problem by destroying all objects that the DLL creates. It looks to me like the best approach is to do that when PrintTopSellers terminates.
Procedure PrintTopSellers; stdcall;
begin
Form1 := TForm1.create(nil);
try
GetMonth := TGetMonth.create(nil);
try
Form1.PrintTopSellers;
finally
GetMonth.Free;
end;
finally
Form1.Free;
end;
end;
In the code that loads the DLL, TRead_iButton is declared incorrectly. It should be
TRead_iButton = procedure; stdcall;
But that doesn't actually explain the problem here since the signature mismatch is benign for a parameterless procedure.
"TRead_iButton = function: integer; register;"
"Procedure PrintTopSellers; stdcall;"
Absolutely different conventions/types, ain't them ?
Make them the same.
And better ditch DLL and use packages (BPL), then compiler would make you safe from such errors
We also don't see the code neither in Form1.PrintTopSellers nor in TGetMonth. The all can leave some dangling pointers in the host exe, that would get accesses after DLL unloaded.
Show exactly chain of function calls leading to AV - it is called stack trace.
Debug info + some excaption interrupt like Jedi CodeLibrary (used by Delphi IDE) madExcept, EurekaLog, synopse log and a lot of other exist.
Display the call stack in a Delphi Win32 application
Does DLL or EXE use Runtime packages ?
DLL registration with regsvr32.exe freezes when unit HtmlHelpViewer is used in DLL sources in Delphi XE or Delphi XE2 Update 3. Just add the unit to interface uses list. The main project (that uses DLL) freezes on exit too.
How to fix the issue?
Thanks for the help!
STEPS TO REPRODUCE THE ISSUE AND ISSUE IN SUGGESTED FIX:
1). Please create the following DLL:
library Test;
uses
ComServ,
HtmlHelpFixer,
HtmlHelpViewer;
exports
DllGetClassObject,
DllCanUnloadNow,
DllRegisterServer,
DllUnregisterServer;
begin
end.
2). Also create the following BPL linked to this DLL (by -LUTestBpl dcc32 parameter for example):
package TestBpl;
requires
Vcl;
end.
3). Then just execute: regsvr32.exe /s Test.dll. OS Windows 7 32-bit.
Update
According to the latest comments on the QC report submitted by Altaveron, this problem will be resolved in the next Delphi update, update 4. And indeed, Altaveron now confirms that update 4 does resolve the issue.
This is a known problem with the MS HTML help control, hhctrl.ocx. The best description of it that I am aware of is at the HelpWare FAR HTML FAQ. There are many QC reports describing the issue: 48983, 67463, 78998, 89616.
According to the latest QC report, this is fixed in XE2 but you report otherwise and I'd be inclined to believe you. Especially as a comparison of the source for the HtmlHelpViewer unit from XE and XE2 reveals no changes that appear related to this issue.
It's quite hard to work around the issue since the code that needs to be modified is buried deep inside the HtmlHelpViewer unit. I've had to resort to patching the HtmlHelp API call. Like this:
unit HtmlHelpFixer;
interface
implementation
uses
Windows;
function HtmlHelp(hWndCaller: HWND; pszFile: PWideChar; uCommand: UINT; dwData: DWORD): HWND;
begin
if uCommand=HH_CLOSE_ALL then begin
//don't call HtmlHelpW because it can result in a hang due to a bug in hhctrl.ocx
Result := 0;
end else begin
Result := HtmlHelpW(hWndCaller, pszFile, uCommand, dwData);
end;
end;
procedure PatchCode(Address: Pointer; const NewCode; Size: Integer);
var
OldProtect: DWORD;
begin
if VirtualProtect(Address, Size, PAGE_EXECUTE_READWRITE, OldProtect) then begin
Move(NewCode, Address^, Size);
FlushInstructionCache(GetCurrentProcess, Address, Size);
VirtualProtect(Address, Size, OldProtect, #OldProtect);
end;
end;
type
PInstruction = ^TInstruction;
TInstruction = packed record
Opcode: Byte;
Offset: Integer;
end;
procedure RedirectProcedure(OldAddress, NewAddress: Pointer);
var
NewCode: TInstruction;
begin
NewCode.Opcode := $E9;//jump relative
NewCode.Offset := NativeInt(NewAddress)-NativeInt(OldAddress)-SizeOf(NewCode);
PatchCode(OldAddress, NewCode, SizeOf(NewCode));
end;
procedure RedirectHtmlHelp;
var
HtmlHelp: function(hWndCaller: HWND; pszFile: PWideChar; uCommand: UINT; dwData: DWORD_PTR): HWND;
begin
HtmlHelp := Windows.HtmlHelp;
RedirectProcedure(#HtmlHelp, #HtmlHelpFixer.HtmlHelp);
end;
initialization
RedirectHtmlHelp;
end.
Include this unit early in your .dpr uses list, before any unit that does anything with HTML help.
The version of the code that I use does a little more and takes steps to ensure that any open help windows are closed when the DLL unloads. This no longer happens because we have stopped sending HH_CLOSE_ALL.
You will want to make sure that any help windows are shut down then keep track of the window handles returned by HtmlHelp calls, which you can now intercept. Then at shutdown send a WM_CLOSE message to those windows which replaces the missing HH_CLOSE_ALL call to HtmlHelp.
However, I believe that the code above should get you over your immediate hurdle with regsvr32 which won't be showing help windows.
Feel free to do some experimentation! At the very least, the code above gives you entry points with which you can modify the behaviour of the HtmlHelpViewer unit.
Embarcadero have fixed this issue on Delphi XE2 Update 4. But now context help doesn't work on IDE while you're using BPL with HtmlHelpViewer unit on uses clause.
I want to use some units in both older and newer versions of Delphi. Since a recent Delphi version, Utf8Decode throws a deprecated warning which advises to switch to Utf8ToString. Problem is older versions of Delphi don't declare this function, so which {$IFDEF}label should I use to define a wrapper around Utf8Decode named Utf8String (or perhaps Utf8ToWideString)?
Or in other words: which version was Utf8ToString introduced?
I think I would implement it with an $IF so that calling code can use either the new RTL function, or fall back on the older deprecated version. Since the new UTF8ToString returns a UnicodeString I think it is safe to assume that it was introduced in Delphi 2009.
{$IF not Declared(UTF8ToString)}
function UTF8ToString(const s: UTF8String): WideString;
begin
Result := UTF8Decode(s);
end;
{$IFEND}
As far as I remember:
UTF8String and associated UTF8Encode / UTF8Decode were introduced in Delphi 6;
UTF8ToWideString and UTF8ToString were introduced in Delphi 2009 (i.e. Unicode version), as such:
function UTF8Decode(const S: RawByteString): WideString;
deprecated 'Use UTF8ToWideString or UTF8ToString';
In order to get rid of this compatibility issue, you can either define your own UTF8ToString function (as David propose), or either use your own implementation.
I rewrote some (perhaps) faster version for our framework, which works also with Delphi 5 (I wanted to add UTF-8 support for some legacy Delphi 5 code, some 3,000,000 source code lines with third party components which stops easy upgrade - at least for the manager's decision). See all corresponding RawUTF8 type in SynCommons.pas:
{$ifdef UNICODE}
function UTF8DecodeToString(P: PUTF8Char; L: integer): string;
begin
result := UTF8DecodeToUnicodeString(P,L);
end;
{$else}
function UTF8DecodeToString(P: PUTF8Char; L: integer): string;
var Dest: RawUnicode;
begin
if GetACP=CODEPAGE_US then begin
if (P=nil) or (L=0) then
result := '' else begin
SetLength(Dest,L); // faster than Windows API / Delphi RTL
SetString(result,PAnsiChar(pointer(Dest)),UTF8ToWinPChar(pointer(Dest),P,L));
end;
exit;
end;
result := '';
if (P=nil) or (L=0) then
exit;
SetLength(Dest,L*2);
L := UTF8ToWideChar(pointer(Dest),P,L) shr 1;
SetLength(result,WideCharToMultiByte(GetACP,0,pointer(Dest),L,nil,0,nil,nil));
WideCharToMultiByte(GetACP,0,pointer(Dest),L,pointer(result),length(result),nil,nil);
end;
{$endif}