I'm using Delphi XE5.
On my GroupFooter I try to hide several memos in a conditional is met
procedure GroupFooter1OnBeforePrint(Sender: TfrxComponent);
begin
ShowMessage('a');
if <frxDB."total_payment"> <= 0 then begin
Memo27.Visible := False;
Memo28.Visible := False;
Memo29.Visible := False;
Memo30.Visible := False;
end;
end;
This is my calling code in Delphi
Report.LoadFromFile(CurDir+'reports/invoice/'+ReportName);
if Report.PrepareReport then
Report.ShowPreparedReport;
I found that the OnBeforePrint event never fires when the report was showing after frxReport.ShowPreparedReport command, but when I tries to preview it in the designer, it works just as normal.
I keep wondering what did I miss.
Anyone can help?
Thanks
I recently found out that this is due to FastReport 4 demo version that is bundled along with Embarcadero RAD Studio XE5. The full version works perfectly, but any fr3 file created from demo-bundled version can't be opened in full version.
Related
I'm trying to call Chromium Dev Tools with this code from dcef3 demos:
procedure TMainForm.actDevToolExecute(Sender: TObject);
begin
actDevTool.Checked := not actDevTool.Checked;
debug.Visible := actDevTool.Checked;
Splitter1.Visible := actDevTool.Checked;
if actDevTool.Checked then
begin
if not FDevToolLoaded then
begin
debug.Load(crm.Browser.Host.GetDevToolsUrl(True));
FDevToolLoaded := True;
end;
end;
end;
When i'm running programm, and pressing DevTools button, nothing happens, empty window, empty source code.
For Debug im trying this:
showmessage(crm.Browser.Host.GetDevToolsUrl(True));
And it return nothing(empty string).
But this code Works Fine in dcef3 guidemo... And not works in my Programm.
Whats a problem?
Here is dcef3 guiclient demo Full Code - http://dumpz.org/589068/
Thanks
Searching yields a discussion on Google Groups where Henri Gourvest explains that for the dev-tools URL to work, you need to define a debugging port. For example:
CefRemoteDebuggingPort := 9000;
If that doesn't work, then you need to compare your code with the working demo and identify what else you're doing differently.
I am migrating the code from Delphi 7 to XE2 one of the Graphical module.
we are using TRect variable , the old code is working in Delphi 7 without issue
Ex:
Var
Beold : TRect
begin
Beold.left := Beold.right;
end.
while porting the code to new XE2 we are facing the issue
E0264 : Left side cannot be assigned to
Can you please explain what is the changes in XE2 TRect and D7, how we can assign the valuse
The code you posted compiles and runs fine in a quick Delphi test app, so it's not your real code.
I'd suspect what you've hit is a change in the with statement when it's related to using properties, however. There was a bug in previous versions of Delphi that existed for many years that was finally fixed recently. IIRC, it was first mentioned in a note in the README.HTML file for D2010. It's been added to the documentation in XE2 (not as a behavior change, but the new behavior is documented). The documentation is located here at the docwiki.
(Additional info: It must have been 2010 where it changed; Marco Cantù's Delphi 2010 Handbook mentions it on page 111 as "The With Statement Now Preserves Read-Only Properties" which describes this behavior and the solution I indicated below.)
Instead of accessing the property of a class directly using a with statement, you now need to declare a local variable, and read and write the whole thing directly (error handling omitted for clarity - yes, I know there should be a try..finally block to free the bitmap).
var
R: TRect;
Bmp: TBitmap;
begin
Bmp := TBitmap.Create;
Bmp.Width := 100;
Bmp.Height := 100;
R := Bmp.Canvas.ClipRect;
{ This block will not compile, with the `Left side cannot be assigned to` error
with Bmp.Canvas.ClipRect do
begin
Left := 100;
Right := 100;
end;
}
// The next block compiles fine, because of the local variable being used instead
R := Bmp.Canvas.ClipRect;
with R do
begin
Left := 100;
Right := 100;
end;
Bmp.Canvas.ClipRect := R;
// Do other stuff with bitmap, and free it when you're done.
end.
turns out, using
with (Bmp.Canvas.ClipRect) do
begin
Bottom := 100;
end;
throws error: [Left side cannot be assigned to]
Yet,
with Bmp.Canvas.ClipRect do
begin
Bottom := 100;
end;
does not.
Delphi 10.3.3 is just as finicky about parenthesis as the older versions.
I am currently working on very old project, which is based on Delphi 5. When I am trying to open new Word document on x64 system, I recive this error:
According to MSDN, the source of problem might be the version of my Office (x64). In application we use TWordApplication object to manage Word invoking. Is there any solution for that problem? On Office x86 everything works fine.
This is part of the code:
Word := TWordApplication.Create(nil);
Word.ConnectKind := ckNewInstance;
Word.AutoQuit := True;
Word.Connect;
Word.Options.CheckSpellingAsYouType := False;
Word.Options.CheckGrammarAsYouType := False;
Word.Options.SuggestSpellingCorrections := False;
Word.Options.CheckGrammarWithSpelling := False;
Word.Options.ShowReadabilityStatistics := False;
Word.Options.IgnoreInternetAndFileAddresses := False;
Word.Options.IgnoreUppercase := True;
Word.Options.IgnoreMixedDigits := True;
Word.Options.ReplaceSelection := True;
The problem appears to be in the VBA code attached to your document rather than the Delphi code. Specifically a hidden module named API is implicated. Perhaps this is in a template or an add-in or an auto start.
Hidden modules are protected which suggests that you may not be able to modify the module. You could try contacting the author of the protected module or perhaps removing whatever it is that introduced this module.
Reverting to 32 bit Office is an easier solution. This will require you to uninstall 64 bit Office first since the two editions do not co-exist.
I did a checkout of d-gecko SDK from sf.net ( http://sourceforge.net/projects/d-gecko/ ).
I wanted to try it with Gecko (XULRunner) 1.9, however when running simple application each time I get error in stdcall function, pointing to WebBrowser.Paint line ...
My question is - did anyone succeeded to run GeckoSDK Delphi app in XULRunner 1.9?
If so - how? Did it worked out-of-the-box for you?
Thanks
m.
You need to navigate somewhere before the webbrowser first attempts to paint itself. So, LoadURI() must be called before the component is visible.
Easiest solution: Call LoadURI('about:blank') before the component is visible.
I had also this problem. I just neutralized baseWin.Repaint(True);
Il all worked perfectly afterward
procedure TCustomGeckoBrowser.Paint;
var
rc: TRect;
baseWin: nsIBaseWindow;
begin
if csDesigning in ComponentState then
begin
rc := ClientRect;
Canvas.FillRect(rc);
end else
begin
baseWin := FWebBrowser as nsIBaseWindow;
//baseWin.Repaint(True);
end;
inherited;
end;
I've recently had a customer report an issue with my applications and NVidia nView desktop manager. Basically nView seems to 'unhide' hidden secondary forms when moving an application between monitors. I'm testing with Delphi 2010. The problem can also be seen using just the IDE (show a non-docked window, close it and then choose to send the Delphi IDE to a different monitor.) The previously hidden forms are in an unresponsive state and can't be closed.
To reproduce:
. Use a multi-monitor system with NVidia nView desktop manager.
. Start any Delphi application with secondary forms that will be hidden when they are closed.
. Show or ShowModal the form, then close it (form needs to have been shown at least once).
. Choose to send the application to a different monitor. (via hotkeys or the caption icons)
. The application will move to the other monitor and any hidden forms will be visible.
Has anyone else seen this issue? I've verified it with an older version of nView, but a customer with the latest version has the issue whenever he tries to move the main form or resize it. Unfortunately my laptop can't be updated to the latest version so I can't easily test with it.
Thanks for any comments or suggestions!
-Mark
I had the same problem. The Delphi application stopped responding without any obvious reason. Looking at the stack trace from madExcept I could see that the application froze in nview.dll. The only "solution" that I found was to look for nView and advise the user to turn it off using the code below:
function CheckForNview: Boolean;
function IsNviewModuleRunning(AHandle: THandle; AProcessId: DWord): Boolean;
var
AModuleEntry: TModuleEntry32;
begin
AModuleEntry.dwSize := SizeOf(AModuleEntry);
AModuleEntry.th32ProcessID := AProcessId;
Result := False;
if Module32First(AHandle, AModuleEntry) then
begin
if SameStr(AModuleEntry.szModule, 'nview.dll') then
Result := True;
while Module32Next(AHandle, AModuleEntry) do
begin
if SameStr(AModuleEntry.szModule, 'nview.dll') then
Result := True;
end;
end;
end;
var
AHandle: THandle;
AProcessEntry: TProcessEntry32;
begin
Result := False;
AHandle := CreateToolhelp32Snapshot(TH32CS_SNAPALL, 0);
if Process32First(AHandle, AProcessEntry) then
begin
if SameStr(AProcessEntry.szExeFile, ExtractFileName(ParamStr(0))) then
Result := Result or IsNviewModuleRunning(AHandle, AProcessEntry.th32ProcessID);
while Process32Next(AHandle, AProcessEntry) do
begin
if SameStr(AProcessEntry.szExeFile, ExtractFileName(ParamStr(0))) then
Result := Result or IsNviewModuleRunning(AHandle, AProcessEntry.th32ProcessID);
end;
end;