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;
Related
I have some problems to create an instance of the StarOffice Desktop object.
I used the standard construct below but whenever it comes to the line: StarDesktop := StarOffice.CreateInstance('com.sun.star.frame.Desktop');
My StarDesktop Variant stays unassigned. I am pretty sure that the code is ok until there but perhaps something with the OpenOffice installation is messed up.
Is there a way to check the com objects or did somebody had the same problem and could solve it...
uses
ComObj;
procedure OpenOfficeDocument;
var
StarOffice: Variant;
StarDesktop: Variant;
begin
StarOffice := CreateOleObject('com.sun.star.ServiceManager');
StarDesktop := StarOffice.CreateInstance('com.sun.star.frame.Desktop');
// StarDesktop is always "unassigned"
....
Yes, I know. I should have stated more clearly that I am too 100% sure that it would work normally in a correct environment.
But my question is what could be the cause why it doesn't work. Why the 'com.sun.star.frame.Desktop' instance is unassigned. I have no option/way to debug it...
And it is a bit unfair to vote me down, I researched for one hour without finding something to explain why it could not work.
Or how and where to check if something is wrong with the Office installation (I uninstalled and reinstalled it twice already"
Again, I know this will work for others and normally would work for me, but something is wrong at my system and I would like to know some help to point me in the direction what could be wrong in the system (and not in the code example...)
is OpenOffice installed on client?
doesn't throw any exception?
I'm using Bernard Marcelly's Delphi 7 OOo tool and as can you see his code like that;
var
OpenOffice, StarDesktop: Variant;
...
OpenOffice:= CreateOleObject('com.sun.star.ServiceManager');
if isNullEmpty(OpenOffice) then Raise Exception.Create('OpenOffice connection is impossible');
StarDesktop:= OpenOffice.createInstance('com.sun.star.frame.Desktop');
if isNullEmpty(Result) then Raise Exception.Create(Format('Impossible to create service : %s', ['com.sun.star.frame.Desktop']));
...
'some constants converted to string'
So, if StarDesktop is null, possible can not access Oo Desktop service. If OpenOffice installed properly some features may be missing, options have to set.
This works for me (in my application):
class procedure TOpenOffice.Connect;
begin
if IsConnected then
Exit;
try
FServiceManager := CreateOleObject('com.sun.star.ServiceManager');
except
FServiceManager := Null;
end;
if VarIsNull(FServiceManager) then
raise EOpenOfficeException.Create(StrConnectionFailed);
FDesktop := CreateService('com.sun.star.frame.Desktop');
FDispatchHelper := CreateService('com.sun.star.frame.DispatchHelper');
FIntrospection := CreateService('com.sun.star.beans.Introspection');
FReflection := CreateService('com.sun.star.reflection.CoreReflection');
end;
and:
class function TOpenOffice.CreateService(const ServiceName: string): Variant;
begin
Result := FServiceManager.createInstance(ServiceName);
if VarIsNull(Result) then
raise EOpenOfficeException.CreateFmt(StrCouldNotCreateService,
[ServiceName]);
end;
I'm currently developing some simple auto-updater app. The most important feature is the possibility of self updating. That's why I plan to put most logic in external DLL. After my DLL grown a little I started to get problems with FreeLibrary call in main app. During dll debugging I've found function responsible for that bug:
function TpmDSServerUpdateDownloader.DownloadUpdates: Boolean;
var
LSQLConnection: TSQLConnection;
LSQLServerMethod: TSqlServerMethod;
LUpdatePackageLink: string;
begin
try
{$IFDEF DEBUG}
Sleep(10000);
{$ENDIF}
// Getting update package link
FUpdateServerIP := '127.0.0.1';
FUpdateServerPort := 8080;
LSQLConnection := TSQLConnection.Create(nil);
LSQLServerMethod:= TSQLServerMethod.Create(nil);
LSQLConnection.DriverName :='DataSnap';
LSQLConnection.LoginPrompt := False;
LSQLConnection.Params.Add('CommunicationProtocol=HTTP');
LSQLConnection.Params.Add('Hostname=' + FUpdateServerIP);
LSQLConnection.Params.Add('Port=' + IntToStr(FUpdateServerPort));
LSQLConnection.Params.Add('ConnectTimeout=' + IntToStr(10000));
LSQLConnection.Connected := True;
LSQLServerMethod.SQLConnection:= LSQLConnection;
LSQLServerMethod.ServerMethodName:= 'TServerMethods1.GetUpdatePackageLink';
LSQLServerMethod.Params[0].AsInteger := 1;
LSQLServerMethod.ExecuteMethod;
LUpdatePackageLink := LSQLServerMethod.Params[1].AsString;
// Downloading update package with LUpdatePackage link
finally
LSQLConnection.Connected := False;
LSQLServerMethod.Free;
FreeAndNil(LSQLConnection);
end;
end;
The problem appears when I'm using dbExpress components from that function. I'm wondering if freeing the TSQLConnection/TSQLServerMethod leaves some working dbExpress threads/objects like it was with SQLMonitor in IBObjects. Maybe you have some ideas how to solve that? I would be very grateful for help.
Greetings
Michal
This is a Delphi BUG.
However there is a solution:
following Microsoft closing thread cannot be called from DLL unload, so FreeLibrary freez on WaitForMultipleObject inifinite loop in the TThread.WaitFor proc of the TDBXScheduler which is created in the initialization section of the Data.DBXCommon and going to be auto close in the finialization section of that unit. This makes the error. So we must close that thread earlier.
The solution is you need to export new procedure and call it before FreeLibrary:
uses
Data.DBXCommon
.....
procedure FinishDLLWork; stdcall; export;
begin
TDBXScheduler.Instance.Free;
end;
and call it just before FreeLibrary;
TDBXScheduler on freeining TDBXScheduler.Instance will auto set it to Nil so this call is fine(check TDBXScheduler.Destroy;)
Unfortunately it cannot be called in the DLL_THREAD_DETACH or DLL_PROCESS_DETACH - it is too late.
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.
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.
Been trying to use the following code in order to check if Windows Aero is enabled:
function AeroEnabled: boolean;
var
enabled: bool;
begin
// Function from the JwaDwmapi unit (JEDI Windows Api Library)
DwmIsCompositionEnabled(enabled);
Result := enabled;
end;
...
if (CheckWin32Version(5,4)) and (AeroEnabled) then
CampaignTabs.ColorBackground := clBlack
else begin
GlassFrame.Enabled := False;
CampaignTabs.ColorBackground := clWhite;
end;
However, doing so on a pre-vista machine causes the app to crash because the DWMApi.dll is missing. I've also tried this code however it produces 2 AV's in a row. How can I do this ? I am using Delphi 2010. :)
You've got your versions wrong. Vista/2008 server are version 6.0. Your test should be:
CheckWin32Version(6,0)
I believe that you are using Delphi 2010 or later in which case you should simply call the DwmCompositionEnabled function from the built-in Dwmapi unit. This organises the version check and the delayed binding for you. No need for JEDI.
Edit: Text below was written before the question was edited.
Probably the easiest approach is to check the Windows version. You need Win32MajorVersion>=6 (i.e. Vista or 2008 server) in order to call DwmIsCompositionEnabled.
If you were binding yourself then you would call LoadLibrary with DWMApi.dll and if that succeeded you would then call GetProcAddress to bind. If that succeeded you are good. But, as I said, since you aren't handling the binding yourself then a version check is probably the simplest.
So the function would be:
function AeroEnabled: boolean;
var
enabled: bool;
begin
if Win32MajorVersion>=6 then begin
DwmIsCompositionEnabled(enabled);
Result := enabled;
end else begin
Result := False;
end;
end;
Note, I'm assuming that your library is doing late binding, i.e. explicit linking. If not then you'll need LoadLibrary/GetProcAddress, exactly as is done in #RRUZ's code to which you link.