Re: [fpc-pascal] TPicture (Graphics unit)
Leonardo M. Ramé wrote: in Graphics.pas, but I can't find it in FPC. Is this class replaced by a similar one? I you just want to load and manipulate an image, you should be able to use the fpimage.pp unit included with FPC. I you are looking for the TPicture class specifically, then you will have to use the Lazarus LCL (Lazarus Component Library) which is a clone of the Delphi VCL. Regards, - Graeme - -- fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Records as properties and Delphi compiler error
Hi Jonas
Thanks for the reply.
A high level, a class is like a record that has been modified to include
functions and procedures. I know that I'm over simplifying thing here, please
bare with me.
I'm trying to understand the logic employed by the creators of Delphi where
they don't allow to write to the fields of a record type property, but if the
property points to a class type, then anything goes. In the example bellow,
where a property is of a class type, both Delphi and FPC compile the code,
but there is no guarantee that the object referenced to by the property has
been instantiated before the property is used (The programmer must
instantiate the TTestProp class within TTestClass prior to any call made to
the property). IMO, it would be a nice feature if the compiler could be
modified to issue a warning in such a case.Again, I'm over simplifying, to
the compiler, it would be similar to checking for a variable declaration
before the variable is used.
I thing that the error in the way that FPC allows record properties to
access the record fields could be handy if retained. Perhaps this feature
could be reserved for objfpc mode. What are your thoughts on the matter?
Regards,
Nino
//--
unit Unit1;
(*
This code sample is written for use with Lazarus.
The Delphi equivalent also compile using Delphi.
*)
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, FileUtil, LResources, Forms, Controls, Graphics, Dialogs,
StdCtrls;
type
TForm1 = class(TForm)
Button1 : TButton;
procedure Button1Click(Sender : TObject);
private
public
end;
TTestProp = class
private
fX : Byte;
fY : Byte;
public
property X : Byte read fX write fX;
property Y : Byte read fY write fY;
end;
TTestClass = class
private
fTestProp : TTestProp;
public
constructor Create();
destructor Destroy(); override;
property TestProp : TTestProp read fTestProp write fTestProp;
end;
var
Form1 : TForm1;
implementation
constructor TTestClass.Create();
begin
//* If this line is commented, the compilation will succeed
//* but a violation will occur at runtime in button click handler
//* since the object referenced does not exist.
//*
//* Note: I'm not suggesting here that the compile should be aware
//* that this object, whilst being referenced later in the code,
//* is not instantiated, but it would be a cool feature if the compiler
//* could be modified to issue at least a warning advising of such an event.
fTestProp := TTestProp.Create();
end;
destructor TTestClass.Destroy();
begin
if Assigned(fTestProp) then
FreeAndNil(fTestProp);
inherited Destroy();
end;
procedure TForm1.Button1Click(Sender : TObject);
var
TestClass : TTestClass;
begin
TestClass := TTestClass.Create();
try
ShowMessage('TestProp before' + #13 +
'X = ' + IntToStr(TestClass.TestProp.X) + #13 +
'Y = ' + IntToStr(TestClass.TestProp.Y));
TestClass.TestProp.X := 10;
TestClass.TestProp.Y := 20 ;
ShowMessage('TestProp after' + #13 +
'X = ' + IntToStr(TestClass.TestProp.X) + #13 +
'Y = ' + IntToStr(TestClass.TestProp.Y));
finally
FreeAndNil(TestClass);
end;
end;
initialization
{$I unit1.lrs}
end.
//*
On Saturday 06 June 2009 18:27:03 Jonas Maebe wrote:
On 06 Jun 2009, at 17:36, fpcl...@silvermono.co.za wrote:
Is there a reason why the following code fails to compile in Delphi
but
compile in FPC? Could the reason be that FPC allows the use of global
properties?
No, it's an error in FPC which has been fixed in 2.3.1:
http://wiki.freepascal.org/User_Changes_Trunk#Treating_direct-mapped_proper
ties_as_regular_fields
Jonas
___
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] TPicture (Graphics unit)
Thanks Graeme, I'll take a look at fpimage unit. Leonardo M. Ramé http://leonardorame.blogspot.com --- On Sun, 6/7/09, Graeme Geldenhuys grae...@opensoft.homeip.net wrote: From: Graeme Geldenhuys grae...@opensoft.homeip.net Subject: Re: [fpc-pascal] TPicture (Graphics unit) To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Date: Sunday, June 7, 2009, 4:22 AM Leonardo M. Ramé wrote: in Graphics.pas, but I can't find it in FPC. Is this class replaced by a similar one? I you just want to load and manipulate an image, you should be able to use the fpimage.pp unit included with FPC. I you are looking for the TPicture class specifically, then you will have to use the Lazarus LCL (Lazarus Component Library) which is a clone of the Delphi VCL. Regards, - Graeme - -- fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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] Records as properties and Delphi compiler error
On 07 Jun 2009, at 10:35, fpcl...@silvermono.co.za wrote: A high level, a class is like a record that has been modified to include functions and procedures. I know that I'm over simplifying thing here, please bare with me. The difference you skip over is the fundamental reason why one works and the other doesn't: a class is a pointer, while a record is a value. I'm trying to understand the logic employed by the creators of Delphi where they don't allow to write to the fields of a record type property, but if the property points to a class type, then anything goes. In case of a class, the property returns a pointer (namely the pointer to the class instance data), and then you (implicitly) dereference the pointer and write data where it points to. In case of a record, the property returns a record's value, and then (semantically) you change the value of this returned record (not the value of the element of the record that the property referred to). This worked in previous FPC versions because rather than treating the result of the property like a function result (which it has to, because that's the semantical meaning of a property, so you can transparently change them into getters/setters without breaking any code), it treated it like a direct field access in case no getter/ setter existed. So rather than returning a record's value, the property returned a reference to a record. In the example bellow, where a property is of a class type, both Delphi and FPC compile the code, but there is no guarantee that the object referenced to by the property has been instantiated before the property is used (The programmer must instantiate the TTestProp class within TTestClass prior to any call made to xx the property). IMO, it would be a nice feature if the compiler could be modified to issue a warning in such a case.Again, I'm over simplifying, to the compiler, it would be similar to checking for a variable declaration before the variable is used. Except that it's about dynamically allocated memory and depends on interprocedural control flow graph analysis, which makes it immensely more complex. I thing that the error in the way that FPC allows record properties to access the record fields could be handy if retained. Perhaps this feature could be reserved for objfpc mode. What are your thoughts on the matter? Things will remain the way they are for the reasons explained above. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
