Re: [fpc-pascal] Generics - how to rewrite TOjectDictionary
Hi, Ever tried TStringList with Strings[] and Objects[] properties? kind regards, Dimitri Smits - Oorspronkelijk e-mail - Van: Marius mar...@lmspathologie.nl Aan: fpc-pascal@lists.freepascal.org Verzonden: Zondag 7 april 2013 18:48:02 Onderwerp: [fpc-pascal] Generics - how to rewrite TOjectDictionary Hello, It was many years ago i tried fpc/lazarus so i'm not up to speed with eveything. At this moment I'm trying to rewrite a piece of software from delphi to fpc/laz and i'm having trouble rewriting generics and in special the TObjectDictionary. Below shows how it is implemented in delphi. Is there a native fpc solution for this and if there is not what are the alternatives to rewrite this? Or would it even be better to avoid generics in general? TMyDic = TObjectDictionary string, TMyObject; I would welcome any tips to solve this Thanks, Marius I'm using fpc 2.7.1, laz 1.1(svn 4/7/13) -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Generics-how-to-rewrite-TOjectDictionary-tp5714029.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
- Oorspronkelijk e-mail - Van: Florian Klämpfl flor...@freepascal.org Aan: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Verzonden: Maandag 4 maart 2013 21:00:10 And how does this change the fact that it is an external cg not written in pascal? the front-end would still be written in pascal. as a matter of fact, when you use the binutils and ld etc, you aren't exactly using a full pascal toolchain either, no? kind regards, Dimitri Smits ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
- Oorspronkelijk e-mail - Van: Florian Klämpfl flor...@freepascal.org Aan: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Verzonden: Vrijdag 1 maart 2013 18:13:42 Onderwerp: Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ? Am 01.03.2013 11:04, schrieb Sven Barth: But even if LLVM would support all targets that FPC supports the core developers don't *want* to make LLVM the default. Actually, I wouldn't have any interest working on a compiler using llvm as a backend because it leaves only the boring front end work :) Not to mention the maintainance problems when depending on an external cg written not in pascal, the probably significant speed drop etc. as a matter of fact, the llvm-stack is not just your front-end to provide the intermediate bytecode (or textual variant)! You can provide/maintain multiple plugins for almost every pass. Going from optimisation passes to the entire executable generation as back-end. Admittedly you need to make a C(++?) compatible interface, but I think nobody stops you from making those passes/plugins in FPC... on the other hand... the speed difference with Delphi XE 3.5 or later would level out a bit more :-) that being said, Embarcadero will surely implement such proprietary passes/plugins and additions for their own benefit. At least I am very curious to next fall when the next version(s) come out. Not in the least if they also support Android with a cross-platform library/interface between iOS and Android for common features, like they 'promised' last fall on a conference. (BE-Delphi last november) full disclosure: yes, paying owner of a licence DXE3 kind regards, Dimitri Smits ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] converting c code
- Oorspronkelijk e-mail -
On Sun, 13 May 2012 15:09:15 +0200
Darius Blaszyk dhkblas...@zeelandnet.nl wrote:
I'm struggling to convert a simple for loop from C to pascal. The
code is shown below (as is a trace of the loop parameter values).
I'm a bit puzzled how this should look elegantly in pascal. Anyone
has an idea?
IMHO the C code is short, but not elegant. It would be more elegant
if
the j=i is at the end.
unsigned nc = 4;
for (unsigned i = 0, j = nc-1; i nc; j=i++)
{
cout i: i endl;
cout j: j endl;
}
Maybe:
var i,j: integer;
begin
j:=nc-1;
for i:=0 to nc-1 do begin
writeln('i:',i);
writeln('j:',j);
j:=i;
end;
actualy, Marco's version is more correct. A C(++) for loop does it's evaluation
on the fly, whereas in pascal (or some dialects), the for variable(s) are
immutable or evaluated as early as possible. In this case it might work, but in
general, a C++ for loop is better written as a pascal's while ... do of
repeat ... until construct because of this.
consider a loop where you want to exit out of when a condition is met. In C(++)
you can change the values of the for loop's variables on the fly et voila, on
next iteration you return.
at least, that was what we were told in our CS courses, comparing C(++) vs
Pascal/Modula/Oberon (almost 2 decades ago).
kind regards,
Dimitri Smits
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is Random(255) some 529x slower compared to Delphi 7?
- Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com schreef: On Fri, Dec 9, 2011 at 9:39 AM, Graeme Geldenhuys graemeg.li...@gmail.com wrote: I didn't write this encryption code, I merely debugged why the unit tests for this unit took so long to complete, compared to under Delphi. It is specifically written in the Delphi documentation that Random should not be utilized for encryption... true, (but) looking at the code again, it seems that you always have a predictable sequence when using the same algorithm. Not sure if that is a good thing or a bad one in cryptology :-). After all, when you do not randomize() first, randseed has a default startupvalue (and otherwise it is typically seeded with a timestamp of somesorts). I don't remember where I read it (ages ago), and the comment in Delphi seems to negate that this is the used algorithm, but this 'predictable sequence from the same seed'-property is especially true when using a LCG pseudo-random-number-generator. Just to be sure, the wikipedia article DOES mention that Delphi (and every other HL language that matters :-)) supplies a Random functionality that is based on a LCG. http://en.wikipedia.org/wiki/Linear_congruential_generator And in the java realm there are numerous other algorithms available, but the default implementation with the language libraries is a LCG, as does the C(++). Reading the article again, I find a few paragraphs corresponding to the Delphi help. Excerpt from the 'advantages and disadvantages' part of the page: -- LCGs should not be used for applications where high-quality randomness is critical. For example, it is not suitable for a Monte Carlo simulation because of the serial correlation (among other things). They should also not be used for cryptographic applications; see cryptographically secure pseudo-random number generator for more suitable generators. If a linear congruential generator is seeded with a character and then iterated once, the result is a simple classical cipher called an affine cipher; this cipher is easily broken by standard frequency analysis. -- kind regards, Dimitri Smits ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is Random(255) some 529x slower compared to Delphi 7?
- Graeme Geldenhuys graemeg.li...@gmail.com schreef: On 9 December 2011 10:42, Felipe Monteiro de Carvalho wrote: It is specifically written in the Delphi documentation that Random should not be utilized for encryption... Delphi documentation mentions a lot of things you mustn't do... Does that stop anybody. ;-) only those that take their jobs seriously and read help/manuals iso assuming? :-) Like I said, I didn't write that code, and I don't specialise in encryption algorithms. But Florian might be right, the RandSeed assignment might have been added due to the bad random generator of Delphi - hopefully the original author of the code can shed some light. I actually doubt that that codesnippet does any real encryption. From what I understand from it (with the provided code and assuming types), the source-message is bitstreamed. In the resulting message, the LSB of every octet/byte/8-bitvalue is the one you need to focus on, the rest is random data. Also, as a result, the result-message is 8 times as large. And that LSB is also easily decrypted = parse the LSB from every byte in your data and reconstruct using OR the (index mod 8)-th bit on the (index div 8) octet. hardly encrypted ;-) kind regards, Dimitri Smits ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Why is Random(255) some 529x slower compared to Delphi 7?
- Virgo Pärna virgo.pa...@mail.ee schreef: On Fri, 09 Dec 2011 09:19:53 +0100, Florian Klaempfl flor...@freepascal.org wrote: Oops, mails crossed. The assignment to randseed is indeed the problem. Why is it done? Bad random generator of delphi :)? I don't know, how bad Delphis random generator is, but I once years ago did make a mistake of calling randomize before random. It was a school assignment for using Turbo Pascal graphics. So I made program, that was supposed to fill screen with random dots (colour was also set with random). Anyway, when I called randomize before random, then as a result dots didn't fill the screen, but were mostly along the diagonal of the screen. So I'd guess, that setting randseed multiple times could be actually bad for randomness of results. Or maybe modern algorithms are better at situations like this? Randomize() is supposed to be called only once to seed the generator with an initial value. If you made it something like so: begin for i := 0 to 1000 do begin randomize(); pixel[random(screenwidth),random(screenheight)]:= clSomeColor; end; end; then you seed with a timestamp before randoming and your distribution does not change much with a lcg. Not the fault of the algorithm itself, just your mistake of doing the randomize in the loop itself (like you mentioned yourself). kind regards, Dimitri Smits ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is Random(255) some 529x slower compared to Delphi 7?
- Jürgen Hestermann juergen.hesterm...@gmx.de schreef: But now we have a fast random() function in Delphi and a statistical good one in FPC but none of them has both. just my 2cts, but... The Delphi 7 help states about function System.Random [ ( Range: Integer) ]; the following -- In Delphi code, Random returns a random number within the range 0 = X Range. If Range is not specified, the result is a real-type random number within the range 0 = X 1. To initialize the random number generator, add a single call Randomize or assign a value to the RandSeed variable before making any calls to Random. Note: Because the implementation of the Random function may change between compiler versions, we do not recommend using Random for encryption or other purposes that require reproducible sequences of pseudo-random numbers. -- I would argue that: - using Random for encryption always was a bad idea - you have largely incompatible implementations and expectations when you want to make code fpc+delphi7 compilable As for other Random functions, Delphi7 also has Math.RandG (gaussian distribution around a mean) and Math.RandomRange. I would suggest the Math.RandomMT and a simpler, faster random method + good documenting. The above Delphi-help snippet also discourages explicitly the use for encryption and other purposes. A See also could be used to get some statistically better distributed random numbers. OR, what was suggested with the pluggable Random number generatorcall like the memorymanagers. like I said, just my 2cts... kind regards, Dimitri Smits ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Class reference doubt
- Luiz Americo Pereira Camara luiz...@oi.com.br schreef: On 24/11/2011 19:34, Jonas Maebe wrote: In that case, you did not hit the same problem as the original poster (your I also hit this problem recently is what triggered my response). His problem was that if you call a non-virtual constructor on a class reference variable, that the constructor is determined based on the static type of the class reference rather than on the dynamic type. It does not matter much but i hit the same problem. Just replace class of TObj by class of TObject (TClass) I stored a class (TMyClass) in a class variable (AClass: TClass). I was expecting that calling AClass.Create would call TMyClass.Create. Just like him i found that is not the case. To be clear: i'm not saying that is a bug or asking for changing the behavior so you have: type TMyObject=class(TObject) ... constructor Create; end; TMyClass = class of TMyObject; // -- important I guess ... procedure processSomething(AClass: TClass); var someInstance: TObject; begin someInstance := AClass.Create(); // -- always the one from TClass/TObject? end; ... begin processSomething(TMyObject); end; class methods (and the constructors and destructor) are in Delphi part of the TClass memorystructure. I believe even the TObject default Create. For your trick to work, you need one of 2 things: - declare the class-reference for a type explicitly (class of T...) - make a virtual constructor in a subtype of TObject and declare a class-reference. Then you derive from that subtype. I don't think (did not test) it finds a TMyClass in Delphi as well if you do not declare the type, so in effect it always takes TClass. The other scenario's I've used before in classfactory pattern before. It has nothing and everything to do with RTTI. No, the new D2010+ RTTI does not give access to the default constructor (I think), but it IS part of the TClass-alike-structure that is generated for the TObject descendant. kind regards, Dimitri Smits ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linux - ExecuteProcess versus fpSystem
- brian br...@meadows.pair.com schreef: This is reproducible on a whole batch of files, and yes, I've checked all the file permissions. It's got to be something obvious, or some quirk of Linux programming that I haven't met up with yet (I'm still a novice with FreePascal and Linux, though I've many years experience with Delphi and Windows). What am I missing? from what I understand, you are trying to run 2 commands? one question that I ask myself then is: why does your driving program have to be a fpc program? What is wrong with a shell script? while you may have valid reasons for doing so, have you tried to put that flow (calling of the 2 commands) into a single shell script and executing that instead? kind regards, Dimitri Smits ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Library for network calculation
don't have a Delphi in reach for the moment to verify, but you could do that to a const (if you enable the assignable constants setting) procedure SomeProc; const someconst: Integer = 22; begin //blabla someconst := 42; //yadda yadda end; - Sven Barth pascaldra...@googlemail.com schreef: Well... seems like you didn't notice this feature yet :D I'm talking about this: === source begin === procedure SomeProc; var somevar: Integer = 42; begin end; === source end === This works in FPC, but doesn't in Delphi ;) Regards Sven Am 26.07.2011 21:27, schrieb Jorge Aldo G. de F. Junior: I dont like to take local variable initialization for granted. Even if the manual says that its guaranteed that a local variable will start with 0, i prefer to initialize everything to a known value myself. An aditional Move $varaddress, 00 at startup wont slow things down noticeably when your pc is running at 2ghz... This unit needs to take care of big endian vs. low endian (maybe a $define ?) When i wrote that code i did not pay attention to this... Anything more complex (like interacting with DHCP server) would be too complex and probably dependent on external units (like synapse x lnet etc). Some people might prefer to use other library instead of the default choosen one, etc... 2011/7/26 Sven Barthpascaldra...@googlemail.com: On 26.07.2011 01:23, Paul Nicholls wrote: Jorge Aldo G. de F. Junior jagf...@gmail.comwrote in message news:CAAHHabS9aUe9gwyNjkve-XVXsRyf2UPsArh6=fsdpgokugj...@mail.gmail.com... Some time ago someone asked for a library able to do network calculations. Here is something that might evolve into such library : SNIP Function NetMaskToHostMask(NetMask : TNetworkIP): TNetworkIP; Begin Result.Mode := False; NetMask.Mode := False; Result.IP := NetMask.IP Xor %; End; SNIP I didn't know that freepascal handled binary formatted numbers?!? % There are often new things one can learn about what FPC supports ;) (though binary numbers are already old for me ^^) The most recent finding (at least for me) was the abbility to initialize local variables. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] The new Delphi 2010 RTTI
- michael vancanneyt michael.vancann...@wisa.be schreef: My solution, in short, is that packages should have OS independent interface to RTL built into executable visible to packages as RTL built as c package (with is a bridge to real RTL). I understood that. Assuming you can make this interface (which I don't believe), your solution is still not realistic: And how will you make a package that uses a os-specific function OS independent ? (for instance, a package with a control that uses a WinAPI call.) So a package with the LCL is by definition impossible. Like I said, your proposal requires that we emulate all OSes on all other OSes. I think he means a hybrid of the old 'overlay' loadable code. and I also think he means something like: - if you want to have a package for a 386 cpu, then you only have to compile it once - you can link in your code regardless of os, as long as it is a 386 cpu with the same code ofcourse I cannot agree more on the 'use what the os gives you'. ???.dll/lib???.so what I don't understand is the remark on windows dll is a pe executable and linux .so's are how packages are supposed to be. Anybody can clarify that statement? kind regards, Dimitri Smits ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] The new Delphi 2010 RTTI
Hi, what is so different on this mail than the one I sent a few months ago to the fpc-devel list? anyway, it would require some packages (bpl) language/RTE additions as well. That was where I was hanging when spare time slipped away a few months back. I started on rtti unit with help in embarcadero's online wiki. Btw, during those few weeks, I noticed the XE updates. In theory it is possible to do some AOP in Delphi XE now with TVirtualMethodInterceptor or something like that. the unit wasn't all that useful yet (mostly interface) and probably partially obsolete due to the XE upgrade :-). kind regards, Dimitri Smits - Thierry Coq t...@free.fr schreef: Hello, Delphi 2010 has changed the RTTI mechanism, and it is said to be much more usable than the previous one. (see here for example: http://www.malcolmgroves.com/blog/?p=476) Some interesting tools are using this new approach, like DelphiOnRails: http://code.google.com/p/delphionrails/ Currently, the FPC doesn't implement this new mechanism (See Jonas' answer to my previous post, badly sent :-( ). But it might be possible to add this mechanism, by making patches to FPC. Would it interest somebody to have this new functionality? Best regards, Thierry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] The new Delphi 2010 RTTI
Sure, but I was talking about the RTTI unit and API compatibility.
(hierarchical starting point is program, then package, then unit, then type)
more pressing would be:
- list of units in program (only once, hence the packages or monolythic
executable)
- list of types/vars/methods in that unit
a TClass should be able to get its unitname as well.
Your remark on the package support is invalid. The other way around IS valid as
well, since the api of the rtti unit has some dependencies. If Packages are
ever implemented, then the api must be corrected. Likewise, some parts of the
api are made from their point of view (embarcadero's), where an executable is a
package, as well as every bpl, and each add their unit-info's to the RTE on
load of that package. From there a logical hierarchy is possible, which shows
a bit in the rtti unit api. It all depends on the direction of the relationship
(tclass.unitname, tunitinfo.packagename, but also
rtticontext.findtype('unit.type')) which makes the implementation a breeze or a
bit harder.
from http://docwiki.embarcadero.com/VCL/en/RTTI.TRttiContext
TRttiContext = record
public
class function Create: TRttiContext; static;
procedure Free;
function GetType(ATypeInfo: Pointer): TRttiType; overload;
function GetType(AClass: TClass): TRttiType; overload;
function GetTypes: TArrayTRttiType;
function FindType(const AQualifiedName: string): TRttiType;
function GetPackages: TArrayTRttiPackage;
end;
where TArrayTRttiPackage and TArrayTRttiType is btw a generically defined
= TArrayT=array of T;
Since Delphi can have only one instance of a unit in memory (error on load
otherwise regarding duplicate units), and can load/unload dll/bpl at runtime,
the entire FindType method starts with the packages and the onload/onunload
hooks must take into account that that array gets updated/invalidated.
bidirectional dependencies are to be avoided, but here we are... make without
packages = change interface, change trivialness of implementation, change rtti
on types; implement packages later on = reimplement, reinstate interface,
change rtti again on types (if still possible).
kind regards,
Dimitri Smits
- Michael Van Canneyt mich...@freepascal.org schreef:
On Wed, 22 Dec 2010, Dimitri Smits wrote:
Hi,
what is so different on this mail than the one I sent a few months
ago to the fpc-devel list?
anyway, it would require some packages (bpl) language/RTE additions
as well.
Would you care to explain why you think so ?
The 2 features have nothing to do with each other whatsoever.
You can perfectly add extended RTTI to FPC without package support.
It may be that package support (if/whenever it appears) may need to
take into account
RTTI, but certainly not the other way round.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Can variables be declared within a block?
- Bernd Kreuss prof7...@googlemail.com schreef: On 18.10.2010 15:19, Lukasz Sokol wrote: Having variables declared within code block used to require to parse the source code at least 2 times Or create them on the stack at the begin and remove them at the end of the block (which would be the only way to have some additional functionality through this). or do the same as with that vb-ism: the 'with' keyword. Only difference(s): it is named/typed and it is block-scoped from the point of declaration to the end of the current block statement. (I never use it, so I'm only guessing that it does something similar to the scenario explained above) on the other hand, what stops the OP from using 'with'? (multiple levels/variables?) and you won't die from using another stack variable scoped at the beginning of the method. just to say that I'm not too fond of that c-ism in a pascal language (although I've used it plenty in c++, java, C#, php, ... over the years). kind regards, Dimitri Smits ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Nesting
- Juha Manninen (gmail) juha.mannine...@gmail.com schreef: A new Lazarus review : http://delphimax.wordpress.com/2010/09/13/freepascal-and-lazarus-success-or- failure/ has this comment about Lazarus source: --- Abundant use of the Exit() command instead of nesting code in If/then/else. It has been proven (last time in Delphi Informant Magazine) that allowing a method to nest itself out makes faster code. It is also easier to read and study. Exit should of course be used (it must be used in many situations) but prudently. --- Does nesting really create faster code? not really tested, but think about the following: 1) with nesting: you validate an expression on being true/false. According to the result, you jump over a return statement of over a jmp statement to the cleanup block. (if not optimized by compiler) So, you ALWAYS jump/call. 2) without nesting: you validate an expression on being true/false. According to the result, you jump to the clean-up block. Otherwise you continue. I haven't studied processors that intimately on their branch-prediction beyond the original Pentium (586), but there it could have 'significant' repercussions with pipeline-stalling resulting in a few clock-cycles extra for a jump statement (regardless if it was taken). For readability I like the nesting style, except when there are very many such tests in one function. that is a matter of taste. I find the *overuse* of exit somewhat bad programming. It is not really clear in a function/procedure all the time during debugging why this piece of code is never visited when you have a few of those blocks above the said tested statement. A remnant of C-style programmers? Ofcourse there are cases where you need to use it, but in most cases it is about writing the correct control-statement. kind regards, Dimitri Smits ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fpc-pascal Digest, Vol 72, Issue 12
Graeme Geldenhuys wrote: In LCL the owner is always the form. Otherwise the form variables would not work. I know that, and the same think applies to VCL. But again, I don't see why Borland had to do that. Like fpGUI proves, it's not even required to have Owner and Parent. fpGUI can easily remove Parent and just use Owner and work perfectly. At the moment in fpGUI, Parent is just for convenience to VCL/LCL developers - it's just an alias for Owner. Parent and Owner are what they say they are. Owner: the TComponent that owns the TComponent-descendant. In other words, that is responsible for the lifecycle of that instance. Parent: the control on which the control is visualised. It is not because by default the LCL or VCL don't keep those in sync in most cases, that it is redundant. I've seen plenty in my 10+ Delphi years of code where a control is created by another TComponent and where the parent is set to a control on a(nother) Tform or container. Whether or not that is good design in all cases is not the issue. The point is that they do not need to be the same. (as well as Parent can be a container) I then conclude from your case above, Graeme, that fpgui does not work with containers like TPanel/TGroupbox/... and does not allow to inject extra visual controls on another form? kind regards, Dimitri Smits ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
