On Fri, Mar 2, 2012 at 5:14 PM, Sven Barth wrote:
> On 02.03.2012 20:03, Sven Barth wrote:
>>
>> > One more question: why this feature isn't works when used with
>> arguments?
>> > The arguments could have the same name of a property.
>>
>> Normally it should work with arguments as well, but the
On 02.03.2012 20:03, Sven Barth wrote:
> One more question: why this feature isn't works when used with arguments?
> The arguments could have the same name of a property.
Normally it should work with arguments as well, but there is a bug if
you define a property with an identifier that's used
Am 02.03.2012 16:48 schrieb "Marcos Douglas" :
>
> On Fri, Mar 2, 2012 at 10:39 AM, Sven Barth
wrote:
> > Am 02.03.2012 13:23, schrieb Marcos Douglas:
> >
> >> On Thu, Mar 1, 2012 at 5:49 PM, Sven Barth
> >> wrote:
> >>>
> >>> On 01.03.2012 21:42, Marcos Douglas wrote:
>
>
> On Thu
On Fri, Mar 2, 2012 at 10:39 AM, Sven Barth wrote:
> Am 02.03.2012 13:23, schrieb Marcos Douglas:
>
>> On Thu, Mar 1, 2012 at 5:49 PM, Sven Barth
>> wrote:
>>>
>>> On 01.03.2012 21:42, Marcos Douglas wrote:
On Thu, Mar 1, 2012 at 5:14 PM, Sven Barth
wrote:
>
>
> O
Am 02.03.2012 13:23, schrieb Marcos Douglas:
On Thu, Mar 1, 2012 at 5:49 PM, Sven Barth wrote:
On 01.03.2012 21:42, Marcos Douglas wrote:
On Thu, Mar 1, 2012 at 5:14 PM, Sven Barth
wrote:
On 01.03.2012 16:34, Marcos Douglas wrote:
On Thu, Mar 1, 2012 at 4:29 AM, leledumbo
wrote:
T
On Fri, Mar 2, 2012 at 10:48 AM, leledumbo wrote:
>> But if I have many methods with a identifier like Value, I will have
> to modify all methods and put something like lValue, Value1, etc.
>
> Trust me, that's MUCH better than letting the compiler compiles wrong code.
> i.e. it refers to identifi
> But if I have many methods with a identifier like Value, I will have
to modify all methods and put something like lValue, Value1, etc.
Trust me, that's MUCH better than letting the compiler compiles wrong code.
i.e. it refers to identifier we don't mean to refer. I've had a lot of this
before
On Thu, Mar 1, 2012 at 5:49 PM, Sven Barth wrote:
> On 01.03.2012 21:42, Marcos Douglas wrote:
>>
>> On Thu, Mar 1, 2012 at 5:14 PM, Sven Barth
>> wrote:
>>>
>>> On 01.03.2012 16:34, Marcos Douglas wrote:
On Thu, Mar 1, 2012 at 4:29 AM, leledumbo
wrote:
>
>
> That
> However the compiler specifically names other units as the culprit, so who
knows.
Yep, and according to the error message, what if you open the corresponding
unit at the position told by the compiler?
Hint: Your form must be a descendant of TForm which perhaps has... guess it
;)
--
View this m
On 01.03.2012 21:42, Marcos Douglas wrote:
On Thu, Mar 1, 2012 at 5:14 PM, Sven Barth wrote:
On 01.03.2012 16:34, Marcos Douglas wrote:
On Thu, Mar 1, 2012 at 4:29 AM, leledumbo
wrote:
That's different case IMHO (In My Humble Observation), I guess it's
something
like this:
{$mode objfpc}
On Thu, Mar 1, 2012 at 5:14 PM, Sven Barth wrote:
> On 01.03.2012 16:34, Marcos Douglas wrote:
>>
>> On Thu, Mar 1, 2012 at 4:29 AM, leledumbo
>> wrote:
>>>
>>> That's different case IMHO (In My Humble Observation), I guess it's
>>> something
>>> like this:
>>>
>>> {$mode objfpc}
>>> type
>>> TT
On 01.03.2012 16:34, Marcos Douglas wrote:
On Thu, Mar 1, 2012 at 4:29 AM, leledumbo wrote:
That's different case IMHO (In My Humble Observation), I guess it's something
like this:
{$mode objfpc}
type
TTestClass = class
FTile: Integer;
property Tile: Integer read FTile write FTile;
On Thu, Mar 1, 2012 at 4:29 AM, leledumbo wrote:
> That's different case IMHO (In My Humble Observation), I guess it's something
> like this:
>
> {$mode objfpc}
> type
> TTestClass = class
> FTile: Integer;
> property Tile: Integer read FTile write FTile;
> procedure Test;
> end;
>
> pr
Hi leledumbo,
I also tend to Think it's something like that with non-scoped records or
something similar. (this is mostly non-oop code, but there are record types
with members called "tile" in other units that get pulled in...)
However the compiler specifically names other units as the culprit
Sven,
No, I used it only in TW var section of various methods as a temporary
structure. I should note that this compiled in FPC 2.4 fine.
(that said, the source code in question is quite messy...)
-- Noah
On 2012/03/01, at 16:17, Sven Barth wrote:
> Am 01.03.2012 03:35, schrieb Noah Silva:
That's different case IMHO (In My Humble Observation), I guess it's something
like this:
{$mode objfpc}
type
TTestClass = class
FTile: Integer;
property Tile: Integer read FTile write FTile;
procedure Test;
end;
procedure TTestClass.Test;
var
Tile: Integer;
begin
end;
begin
e
Am 01.03.2012 03:35, schrieb Noah Silva:
Hi leledumbo,
(Changing the topic to indicate OT)
I didn't really take time to figure out whether it "should" be happening
or not, I just changed the references not to conflict. If you are
interested, though, I reproduced it in the screenshot below for
Hi leledumbo,
(Changing the topic to indicate OT)
I didn't really take time to figure out whether it "should" be happening or
not, I just changed the references not to conflict. If you are interested,
though, I reproduced it in the screenshot below for you:
https://picasaweb.google.com/lh/photo
18 matches
Mail list logo
