Re: [fpc-pascal] Cloning objects?
On 19.03.2014 23:01, Timothy Groves wrote: Is there a drop-dead simple way to clone an object? I've got a small tree of classes (tBaseProfile, and four descendants of such). Only the descendant classes are instantiated. I need to be able to create new copies of these objects for use in other lists. At the moment, I am writing a Duplicate method that returns the new object. But this means assigning all of the data to the duplicated object. There must be an easier way! There is usually a good reason to NOT do it blindly for all members and why you don't find a default clone method in any programming language in can think of right now. Just think about it: you clone a database object (from an ORM or similar). How far does the clone/copy go? Will you also clone the associated database connection object? Probably not, so your manual code would only assign the same reference to the clone. However the table name, field name, sql statement etc. will be copied. Or think about file access: your object has a TFileStream as member. Will you clone that? What if the access was read/write and maybe even exclusive? IMHO there is no one-size-fits-all here. Best regards, Andreas signature.asc Description: OpenPGP digital signature ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSQLQuery.ApplyUpdates problem with UTF-8
Dennis Poon wrote / napísal(a):
I tried, the results are:
@@character_set_client : utf8
@@character_set_connection : latin1
@@character_set_database : latin1
Dennis, do you received my reply?:
IMO @@character_set_connection is wrong and must be utf8.
I will try fix it, but first can you try as workaround this:
- after connection is established can you use
MySQLConnection1.ExecuteDirect('SET NAMES ''utf8''');
- and then check again @@character_set_client,
@@character_set_connection (IMO both must be utf8 ... if they will be,
then your program should work as expected ... can you test it again?)
-Laco.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cloning objects?
On 03/19/2014 11:01 PM, Timothy Groves wrote: Is there a drop-dead simple way to clone an object? AFAIK, there are good reasons, why any class needs to implement it's own dedicated assign method to be cloneable. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linking object file
Thanks Tomas, I did a quick test and it works perfectly! Regards, Darius Tomas Hajny schreef op 20 mrt '14: On Wed, March 19, 2014 23:49, Darius Blaszyk wrote: Hi, I was wondering if it's possible to link FPC object files by using the $Link directive? At least I have troubles in getting this to work and therefore I'm asking here. Please consider the minimal example I have attached to this email. When linking the object file that implements the test_proc procedure I get the following compiler output: Hint: Start of reading config file C:lazarusfpc2.6.2binx86_64-win64fpc.cfg Hint: End of reading config file C:lazarusfpc2.6.2binx86_64-win64fpc.cfg Free Pascal Compiler version 2.6.2 [2014/02/28] for x86_64 Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Win64 for x64 Compiling test.pp Linking test.exe test.pp(8,1) Error: Undefined symbol: TEST_INT_TEST_PROC test.pp(8,1) Fatal: There were 1 errors compiling module, stopping What is needed in the test_impl.pas file so the linker can find the implemented function? Do I need to create a library and export the function perhaps? Basically, you have two options: 1) Provide the import declaration with the mangled name (i.e. the name really stored within the .o file). This may possibly change between different FPC versions, but if you intend to link to an existing object file, you would already know which one was used. In your case, this would mean changing line 7 in test_int.pas to: procedure test_proc; external name 'TEST_IMPL_TEST_PROC'; (the mangled name may be found either by using -a when compiling test_impl.pas and looking into the generated test_impl.s or e.g. by using 'objdump -t test_impl.o'. 2) Specify your own name during rather than relying on some mangling rules - change line 7 in test_impl.pas to: procedure test_proc; export alias: 'My_Test_Proc'; and then line 7 in test_int.pas needs to change accordingly to: procedure test_proc; external name 'My_Test_Proc'; Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal [1] Links: -- [1] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] THandle in code that must compile also with Delphi
FileCreate and FileOpen return THandle with FPC but integer with Delphi2007. Delphi defines THandle as LongWord but for some reason Integer is used instead. With FPC on a 64-bit system THandle is 64- bit unsigned. Question: what is the best way to maintain code that must compile with both FPC and Delphi2007? The obvious solution is to use IFDEF and define a new type, say TMyHandle. FPC's libraries however take care of many platform differences. Is there any better way to solve this? Regards, Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error compile library on Linux.
It's quite possible that there is nevertheless a bug, but you will have to provide the source code required to reproduce it and compilation instructions, otherwise there is nothing we can do (as always). Hum, not too much answer here... ;-( Re-resumed : Units/Project = https://github.com/graemeg/fpGUI/tree/develop Download it by Clicking on Download ZIP. Then in /fpGUI/src/corelib/ Try to compile that simple library with Linux 64 bit : library fpGUI; uses fpg_main; = error while compiling on Linux 64 bit. begin end. Compiler parameters (need parh of fpGUI too) : -MObjFPC -Scghi -CX -Os1 -Xs -XX -vewnhi -fPIC -Fu Many thanks. Fred ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] THandle in code that must compile also with Delphi
On Thu, 20 Mar 2014, Juha Manninen wrote: FileCreate and FileOpen return THandle with FPC but integer with Delphi2007. Delphi defines THandle as LongWord but for some reason Integer is used instead. With FPC on a 64-bit system THandle is 64- bit unsigned. Question: what is the best way to maintain code that must compile with both FPC and Delphi2007? The obvious solution is to use IFDEF and define a new type, say TMyHandle. FPC's libraries however take care of many platform differences. Is there any better way to solve this? Shortly said: No. The Delphi API is wrong; It should also return THandle (as that is what Windows CreateFile returns), but probably for historical reasons they still use Integer. With the advent of 64-bit delphi, they could have cleaned up their API, but Alas... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] THandle in code that must compile also with Delphi
In our previous episode, Michael Van Canneyt said: Question: what is the best way to maintain code that must compile with both FPC and Delphi2007? The obvious solution is to use IFDEF and define a new type, say TMyHandle. FPC's libraries however take care of many platform differences. Is there any better way to solve this? Shortly said: No. The Delphi API is wrong; It should also return THandle (as that is what Windows CreateFile returns), but probably for historical reasons they still use Integer. With the advent of 64-bit delphi, they could have cleaned up their API, but Alas... IMHO the universal handle (for e.g. IPC related handles and file handles) is not a portable concept to begin with. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] THandle in code that must compile also with Delphi
On Thu, 20 Mar 2014, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: Question: what is the best way to maintain code that must compile with both FPC and Delphi2007? The obvious solution is to use IFDEF and define a new type, say TMyHandle. FPC's libraries however take care of many platform differences. Is there any better way to solve this? Shortly said: No. The Delphi API is wrong; It should also return THandle (as that is what Windows CreateFile returns), but probably for historical reasons they still use Integer. With the advent of 64-bit delphi, they could have cleaned up their API, but Alas... IMHO the universal handle (for e.g. IPC related handles and file handles) is not a portable concept to begin with. Normally, I'd expect a TXYZHandle for each 'separate' type. With XYZ = File, Window, Lib, Module, Directory, Shmem, whatnot. This should cover most cases. That these separate types are equal in the background is something the user need not know. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] THandle in code that must compile also with Delphi
On Thu, 20 Mar 2014 13:02:28 +0100 (CET), Michael Van Canneyt mich...@freepascal.org wrote: Shortly said: No. The Delphi API is wrong; It should also return THandle (as that is what Windows CreateFile returns), but probably for historical reasons they still use Integer. With the advent of 64-bit delphi, they could have cleaned up their API, but Alas... I did try googling and it appears, that in 64 bit Delphi XE2 uses THandle as a result type. Anyway, in the case of error, it returns INVALID_HANDLE_VALUE, which is DWORD(-1). So, under Windows it would be possible to use same code, if you compare result against INVALID_HANDLE_VALUE. And you should be able safely cast return value to THandle for that (and use variable of that type). I really don't know, how it would work on linux, because sys_open seems to return int there. -- Virgo Pärna virgo.pa...@mail.ee ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] THandle in code that must compile also with Delphi
Marco van de Voort wrote: IMHO the universal handle (for e.g. IPC related handles and file handles) is not a portable concept to begin with. I think the concept of a handle as an opaque type is universal. What isn't safe is any assumption of consistent behaviour, e.g. that select() may be applied to any type of handle or that a program's stdin/stdout might in practice be implemented by a socket. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSQLQuery.ApplyUpdates problem with UTF-8
I tried, the results are:
@@character_set_client : utf8
@@character_set_connection : latin1
@@character_set_database : latin1
Dennis, do you received my reply?:
IMO @@character_set_connection is wrong and must be utf8.
I will try fix it, but first can you try as workaround this:
- after connection is established can you use
MySQLConnection1.ExecuteDirect('SET NAMES ''utf8''');
- and then check again @@character_set_client,
@@character_set_connection (IMO both must be utf8 ... if they will be,
then your program should work as expected ... can you test it again?)
-Laco.
I tried MYSQLConnection1.ExecuteDirect('SET NAMES ''utf8'';');
and recheck
@@character_set_client: utf8
@@character_set_connection : utf8
@@character_set_database : latin1
So, it corrected one variable.
I re-ran my test but still ?? after applyUpdates.
Dennis
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] THandle in code that must compile also with Delphi
In our previous episode, Mark Morgan Lloyd said: IMHO the universal handle (for e.g. IPC related handles and file handles) is not a portable concept to begin with. I think the concept of a handle as an opaque type is universal. What isn't safe is any assumption of consistent behaviour, e.g. that select() may be applied to any type of handle or that a program's stdin/stdout might in practice be implemented by a socket. Before that, I don't even think sizeof(any handle)=constant for a given target is a valid assumption. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] THandle in code that must compile also with Delphi
On Thu, Mar 20, 2014 at 3:25 PM, Virgo Pärna virgo.pa...@mail.ee wrote: I did try googling and it appears, that in 64 bit Delphi XE2 uses THandle as a result type. Anyway, in the case of error, it returns INVALID_HANDLE_VALUE, which is DWORD(-1). So, under Windows it would be possible to use same code, if you compare result against INVALID_HANDLE_VALUE. And you should be able safely cast return value to THandle for that (and use variable of that type). I really don't know, how it would work on linux, because sys_open seems to return int there. Thanks Virgo for this note. I was just thinking of how to check for errors. In many places our Delphi code has : if Handle-1 then begin ... end; I will not define a new type after all, instead I will use THandle everywhere and then compare against INVALID_HANDLE_VALUE which is defined in Windows unit also for Delphi2007. The only downside is that Delphi compiler will complain about incompatible types (signed / unsigned) when assigning FileCreate() etc. return values. I must use typecast then but it is OK. Regards, Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Lazarus better than delphi
I have been using Delphi 7 forever. I evaluated Delphi xe5 Update 2. Today, I use Lazarus 1.2 and FPC 2.6.2. Lazarus/FPC is just better than Delphi. All development on Mac/Windows is now with Lazarus. You FPC/Lazarus guys ROCK. Best wishes for 2014. md ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazarus better than delphi
m...@rpzdesign.com wrote: I have been using Delphi 7 forever. I evaluated Delphi xe5 Update 2. Today, I use Lazarus 1.2 and FPC 2.6.2. Lazarus/FPC is just better than Delphi. All development on Mac/Windows is now with Lazarus. You FPC/Lazarus guys ROCK. Best wishes for 2014. md I would like to second that. Delphi after Delphi 7 is disappointing, bulky and inefficient. Thanks so much for you guys! Dennis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
