Re: [fpc-devel] LocalReferenceFixup
On Tuesday 05 October 2010 00:37:44 José Mejuto wrote: > Hello FPC, > > I find a problem that I'm unable to resolve, with my limited skills. > In TReader when a property is a TClass it is being added to be > resolved after all components are loaded, but the "Loaded" call is > performed before this fixup, so when a component receive the "Loaded" > signal some fields are still not completly filled in. > > This is terrible in the SQLQuery (from Lazarus) as if you left anyone > "Active" it always complaint in runtime with "Database not set". :( Use " procedure BeginGlobalLoading; procedure NotifyGlobalLoading; procedure EndGlobalLoading; " MSEgui has " procedure msebegingloballoading; //recursive procedure mseendgloballoading; //calls notifygloballoading in level 0 " in order to simplify the task. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dynamic Arrays as Static class variables
On Tuesday 05 October 2010 01:00:19 Willibald Krenn wrote: > Hi, > > I just tried and can reproduce this with fpc rev. 16078 on win64. Same thing here on Linux , AMD64, few days old FPC trunk version. Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
Mark Morgan Lloyd wrote:
I can confirm that I can build FPC 2.4.0 to run under Debian "Lenny" on
an ARM-based system (Cisco/Linksys NSLU2 "Slug") using
make 'NOGDB=1' 'OPT=-dFPC_ARMEL -CfSOFT' all
This appears to be OK to the extent that it can compile Lazarus
0.9.28.3, although my initial attempt ("make all") bombed but for some
reason "make 'OPT=-vt' all" was OK.
If starting with a binary of 2.2.2 it's necessary first to generate
2.4.0 using 'OPT=-CfSOFT'. Obviously the amount of memory limits
compilation and in particular linkage speed. I've not tried later
versions yet.
When running 2.4.0 on an ARM system (Debian v5 "Lenny", armel) with
limited memory (32Mb RAM + 768Mb swap) and using it to compile a large
project (Lazarus 0.9.28.2) I'm seeing intermittent failures which go
away if the make is restarted. I've not seen this running on other
platforms, and I don't believe it is a problem in the Lazarus sources
since the build will eventually complete giving me runnable code.
The output typically looks something like this, although I don't think
it always fails at the same point:
$ make all
make -C lcl all
make[1]: Entering directory `/usr/local/share/lazarus-stable/lcl'
/bin/rm -f units/arm-linux/alllclunits.ppu
/bin/mkdir -p units/arm-linux
/usr/local/bin/ppcarm -gl -Fu. -Funonwin32 -Fuforms -Fuwidgetset
-Fu/usr/local/lib/fpc/2.4.0/units/arm-linux/rtl -Fiinclude -FE.
-FUunits/arm-linux -darm alllclunits.pp
Free Pascal Compiler version 2.4.0 [2010/08/21] for arm
Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux for ARMEL
Compiling alllclunits.pp
Compiling lclversion.pas
Assembling lclversion
..
Assembling postscriptprinter
Compiling postscriptcanvas.pas
Compiling postscriptunicode.pas
Fatal: Compilation aborted
An unhandled exception occurred at $00033B60 :
EInOutError : File not found
$00033B60
$000F6A30
$0011A744
$000FA588
$000F4F20
$00140A14
$0011FF78
$0013648C
$0013FDA0
$00140950
$0011FF78
$0013648C
$0013FDA0
$00140950
$0011FF78
$00024370
$8304
make[1]: *** [alllclunits.ppu] Error 217
make[1]: Leaving directory `/usr/local/share/lazarus-stable/lcl'
make: *** [lcl] Error 2
This is not immediately reproducible, so I can't simply rerun the
compiler using gdb to get a backtrace. Is there an easy way to make
sense of those numbers?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
On 05 Oct 2010, at 10:05, Mark Morgan Lloyd wrote: When running 2.4.0 on an ARM system (Debian v5 "Lenny", armel) with limited memory (32Mb RAM + 768Mb swap) and using it to compile a large project (Lazarus 0.9.28.2) I'm seeing intermittent failures which go away if the make is restarted. I've not seen this running on other platforms, and I don't believe it is a problem in the Lazarus sources since the build will eventually complete giving me runnable code. A couple of days ago I fixed an error in svn trunk for ARMEL that caused the stack to become temporarily unbalanced after performing syscalls with 5 or more parameters (the bug is still there for OABI, but I can't fix that because I don't have access to an OABI machine). A side-effect of that bug was that if the caller passed the address of its own result as one of the parameters to the system call, it would afterwards return a random value as its result and checks for error results caused random failures like the one you posted (the reproducible case that allowed me to fix it was a similar error). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
Jonas Maebe wrote: On 05 Oct 2010, at 10:05, Mark Morgan Lloyd wrote: When running 2.4.0 on an ARM system (Debian v5 "Lenny", armel) with limited memory (32Mb RAM + 768Mb swap) and using it to compile a large project (Lazarus 0.9.28.2) I'm seeing intermittent failures which go away if the make is restarted. I've not seen this running on other platforms, and I don't believe it is a problem in the Lazarus sources since the build will eventually complete giving me runnable code. A couple of days ago I fixed an error in svn trunk for ARMEL that caused the stack to become temporarily unbalanced after performing syscalls with 5 or more parameters (the bug is still there for OABI, but I can't fix that because I don't have access to an OABI machine). I don't at the moment have any spare ARM systems that I could set up and expose for testing. I've got some development boards (effectively, ARM-based PCs) but they came with CE and I'm not paying the manufacturer $500 for Linux... A side-effect of that bug was that if the caller passed the address of its own result as one of the parameters to the system call, it would afterwards return a random value as its result and checks for error results caused random failures like the one you posted (the reproducible case that allowed me to fix it was a similar error). That sounds promising and I'll try it in a few days (once I've got the trial Lazarus compilations out of the way). What should I be doing- updating to trunk? The overall exercise is extending the native testing I did of FPC on various platforms to Lazarus. Granted that not many people are likely to want to run it natively on an ARM target but I think it's still worth knowing whether it can be done. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
On 05 Oct 2010, at 10:50, Mark Morgan Lloyd wrote: Jonas Maebe wrote: On 05 Oct 2010, at 10:05, Mark Morgan Lloyd wrote: When running 2.4.0 on an ARM system (Debian v5 "Lenny", armel) with limited memory (32Mb RAM + 768Mb swap) and using it to compile a large project (Lazarus 0.9.28.2) I'm seeing intermittent failures which go away if the make is restarted. I've not seen this running on other platforms, and I don't believe it is a problem in the Lazarus sources since the build will eventually complete giving me runnable code. A couple of days ago I fixed an error in svn trunk for ARMEL that caused the stack to become temporarily unbalanced after performing syscalls with 5 or more parameters (the bug is still there for OABI, but I can't fix that because I don't have access to an OABI machine). I don't at the moment have any spare ARM systems that I could set up and expose for testing. I've got some development boards (effectively, ARM-based PCs) but they came with CE and I'm not paying the manufacturer $500 for Linux... I've requested an account on the GCC compile farm (http://gcc.gnu.org/wiki/CompileFarm , anyone contributing to any free software project can do so), and I guess that at least one of their ARM machines will also support OABI binaries. A side-effect of that bug was that if the caller passed the address of its own result as one of the parameters to the system call, it would afterwards return a random value as its result and checks for error results caused random failures like the one you posted (the reproducible case that allowed me to fix it was a similar error). That sounds promising and I'll try it in a few days (once I've got the trial Lazarus compilations out of the way). What should I be doing- updating to trunk? Maybe the easiest is to simply download http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/linux/arm/syscall.inc?revision=16073&pathrev=16073 and replace the rtl/linux/arm/syscall.inc file in the 2.4.0 source tree with that file. There are no FPC version-specific changes to that code. The overall exercise is extending the native testing I did of FPC on various platforms to Lazarus. Granted that not many people are likely to want to run it natively on an ARM target but I think it's still worth knowing whether it can be done. Sure! Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
Jonas Maebe wrote: I've requested an account on the GCC compile farm (http://gcc.gnu.org/wiki/CompileFarm, anyone contributing to any free software project can do so), and I guess that at least one of their ARM machines will also support OABI binaries. If you don't get anywhere I might be able to help, although I'm not going to pretend that it would be convenient since I'd have to re-flash a Slug which would mean that I could no longer use it as an emergency fallback system. Things would be far easier if there were still such things as ARM-based workstations, i.e. booting from an external device (USB or whatever) rather than internal Flash. The boards I've got are made by iEi, but you get either CE or Linux- not both. I'm hoping to be able to hack OpenFirmware onto a CompactFlash card which would give it much the same interface as Suns and PPC-based Macs. Maybe the easiest is to simply download http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/linux/arm/syscall.inc?revision=16073&pathrev=16073 and replace the rtl/linux/arm/syscall.inc file in the 2.4.0 source tree with that file. There are no FPC version-specific changes to that code. Noted, I'll report back presently. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
Am 05.10.2010 10:13, schrieb Jonas Maebe: > > On 05 Oct 2010, at 10:05, Mark Morgan Lloyd wrote: > >> When running 2.4.0 on an ARM system (Debian v5 "Lenny", armel) with >> limited memory (32Mb RAM + 768Mb swap) and using it to compile a large >> project (Lazarus 0.9.28.2) I'm seeing intermittent failures which go >> away if the make is restarted. I've not seen this running on other >> platforms, and I don't believe it is a problem in the Lazarus sources >> since the build will eventually complete giving me runnable code. > > A couple of days ago I fixed an error in svn trunk for ARMEL that caused > the stack to become temporarily unbalanced after performing syscalls > with 5 or more parameters (the bug is still there for OABI, but I can't > fix that because I don't have access to an OABI machine). > My arm box is oabi. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dynamic Arrays as Static class variables
Hi! Am Dienstag, den 05.10.2010, 10:50 +0300 schrieb Juha Manninen (gmail): > On Tuesday 05 October 2010 01:00:19 Willibald Krenn wrote: > > Hi, > > > > I just tried and can reproduce this with fpc rev. 16078 on win64. > > Same thing here on Linux , AMD64, few days old FPC trunk version. Thank you for trying and confirming. Should I submit a bug report? Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dynamic Arrays as Static class variables
On 05 Oct 2010, at 11:38, Johann Glaser wrote: Thank you for trying and confirming. Should I submit a bug report? Somebody else already did: http://bugs.freepascal.org/view.php?id=17546 Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] LocalReferenceFixup
Hello Martin, Tuesday, October 5, 2010, 9:56:41 AM, you wrote: >> I find a problem that I'm unable to resolve, with my limited skills. >> In TReader when a property is a TClass it is being added to be >> resolved after all components are loaded, but the "Loaded" call is >> performed before this fixup, so when a component receive the "Loaded" >> signal some fields are still not completly filled in. MS> Use MS> " MS> procedure BeginGlobalLoading; MS> procedure NotifyGlobalLoading; MS> procedure EndGlobalLoading; MS> " I see, but there is still a problem, I think. Let me explain: 1) Component is being read, it reads Active property, if set and csLoading then the "active" is postponed to "afterload". 2) The "Database" property is being read, but as it is a TClass it is added to LocalFixups. 3) The remaining properties are beign read. 4) Component is notified with "Loaded" signal, so it tries to active itself, but database is not set. 5) Fixups are performed. 6) Component is notified again with "Loaded" signal. I do not know how to instruct the component to skip the first "Loaded" signal and wait for the next one, specially because if "Database" is not set (trully error) the second "Loaded" signal will not be fired. Maybe a component state like "csFixupsPending" ? I do not have too much experience with components, but calling "Loaded" several times does not look very fine. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] LocalReferenceFixup
On Tue, 5 Oct 2010, José Mejuto wrote: Hello Martin, Tuesday, October 5, 2010, 9:56:41 AM, you wrote: I find a problem that I'm unable to resolve, with my limited skills. In TReader when a property is a TClass it is being added to be resolved after all components are loaded, but the "Loaded" call is performed before this fixup, so when a component receive the "Loaded" signal some fields are still not completly filled in. MS> Use MS> " MS> procedure BeginGlobalLoading; MS> procedure NotifyGlobalLoading; MS> procedure EndGlobalLoading; MS> " I see, but there is still a problem, I think. Let me explain: 1) Component is being read, it reads Active property, if set and csLoading then the "active" is postponed to "afterload". 2) The "Database" property is being read, but as it is a TClass it is added to LocalFixups. 3) The remaining properties are beign read. 4) Component is notified with "Loaded" signal, so it tries to active itself, but database is not set. 5) Fixups are performed. 6) Component is notified again with "Loaded" signal. I do not know how to instruct the component to skip the first "Loaded" signal and wait for the next one, specially because if "Database" is not set (trully error) the second "Loaded" signal will not be fired. Maybe a component state like "csFixupsPending" ? I do not have too much experience with components, but calling "Loaded" several times does not look very fine. To the best of my knowledge: it should be called once only, after the fixups. If it isn't so, this is a bug. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[3]: [fpc-devel] LocalReferenceFixup
Hello FPC,
Tuesday, October 5, 2010, 1:10:43 PM, you wrote:
>> I do not have too much experience with components, but calling
>> "Loaded" several times does not look very fine.
MVC> To the best of my knowledge: it should be called once only, after the
fixups.
MVC> If it isn't so, this is a bug.
Extracted from "reader.inc", comments below...
--
[...]
procedure TReader.FixupReferences;
var
i: Integer;
begin
DoFixupReferences;
GlobalFixupReferences;
for i := 0 to FLoaded.Count - 1 do
TComponent(FLoaded[I]).Loaded;
end;
[...]
function TReader.ReadRootComponent(ARoot: TComponent): TComponent;
[...]
if Assigned(GlobalLoaded) then
FLoaded := GlobalLoaded
else
FLoaded := TFpList.Create;
try
if FLoaded.IndexOf(FRoot) < 0 then
FLoaded.Add(FRoot);
FOwner := FRoot;
FRoot.FComponentState := FRoot.FComponentState + [csLoading, csReading];
FRoot.ReadState(Self);
Exclude(FRoot.FComponentState, csReading);
if not Assigned(GlobalLoaded) then begin
for i := 0 to FLoaded.Count - 1 do
TComponent(FLoaded[i]).Loaded;//
end;
finally
if not Assigned(GlobalLoaded) then
FLoaded.Free;
FLoaded := nil;
end;
GlobalFixupReferences;
[...]
end;
procedure TReader.ReadData(Instance: TComponent);
[...]
{ Fixup references if necessary (normally only if this is the root) }
If (Instance=FRoot) then
DoFixupReferences;
end;
[...]
--
As you can see the "Loaded" event is called (marked with some //-)
before calling "GlobalFixupReferences", I'll try to add some writeln's
here and there to catch the event sequence and post it here for
further comments.
--
Best regards,
José
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[3]: [fpc-devel] LocalReferenceFixup
On Tue, 5 Oct 2010, José Mejuto wrote: Hello FPC, Tuesday, October 5, 2010, 1:10:43 PM, you wrote: I do not have too much experience with components, but calling "Loaded" several times does not look very fine. MVC> To the best of my knowledge: it should be called once only, after the fixups. MVC> If it isn't so, this is a bug. Extracted from "reader.inc", comments below... -- [...] -- As you can see the "Loaded" event is called (marked with some //-) before calling "GlobalFixupReferences", I'll try to add some writeln's here and there to catch the event sequence and post it here for further comments. That would be good, thank you. If we can pinpoint the issue, the solution will probably be easy and straightforward. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LocalReferenceFixup
On Tuesday 05 October 2010 13:55:53 José Mejuto wrote: > > if not Assigned(GlobalLoaded) then begin <-- > for i := 0 to FLoaded.Count - 1 do > TComponent(FLoaded[i]).Loaded;// > end; > > finally > if not Assigned(GlobalLoaded) then > FLoaded.Free; > FLoaded := nil; > end; > GlobalFixupReferences; > [...] > -- > > As you can see the "Loaded" event is called (marked with some //-) > before calling "GlobalFixupReferences", Not if GlobalLoaded is set. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] LocalReferenceFixup
Hello FPC,
Tuesday, October 5, 2010, 4:08:08 PM, you wrote:
>> As you can see the "Loaded" event is called (marked with some //-)
>> before calling "GlobalFixupReferences",
MS> Not if GlobalLoaded is set.
Yes, but it is not set, because BeginGlobalLoading is not called at
all from any point in the code, nor in fpc/rtl nor in Lazarus lcl, nor
in Lazarus IDE, but the IDE is not the important thing as the main
problem is at runtime. Only LNet httpsvlt is calling the
"BeginGlobalLoading" unless some other call it using some kind of
opaque pointer :-?
-
F:\Lazarus>find "begingloballoading" *.pas;*.pp;*.inc /s
0 lines in 0 files
F:\Lazarus>\fpc\svn\
F:\fpc\svn>find "begingloballoading" *.pas;*.pp;*.inc /s
F:\fpc\svn\packages\fcl-net\src\httpsvlt.pp
BeginGlobalLoading;
F:\fpc\svn\rtl\objpas\classes\classes.inc
procedure BeginGlobalLoading;
{ Free the memory occupied by BeginGlobalLoading }
F:\fpc\svn\rtl\objpas\classes\classesh.inc
procedure BeginGlobalLoading;
4 lines in 3 files
-
Is each component which must call "BeginGlobalLoading" ? or is the
read logic which must decide when activate the globalloading ?
--
Best regards,
José
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] __caddr_t type in packages/libc/src/typesh.inc
Hi It looks like the __caddr_t type in packages/libc/src/typesh.inc is declared incorrectly. In C, it is declared as "typedef char *__caddr_t;", but in FPC, it is declared as char, not PChar. This is most obvious when using the ifc_ifcu.ifcu_buf field of the ifconf structure in nifh.inc. Am I reading it wrong? Can someone confirm this is a bug? Regards Hilton Williams -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Pre-zeroing in MM by background thread/process
I did a global search on trunk\compiler and found the following numbers: GetMem(): 212 hits FillChar(): 362 hits I haven't checked any other fpc folder, but I am sure those figures would multiply. What I did notice was that GetMem() and FillChar() were being used in pairs most of the time --as opposed to using AllocMem() which had 16 hits. My focus isn't on the merits of using AllocMem() instead of GetMem() and FillChar() pair; what I do notice is the fact that in a lot of places there is a strong need for zeroed memory. That brings me to the idea of handling the zeroing of memory chunks by the memory manager (MM) instead of doing it in-line. But, before getting grilled to death here, I floated this idea in forums.codegear. Here it is: nntp://forums.codegear.com/embarcadero.public.delphi.language.basm/848 [Quite a bit of the following text is taken from Thorsten Engler's replies to my and other's questions on the topic. For more detail please read the above NNTP thread] The basic idea is this: In the memory manager a background (idle priority) thread/process does the zeroing --preferably using another core. The idea isn't entirely new; Windows has been doing just that for over a decade (since Win98 and NT3.1). It is pre-zeroing pages in a background thread and making them available to applications through VirtualAlloc() calls. In Windows, an idle priority background thread takes pages from the 'Free' list, zeroes them, and puts them into the 'Zeroed' list. That way, when a new physical page is required, it can directly be taken from the 'Zeroed' list. Only if a new page is required and the 'Zeroed' list is empty is a page directly taken from the 'Free' list and zeroed JIT. 'Free' page count (which are pages that have been returned to the page pool, but which still contain whatever it is they contained before being freed) are always pretty close to 0, while the 'Zeroed' page count is usually much higher (except if the system is running out of physical memory). This does not seem to have noticeable impact on Windows or else MS would have --I think-- given up on that long ago. Now, back to the MM in FPC: Obviously, zeroing is a waste of time for any allocation where it is not required. But all allocations for classes DO require it. And besides strings and dynamic arrays, classes a pretty much the major part of all allocations. So, it seems, if we had something like what Windows has, we could get rid of all those GetMem() and FillChar() pairs and replace them with AllocMem() [and ReAllocZeroMem()] that retrieves pre-zeroed memory from the MM and increase the overall performance. The worst case scenario would be this: MM doesn't have any 'Zeroed' memory. In which case, AllocMem() falls back to GetMem() and FillChar() pair. Under Windows, MM could get intial zeroed memory through VirtualAlloc() to begin with and then zero only the returned memory. I did try to lookup an equivalent to VirtualAlloc() and it seems calloc() is it --but I am not sure if it is, or whether it is available in all platforms. Anyway, this is the idea. I wonder what you think. --- More hit data: fpc/trunk/packages/ GetMem(): 1464 hits FillChar(): 608 hits trunk/lazarus/ GetMem(): 522 hits FillChar(): 1366 hits -- Cheers, Adem ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LocalReferenceFixup
On Tuesday, 5. October 2010 17.24:09 José Mejuto wrote: > Hello FPC, > > Tuesday, October 5, 2010, 4:08:08 PM, you wrote: > >> As you can see the "Loaded" event is called (marked with some //-) > >> before calling "GlobalFixupReferences", > > MS> Not if GlobalLoaded is set. > > Yes, but it is not set, because BeginGlobalLoading is not called at > all from any point in the code, nor in fpc/rtl nor in Lazarus lcl, nor > in Lazarus IDE, but the IDE is not the important thing as the main > problem is at runtime. Only LNet httpsvlt is calling the > "BeginGlobalLoading" unless some other call it using some kind of > opaque pointer :-? > Avoid circular component references in the forms and adjust the creation order that the referencing forms are created later or use MSEgui: " msebegingloballoading; [...] create the forms mseendgloballoading; " Lazarus: " begingloballoading; [...] create the forms notifygloballoading; endgloballoading; " (not tested). Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
