[fpc-pascal] Halt() bypassed try..finally block

[Graeme Geldenhuys]

Hi,

Is that correct behavior?  When calling Halt() somewhere inside a
try..finally block, it _doesn't_ execute the finally code.

In fpGUI I used Halt() to terminate the event loop and exit a
application. I then noticed that NO cleanup code gets executed after
that call. Not objects get freed via destructors etc...  Since I
noticed this, I implemented a more graceful termination process, but
Halt() is really harsh!  :-)

Regards,
  - Graeme -
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Halt() bypassed try..finally block

[Michael Van Canneyt]

On Thu, 13 Sep 2007, Graeme Geldenhuys wrote:

> Hi,
> 
> Is that correct behavior?  When calling Halt() somewhere inside a
> try..finally block, it _doesn't_ execute the finally code.

This is by design.

Halt finalizes the units and then exits.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Halt() bypassed try..finally block

[Matt Emson]

Michael Van Canneyt wrote:

On Thu, 13 Sep 2007, Graeme Geldenhuys wrote:

  

Hi,

Is that correct behavior?  When calling Halt() somewhere inside a
try..finally block, it _doesn't_ execute the finally code.



This is by design.

Halt finalizes the units and then exits.

Yeah, I always used to use something like:

var
 haltApp: boolean;
begin

haltApp := false;

try
 //some code that does something
 if (some_condition) then
 begin
   haltApp := true;
   exit;
 end;
 //some other code
finally
 //cleanup code

 if (haltApp) then Halt(halt_condition_code); // one could argue this 
should be outside of the finally,
// 
but if it were it would not always be executed as
// 
desired - especially if an exception was raised. 
end;

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Halt() bypassed try..finally block

[Graeme Geldenhuys]

On 13/09/2007, Michael Van Canneyt <[EMAIL PROTECTED]> wrote:

> > Is that correct behavior?  When calling Halt() somewhere inside a
> > try..finally block, it _doesn't_ execute the finally code.
>
> This is by design.
>
> Halt finalizes the units and then exits.


Thanks. I'll make a mental note to stay away from it.  :)

Regards,
  - Graeme -
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] fpGUI (a Free Pascal GUI Library) version 0.5 has been released

[Graeme Geldenhuys]

Hi,

fpGUI version 0.5 has been released.

This is the first release since the rewrite. A lot has been improved
and added. For one, fpGUI now has it's own GUI Designer. Loads of new
widgets have also been created.

Source and documentation are available for download at SourceForge:
  http://sourceforge.net/project/showfiles.php?group_id=182330

Release notes can be read at:  http://tinyurl.com/2lqpkx

For more information on fpGUI visit:
  http://opensoft.homeip.net/fpgui/

Support newsgroup:
  news://opensoft.homeip.net


Regards,
  - Graeme -
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Resourcestring questions

[Adriaan van Os]

FPCs resourcestring feature is a great way to localize applications, yet I have the following 
questions.


1. The tutorial at 
 gives the 
following example


 resourcestring
   Caption1 = 'Some text';
   HelloWorld1 = 'Hello World';

 Label1.Caption := HelloWorld1;

Wouldn't it be simpler if resourcestrings could be defined and used directly by the form ? That 
would save a lot of code of the form Labelxx.Caption := yyy. Of course, this implies a "reload form 
strings" method to reload form strings when the current language changes.


(my apologies if this is a Lazarus question, it seems related to the compiler 
also)

2. Previously, when using a "GetStringFromResource" routine, I could write 
something like

for n:=1 to 100 do ComboAdd( GetStringFromResource( kComboItemOffs + n))

This doesn't seem to be possible with resourcestring lists, because they use string constants, 
rather then numbers. Unless, of course, we extend the compiler to optionally attach a number or a 
number-constant to resourcestring entries rather than a string constant. Plus a standard function 
that converts the number into a string. This facilitates converting current applications (that 
still use resource IDs) also. Any comments ?


Regards,

Adriaan van Os
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal