Geckoport OK, SampleApps OK, webdesign preview NOT OK

[Leledumbo]

I've been troubleshooting this stuff for a long time, and I almost give up. I'm using two days old svn version of fpc and lazarus, plus tonight's svn version of geckoport and webdesign package. I'm using xulrunner version 1.9.2.13 and the whole folder is put in the directory where lazarus.exe exists.

Compilation goes fine, so I try SampleApps. Compilation OK, binary moved to lazarus folder. At first, ChromeWin gives "cannot get the Service Manager" and GBrowser gives "cannot get the Component Manager". So, I recheck, re-register xulrunner with --register-global, SetExceptionMask (which then I rollback because it works without) and retry. OK, both apps are working fine now.

Next, I try HelloWorld webdesign example and... "cannot get the Service Manager" comes again. Hey, has something goes wrong? I retry both previously working SampleApps and they're still working! I wonder why webdesign previewer failed but the SampleApps don't. Please tell me how to fix it.

[Dibo]

I had this same errors on stable version of gecko port. SVN version have errors when installing on my ubuntu 64 bit.

[skobov]

/off topic

From where I can download latest (svn) version of webdesign package.

[Leledumbo]

From where I can download latest (svn) version of webdesign package.

Use fppkg, it will download automatically.

[Phil]

I had this same errors on stable version of gecko port. SVN version have errors when installing on my ubuntu 64 bit.

Did you get compile errors? It appears from the wiki that GeckoPort has been run successfully on Linux, but I don't know about 64 bit Linux or Windows. Probably some of the same issues that affected THtmlPort will affect GeckoPort as well.

Things you can look for:

- Assembler code.
- Casts
- Look for compiler warnings about non portable code.

If you can track down specific problems, please post fixes or bug reports to Mantis. There's a section for Lazarus CCR where you can post bugs for the add-on packages. JoshyFun is now in charge of this project and he's taken it a lot further than I ever could.

Thanks.

-Phil

[Leledumbo]

It appears from the wiki that GeckoPort has been run successfully on Linux, but I don't know about 64 bit Linux or Windows.

That means Win32 should be fine or what? Coz I'm there...

[Phil]

That means Win32 should be fine or what? Coz I'm there...

It's always worked pretty well on Win32 since it was a Delphi project to start with.

Can you get the two sample apps working?

Status here:  http://wiki.lazarus.freepascal.org/GeckoPort

Thanks.

-Phil

[José Mejuto]

It appears from the wiki that GeckoPort has been run successfully on Linux, but I don't know about 64 bit Linux or Windows.

That means Win32 should be fine or what? Coz I'm there...

Win32 is OK, it works since XULRunner 1.9.1.1 to 2.0.0.8 (this last one needs an IFDEF as it is not backwards compatible). 64 bits Windows will not work as as far as I know there is no official 64 bit XULRunner.

For Linux32 with GTK it should work with two problems not already solved, one is that you must add a timer with empty handler, this timer forces the LCL to process events that comes from Gecko, so use a 100 ms timer. The second problem needs a small change in code, in the gecko paint routine add a self.resizeall or the Gecko will dissapear when you resize the window (when attached to some sides).

I'll add this workarounds in code base once they are confirmed as problems with Gecko, not a bug in LCL.

Also in Linux you must provide a LD_LIBRARY_PATH better to Lazarus or you must use the same technique as Firefox, run a loader that sets the environment variable and in that context lauch your application. Linux does not follow the same logic loading .so that windows .dll and as far as I know Linux does not have a LoadLibraryEx equivalent.

You can get more information from http://wiki.lazarus.freepascal.org/GeckoPort

[Dibo]

I posted my errors in mantis

[Phil]

I posted my errors in mantis

Since GeckoPort uses THandle in various places, the same 64-bit fix that THtmlPort required is probably needed here too: Move SysUtils and Classes before LclType in uses in all of GeckoPort units. That way the 64-bit THandle from LclType will be used, rather than the 32-bit THandle from SysUtils or Classes (both =System.THandle, which apparently is always 32-bits).

Also, this line:

  Result := PtrInt(PGtkWindow(Handle)^.default_widget);

Should probably be:

  Result := PtrUInt(PGtkWindow(Handle)^.default_widget);

That won't get rid of the warning, but will guard against a 64-pointer (always unsigned) that is outside the range of a 64-bit signed integer. See here for more:

http://www.freepascal.org/docs-html/rtl/system/ptrint.html

The windres error you're getting is probably not related to GeckoPort?

Thanks.

-Phil

[José Mejuto]

I posted my errors in mantis

Hello,

Errors should be fixed now.

[José Mejuto]

I posted my errors in mantis

Since GeckoPort uses THandle in various places, the same 64-bit fix that THtmlPort required is probably needed here too: Move SysUtils and Classes before LclType in uses in all of GeckoPort units. That way the 64-bit THandle from LclType will be used, rather than the 32-bit THandle from SysUtils or Classes (both =System.THandle, which apparently is always 32-bits).

Hello,

If system.THandle is always 32 bits nothing in 64 bits would work. A different thing is that a THANDLE=integer is laying somewhere. I'm not aware about the 64 bit problems in Thtmlport but it is more probably that an explicit typecast happends instead a Thandle typecast.

Also, this line:
  Result := PtrInt(PGtkWindow(Handle)^.default_widget);
Should probably be:
  Result := PtrUInt(PGtkWindow(Handle)^.default_widget);
That won't get rid of the warning, but will guard against a 64-pointer (always unsigned) that is outside the range of a 64-bit signed integer. See here for more:

A pointer is sign agnostic, it is not important is you use a signed or unsigned variable as it is opaque. In fact THANDLE usually is a pointer but it is a THANDLE which can be a sequential number, a random one, a pointer to an structure, a pointer to a string, or just a number in the lotto The only important thing is that "Result" hold a 64 bits value in 64 bit systems or 32 bits value in 32 bits system as its value is not operable in any way.

The windres error you're getting is probably not related to GeckoPort?

windres does not like filenames with a dash

[Phil]

THandle is declared as System.THandle (32 bits) both in SysUtils and Classes. It's also declared as PtrUInt in LclType on non-Windows systems.

Note that PtrInt and PtrUInt are not pointers, they're integers. So if a PtrUInt THandle is assigned to a PtrInt integer and range checking is on (as it should be during development)...

Thanks.

-Phil

[Leledumbo]

Can you get the two sample apps working?

As the title says, yes. Only the previewer of webdesign doesn't work.

[José Mejuto]

THandle is declared as System.THandle (32 bits) both in SysUtils and Classes. It's also declared as PtrUInt in LclType on non-Windows systems.

Hello,

Just for windows, system includes systemh.inc which includes sysosh.inc which defines:

{$ifdef CPU64}
  THandle = QWord;
  ULONG_PTR = QWord;
{$else CPU64}
  THandle = DWord;
  ULONG_PTR = DWord;
{$endif CPU64}

Note that PtrInt and PtrUInt are not pointers, they're integers. So if a PtrUInt THandle is assigned to a PtrInt integer and range checking is on (as it should be during development)...

And the other way around... In the other hand I'm usually using PtrUint.