On Sunday 13 September 2009 23:38:08 Jonas Maebe wrote:
> If the behaviour is different in Delphi.
at least in kylix.
this works in kylix and not in fpc
$ cat hooks2.pas
program hooks;
On 13 Sep 2009, at 23:32, Den Jean wrote:
On Sunday 13 September 2009 22:05:17 Jonas Maebe wrote:
That's why in objfpc mode you can (have to) use Hook_Signal
(@MyMethod)
I was rather hoping for an answer/fix for Delphi Mode.
May I consider it a bug and file one ?
If the behaviour is differ
On Sunday 13 September 2009 22:05:17 Jonas Maebe wrote:
> That's why in objfpc mode you can (have to) use Hook_Signal(@MyMethod)
I was rather hoping for an answer/fix for Delphi Mode.
May I consider it a bug and file one ?
kind regards,
Den Jean
_
On 13 Sep 2009, at 22:02, Den Jean wrote:
So I cannot directly give the hooked procedure as a parameter
to a procedure, I have to do stuff like this
var M : TMethod
TSomeMethodTyp(M):=MyMethod
Hook_Signal(M);
Instead of
Hook_Signal(MyMethod)
That's why in objfpc mode you can (have to) use Hoo
On Thursday 10 September 2009 16:56:20 Peter Vreman wrote:
> You can use the TMethod record to access the fields:
> writeln(hexstr(tmethod(@c.p).data));
> writeln(hexstr(tmethod(@c.p).code));
> end.
kind of related to this,
In the Qt binding I had to revert to a non type safe method
for sign
On Saturday 12 September 2009 10:07:55 Mattias Gaertner wrote:
> On Sat, 12 Sep 2009 09:33:11 +0200
>
>
> Martin, I hope you mean Data=ID and Code=nil.
>
Yup, you are right, thanks for correcting.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepa
On Sat, 12 Sep 2009 09:33:11 +0200
Martin Schreiber wrote:
> On Thursday 10 September 2009 19:42:22 Ivo Steinmann wrote:
> > Florian Klaempfl schrieb:
> > > Ivo Steinmann schrieb:
> > >> 1. Using =nil or Assigned should result in the same.
> > >
> > > Afaik not, this was one of the reasons for as
On Thursday 10 September 2009 19:42:22 Ivo Steinmann wrote:
> Florian Klaempfl schrieb:
> > Ivo Steinmann schrieb:
> >> 1. Using =nil or Assigned should result in the same.
> >
> > Afaik not, this was one of the reasons for assigned.
> >
>
> well, nobody seems to know it... eg. if you go through c
Zitat von Michael Schnell :
Mattias Gärtner wrote:
The @ operator is more than "address of".
Hmm "Address of" is not that simple in itself. :)
With a "Procedure of Object", "@" of course handles the Self pointer, too.
I suppose to find the address of a function "@" uses the Virtual Method
On Thursday 10 September 2009 17:52:44 Florian Klaempfl wrote:
> Ivo Steinmann schrieb:
> > 1. Using =nil or Assigned should result in the same.
>
> Afaik not, this was one of the reasons for assigned.
>
I have always used Assigned() to test whether a pointer is 'valid' or is nil.
Thus Assiged()
Mattias Gärtner wrote:
>
> The @ operator is more than "address of".
>
Hmm "Address of" is not that simple in itself. :)
With a "Procedure of Object", "@" of course handles the Self pointer, too.
I suppose to find the address of a function "@" uses the Virtual Method
Table found with the Self
Michael Van Canneyt wrote:
On Thu, 10 Sep 2009, Florian Klaempfl wrote:
Mattias Gaertner schrieb:
On Thu, 10 Sep 2009 17:52:44 +0200
Florian Klaempfl wrote:
Ivo Steinmann schrieb:
1. Using =nil or Assigned should result in the same.
Afaik not, this was one of the reasons for assigned.
Florian Klaempfl schrieb:
Ivo Steinmann schrieb:
1. Using =nil or Assigned should result in the same.
Afaik not, this was one of the reasons for assigned.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/
On Thu, 10 Sep 2009, Florian Klaempfl wrote:
Mattias Gaertner schrieb:
On Thu, 10 Sep 2009 17:52:44 +0200
Florian Klaempfl wrote:
Ivo Steinmann schrieb:
1. Using =nil or Assigned should result in the same.
Afaik not, this was one of the reasons for assigned.
Are there any other reasons
Mattias Gaertner schrieb:
> On Thu, 10 Sep 2009 17:52:44 +0200
> Florian Klaempfl wrote:
>
>> Ivo Steinmann schrieb:
>>> 1. Using =nil or Assigned should result in the same.
>> Afaik not, this was one of the reasons for assigned.
>
> Are there any other reasons for assigned?
Distinction between
On Thu, 10 Sep 2009 17:52:44 +0200
Florian Klaempfl wrote:
> Ivo Steinmann schrieb:
> >
> > 1. Using =nil or Assigned should result in the same.
>
> Afaik not, this was one of the reasons for assigned.
Are there any other reasons for assigned?
Mattias
_
Mattias Gärtner wrote:
Zitat von Michael Schnell :
Mattias Gärtner wrote:
Can someone explain why in mode objfpc comparing methods only compares
the address, but not the instance?
Seems perfectly logical to me (@ = Address of, in this case "code
address", the code is the same for all instances
Ivo Steinmann schrieb:
>
> 1. Using =nil or Assigned should result in the same.
Afaik not, this was one of the reasons for assigned.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Thank you Peter.
TMethod would have been handy if i knew about this back then. For delphi
compatibility, I had to do this:
program methodpointer;
uses
Classes, sysutils;
type
TMyEvent = procedure of object;
TMyClass = class(TObject)
procedure MyMethod;
end;
{ TMyClass }
procedure
Mattias Gärtner schrieb:
Zitat von Vincent Snijders :
Jonas Maebe schreef:
On 10 Sep 2009, at 14:01, Mattias Gärtner wrote:
Mattias Gärtner wrote:
Can someone explain why in mode objfpc comparing methods only
compares
the address, but not the instance?
Seems perfectly logical to me (@
On Thu, 10 Sep 2009 14:25:26 +, Desmond Coertzen
wrote:
> I have done some horrible code where I needed to know the following:
>
> If TSomeProc = procedure(), then is it easy to determine or set
entry
> vector of ThatProc: TSomeProc by stating ThatProc :=
> @ProcWhereTheCodeLives_InTheCod
I have done some horrible code where I needed to know the following:
If TSomeProc = procedure(), then is it easy to determine or set entry
vector of ThatProc: TSomeProc by stating ThatProc :=
@ProcWhereTheCodeLives_InTheCodeSegment;
It gets more difficult when you work with TSomeClassProc = p
Zitat von Vincent Snijders :
Jonas Maebe schreef:
On 10 Sep 2009, at 14:01, Mattias Gärtner wrote:
Mattias Gärtner wrote:
Can someone explain why in mode objfpc comparing methods only compares
the address, but not the instance?
Seems perfectly logical to me (@ = Address of, in this case
Zitat von Jonas Maebe :
On 10 Sep 2009, at 14:01, Mattias Gärtner wrote:
Mattias Gärtner wrote:
Can someone explain why in mode objfpc comparing methods only compares
the address, but not the instance?
Seems perfectly logical to me (@ = Address of, in this case "code
address", the code is
Zitat von Thaddy :
Mattias Gärtner wrote:
Zitat von Michael Schnell :
Mattias Gärtner wrote:
Can someone explain why in mode objfpc comparing methods only compares
the address, but not the instance?
Seems perfectly logical to me (@ = Address of, in this case "code
address", the code is the
Jonas Maebe schreef:
On 10 Sep 2009, at 14:01, Mattias Gärtner wrote:
Mattias Gärtner wrote:
Can someone explain why in mode objfpc comparing methods only compares
the address, but not the instance?
Seems perfectly logical to me (@ = Address of, in this case "code
address", the code is the
Mattias Gärtner wrote:
Zitat von Michael Schnell :
Mattias Gärtner wrote:
Can someone explain why in mode objfpc comparing methods only compares
the address, but not the instance?
Seems perfectly logical to me (@ = Address of, in this case "code
address", the code is the same for all instanc
On 10 Sep 2009, at 14:01, Mattias Gärtner wrote:
Mattias Gärtner wrote:
Can someone explain why in mode objfpc comparing methods only
compares
the address, but not the instance?
Seems perfectly logical to me (@ = Address of, in this case "code
address", the code is the same for all instan
Zitat von Michael Schnell :
Mattias Gärtner wrote:
Can someone explain why in mode objfpc comparing methods only compares
the address, but not the instance?
Seems perfectly logical to me (@ = Address of, in this case "code
address", the code is the same for all instances of a class).
OnClic
Mattias Gärtner wrote:
Hi,
Can someone explain why in mode objfpc comparing methods only compares
the address, but not the instance?
For example:
a:=TMyClass.Create;
b:=TMyClass.Create;
if @a.test = @b.test then writeln('the same method');
This results in strange behaviors, when using
Mattias Gärtner wrote:
> Can someone explain why in mode objfpc comparing methods only compares
> the address, but not the instance?
Seems perfectly logical to me (@ = Address of, in this case "code
address", the code is the same for all instances of a class).
-Michael
___
31 matches
Mail list logo
