TOPIC:

G'day one and all,

I'm having a problem where Lazarus 64bit running under windows 7 professional 64 fails to start, when I say fails to start what actually happens is the splash screen appears as per normal but then nothing, If I check task manager an instance of lazarus is running, bit no IDE whatsoever nada not a thing..

If I clean and compile the small IDE, this runs aok under 64bit, so I'm assuming its something to do with some of the packages being loaded?

Big and Small IDE 32 both run ok as well, just not 64-bit Big IDE.

The windows 7 is a VM running on my Mac and has 4096 Ram allocated to it. Is this enough RAM for the big IDE environment?

I've completely remove Code Typhon and reinstalled a number of times to no avail.

Regards,

Stephen...

seaton wrote: I'm having a problem where Lazarus 64bit running under windows 7 professional 64 fails to start, when I say fails to start what actually happens is the splash screen appears as per normal but then nothing, If I check task manager an instance of lazarus is running, bit no IDE whatsoever nada not a thing..

I use Lazarus 64 on Windows 8 Pro 64 bit without a problem.

Maybe you have to look for other causes then invalid packages .

Good luck!

The small IDE of Lazarus 64 runs out of the box no problems, however if I add a package, any package, and rebuild the IDE then the problem rears it's head as soon as it finishes compiling and restarts.

No errors reported when compiling.

actually even if I just rebuild the default small IDE the problem raises it's head, so no removing or adding packages and the small IDE that has been originally built (and working) from within the CodeTyphon Centre.

I've enabled debug via command line with

C:\codetyphon\lazarus\bin64>lazarus --debug-log=lazarusdebuglog.txt

this is whats reported in the log file

TLResourceList.Sort 354 DUPLICATE RESOURCE TLResourceList.Sort 331 DUPLICATE RESOURCE FOUND: pkg_install:PNG
TLResourceList.Sort 355 DUPLICATE RESOURCE FOUND: pkg_install:PNG
TLResourceList.Sort 355 DUPLICATE RESOURCE FOUND: pkg_install:PNG
TLResourceList.Sort 379 DUPLICATE RESOURCE FOUND: pkg_install:PNG
TLResourceList.Sort 396 DUPLICATE RESOURCE FOUND: pkg_install:PNG
TLResourceList.Sort 396 DUPLICATE RESOURCE FOUND: pkg_install:PNG
TLResourceList.Sort 396 DUPLICATE RESOURCE FOUND: pkg_install:PNG
TLResourceList.Sort 396 DUPLICATE RESOURCE

G'day one and all,

I'm having a problem where Lazarus 64bit running under windows 7 also, but I solved it with changing default printer after look in debuglog file :

lazreport: unit lr_prntr: Control-C hit
[FORMS.PP] ExceptionOccurred
Sender=EAccessViolation
Exception=Access violation
Stack trace:
$000000007747825D
TApplication.HandleException Access violation
Stack trace:
$000000007747825D
[FORMS.PP] ExceptionOccurred
Sender=EAccessViolation
Exception=Access violation
Stack trace:
$0000000000000000
$0000000100A38C10
$0000000100A3A7A1
$0000000100A3BA29
$0000000100A3C3E2
$0000000100A3C49E
$0000000100A3C12A
$0000000100A399FD
$0000000100A3B424
$0000000100A38342
$000000010001066F
$0000000100013E85
$00000001000142B8
TApplication.HandleException Access violation
Stack trace:
$0000000000000000
$0000000100A38C10
$0000000100A3A7A1
$0000000100A3BA29
$0000000100A3C3E2
$0000000100A3C49E
$0000000100A3C12A
$0000000100A399FD
$0000000100A3B424
$0000000100A38342
$000000010001066F
$0000000100013E85
$00000001000142B8

Well I'll be blowed, changing the printer actually fixed my problem. Thanks CBA

It is possible that some BIG IDE package uses a printer, and during it's initialization it does not check if default printer does not exist or does not have needed capabilities, but when error should be shown that exception is probably handled by a package.

I have found this the hard way. Many years ago I made a Delphi application which had some strange initialization error message that I could not reproduce on my pc. It turned out that on a Windows machine without printer, or with just an image printer installed by MS Office, that error was shown on application initialization. After checking for a printer existance on initialization and proper handling, the problem has gone for good.