the users must compile the RTL for non Lazarus use.
=
Really , it needs FPC sources at user's side.
Then a workaround - to maintain protected properties for private variables :
private
fldPrivate1: integer;
fldPrivate2: string;
[..]
private
prorerty Private1: integer read fldPri
On Saturday 21 July 2012 23:57:50 Florian Klämpfl wrote:
> Am 21.07.2012 23:06, schrieb Ivanko B:
> > No, just reorder the fields so that they can be properly $IFDEFed as
> > protected for nonLAZARUS and left (private) as is otherwise.
>
> Why should lazarus people have less chances to mess with pr
Hi,
There MoveChars* function (or similar) native on Free Pascal?
(*) -
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/System_MoveChars.html
Thanks,
--
Silvio Clécio
My public projects - github.com/silvioprog
___
But for very base (not yet specialized) classes - a good idea.
2012/7/22, Ivanko B :
> Why should lazarus people have less chances to mess with private fields?
> =
> AFAIK, they haven't to use any crackers up to now and it is a normal
> way for the mainstream - where complier & IDE are mai
Why should lazarus people have less chances to mess with private fields?
=
AFAIK, they haven't to use any crackers up to now and it is a normal
way for the mainstream - where complier & IDE are maintained by same
team so fixing any bugs is much more urgent than for no-mainstream.
Either we
Am 21.07.2012 23:06, schrieb Ivanko B:
> No, just reorder the fields so that they can be properly $IFDEFed as
> protected for nonLAZARUS and left (private) as is otherwise.
Why should lazarus people have less chances to mess with private fields?
Either we make them public for all or for nobody. O
Smth like the below:
type
TNonCrackableClass = class
private
fldPrivate1: integer;
fldPrivate2: styring;
{$ifndef nonLazarus}
fldPrivate3: real; // for LAZARUS
{$else}
protected
fldPrivate3: real; // for MSEgui/FPgui
{$endif}
protected
fldProtected1: string
public
[..]
end;
2012/7/22
No, just reorder the fields so that they can be properly $IFDEFed as
protected for nonLAZARUS and left (private) as is otherwise. Sure not
every filed but those the non-mainstreams developers ask. This'll
allow the non-mainstreams to start fixing right now.
Florian, it's a huge headache for Martin
Am 21.07.2012 20:47, schrieb Ivanko B:
> I don't see cracker classes as valid code.
> =
> Then the FPC team should eliminate the need in such crackers - via
> either disabling (via licencing, prisoning etc) the "impatient"
> [mainly because of impatient customers] non-mainstreams (non-L
I don't see cracker classes as valid code.
=
Then the FPC team should eliminate the need in such crackers - via
either disabling (via licencing, prisoning etc) the "impatient"
[mainly because of impatient customers] non-mainstreams (non-Lazarus)
or meeting needs of the non-mainstreams (
Am 21.07.2012 18:48, schrieb Martin:
> On 21/07/2012 16:55, Ivanko B wrote:
>> The problem now is that cracker classes can't be used in future anymore
>> because of the new class field ordering optimisation, so I dared to
>> ask.
>
>> So, is it possible to design the new feature in such way
Or an option:
{$ifdef nonLazarus}
protected
...
{$else}
private
...
{$endif}
Then MSEgui/FPgui/.. may be compiled with "-DnonLazarus" option
2012/7/21, Ivanko B :
> The problem now is that cracker classes can't be used in future anymore
> because of the new class field ordering optimisation, s
On 21/07/2012 16:55, Ivanko B wrote:
The problem now is that cracker classes can't be used in future anymore
because of the new class field ordering optimisation, so I dared to ask.
So, is it possible to design the new feature in such way that to have
an option to proceed using cracker c
On 14/07/2012 20:46, Jonas Maebe wrote:
That may actually lead to quite some troubles: if someone recompiles the RTL without
optimizations, then your class crackers also have to change that setting. And there's no
way to detect how the RTL (or in general: units containing classes you are
"crac
The problem now is that cracker classes can't be used in future anymore
because of the new class field ordering optimisation, so I dared to ask.
==
The guys, this point is important !
All the discussion members are right in their arguments (Martin's &
the "community" impatience to fix
15 matches
Mail list logo
