[Lazarus] Unicode branch

[Benito van der Zander]

That would be much clearer to use, if Pascal had scope local variables 
and auto created stack objects:

begin
    var x: SetBusyMouseCursorObject;
end;


That would also make the ref-counted classes at language level 
unnecessary, because you could just use

       type TObjectWithRefCounting=  specialize TRefCountingObject<TObjectWithoutRefCounting>;




Benito

On 06/30/2013 10:14 PM, Graeme Geldenhuys wrote:
> On 2013-06-30 17:25, Hans-Peter Diettrich wrote:
>> I'm somewhat confused now. When an object has an definite "last use", it
>> should not matter when it is destroyed afterwards, sooner or later.
>
> The simplest example... You have code that executes when the Interface
> gets destroyed. A very simple example (you can Google for exact code or
> more examples) is using Interfaces to change the mouse cursor to "busy",
> then let the Interface set the mouse cursor back to what it initially
> was when the Interface finally goes out of scope.
>
> eg: [not really code - ]
>
> procedure SomeLongProcedure;
> begin
>    SetBusyMouseCursor;
>    // <----------------------- (2)
>    ... long running code here
> end;   //  <------------------ (1)
>
>
> (1) is where Delphi will release the interface, and the mouse cursor
> will be reset. Always at the end of a code block.
>
> (2) is where FPC will release the interface, and the mouse cursor will
> be reset [at the undesired place].
>
>
> Like I said, this is a very simple example - but the Delphi behaviour is
> consistent since forever, and allows for some very nifty code (eg:
> debugging call stacks etc) - and without the need to define local
> interface variables.
>
> Regards,
>    - Graeme -
>
>
>
> --
> _______________________________________________
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20130701/708a4e77/attachment-0003.html>