Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
Sven Barth wrote: On 11.02.2013 15:30, Mark Morgan Lloyd wrote: If anything, it is the fault of AppConfigDir for indicating a directory without raising an exception pointing out that it doesn't yet exist :-) And AppConfigDir/File is documented as not guaranteeing that the path to the directory or file exists. This also includes upper parts of the path's tree. I admit that I was slightly trolling there, since Giuliano was complaining about exceptions that he wasn't seeing (because, it turns out, he wasn't catching them). However I feel that my point stands: if the program opens, checks and closes the .ini file before the main logic starts, then it's possible to keep those initial activities separate from any try-finally required by the application logic. This initial activity obviously still requires both a try-finally and a try-except, which is where he was going wrong with his initial attempt. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Compiled program is a virus (seems to be internallinker problem)
On 11/02/2013 23:19, Gerhard Scholz wrote: I switched to AVAST free Antivirus now, the problem does not occur here. This is not a pascal question, but maybe can give me a hint if AVAST is good or which software is more recommendable. (I do not really trust the tests I find in the internet because I do not know who pays them) Gerhard I found myself recently quite comfortable using ZoneAlarm. L. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 02/11/2013 09:14 PM, Sven Barth wrote:
It would be nice if you could minimize the problemematic code further
step by step so that we can see what caused the missing dialog.
Maybe it's a bug somewhere else...
I've made some further experiments with my minimal test.
Test form is just a Form with a Close button (BitBtn Kind=bkClose).
The full code is the following:
unit uinitfile;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs,
Buttons,IniFiles;
type
{ TForm1 }
TForm1 = class(TForm)
BitBtn1: TBitBtn;
procedure FormClose(Sender: TObject; var CloseAction: TCloseAction);
procedure FormCreate(Sender: TObject);
private
{ private declarations }
public
{ public declarations }
end;
var
Form1: TForm1;
ini: TIniFile;
AppConfigFileName: string;
SomeData: boolean;
SomeOtherData: boolean;
implementation
{$R *.lfm}
{ TForm1 }
procedure TForm1.FormCreate(Sender: TObject);
begin
AppConfigFileName:= '/not/existing/path/inifile.cfg';
ini := TIniFile.Create(AppConfigFileName);
try
SomeData:= ini.ReadBool('Section','Val',true);
SomeOtherData:= ini.ReadBool('Section','Val1',true);
finally
ini.Free;
end;
end;
procedure TForm1.FormClose(Sender: TObject; var CloseAction: TCloseAction);
begin
ini:= TIniFile.Create(AppConfigFileName);
{$DEFINE Finally}
{$IFDEF Finally}
try
ini.WriteBool('Section','Val',SomeData);
ini.WriteBool('Section','Val1',SomeOtherData);
finally
ini.Free;
end;
{$ELSE}
try
ini.WriteBool('Section','Val',SomeData);
ini.WriteBool('Section','Val1',SomeOtherData);
except
MessageDlg('Error while writing '+AppConfigFileName,mtError,[mbOK],0);
end;
ini.Free;
{$ENDIF}
end;
end.
One may test two conditions: with try..finally and with try..except.
Even with this minimal sheds some light on the matter.
Try..finally situation, with IDE and Debugger.
Press the Close button. A debugger error notification is shown. Pressing
Continue, an error dialog is displayed: Unable to create ... press OK
to Ignore...etc.:
Pressing OK (no harm should come, just the file can't be written) the
form isn't closed as it should, and it's still there.
Pressing again the close Button, FormClose is executed again, and the
same dialog is shown. No way to close the form, unless you press Cancel
on the error dialog.
Why FormClose doesn't close the form in presence of an error (handled by
a try..finally) when writing the ini file?
Launching from command line, you have the same behavior, and an
additional information when you select Cancel:
WARNING: TLCLComponent.Destroy with LCLRefCount0. Hint: Maybe the component is
processing an event?
Try..except situation, from IDE and Debugger.
Press the Close button. Debugger Notification. Pressing Continue my
message dialog is shown. Pressing OK on my dialog the form is closed and
the program is terminated.
Launching from command line, no console messages.
My conclusion is that one can't properly handle INI files with just a
try..finally construct, as all examples show, because a possible error
will propagate outside the construct, with unpredictable effects (in
this case the FormClose procedure doesn't properly complete).
Giuliano
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
El 12/02/2013 13:29, Giuliano Colla escribió: My conclusion is that one can't properly handle INI files with just a try..finally construct, as all examples show, because a possible error will propagate outside the construct, with unpredictable effects (in this case the FormClose procedure doesn't properly complete). Hello, Finally always propagate the exception bubbling up looking for other exception handler, and that's its job, in comparation to except handler which eat the exception and if you need to propagate it again you must Raise in the exception handler. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 02/12/2013 10:02 AM, Mark Morgan Lloyd wrote: I admit that I was slightly trolling there, since Giuliano was complaining about exceptions that he wasn't seeing (because, it turns out, he wasn't catching them). You catch an exception if you can handle it. If a user for some reasons has write-protected a configuration file, there's nothing the application can do about it. One can usually rely on the system default exception handler to show the error message. If it doesn't happen, then there's something wrong somewhere. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 12.02.2013 13:29, Giuliano Colla wrote: On 02/11/2013 09:14 PM, Sven Barth wrote: It would be nice if you could minimize the problemematic code further step by step so that we can see what caused the missing dialog. Maybe it's a bug somewhere else... I've made some further experiments with my minimal test. Test form is just a Form with a Close button (BitBtn Kind=bkClose). The full code is the following: [snip] One may test two conditions: with try..finally and with try..except. Even with this minimal sheds some light on the matter. It indeed does, but not as you think. Try..finally situation, with IDE and Debugger. Press the Close button. A debugger error notification is shown. Pressing Continue, an error dialog is displayed: Unable to create ... press OK to Ignore...etc.: Pressing OK (no harm should come, just the file can't be written) the form isn't closed as it should, and it's still there. Pressing again the close Button, FormClose is executed again, and the same dialog is shown. No way to close the form, unless you press Cancel on the error dialog. Why FormClose doesn't close the form in presence of an error (handled by a try..finally) when writing the ini file? Launching from command line, you have the same behavior, and an additional information when you select Cancel: WARNING: TLCLComponent.Destroy with LCLRefCount0. Hint: Maybe the component is processing an event? Try..except situation, from IDE and Debugger. Press the Close button. Debugger Notification. Pressing Continue my message dialog is shown. Pressing OK on my dialog the form is closed and the program is terminated. Launching from command line, no console messages. My conclusion is that one can't properly handle INI files with just a try..finally construct, as all examples show, because a possible error will propagate outside the construct, with unpredictable effects (in this case the FormClose procedure doesn't properly complete). The problem is not INI files, but more how OnClose is handled. OnClose is called whenever the user tries to close the form and if an assigned event handler raises an exception it seems that the calling code assumes that the form should not be closed. In my example I used OnDestroy which seems to be handled more gracefully. I'd suggest you to ask on the Lazarus list whether it is intentionally that you can't close a form of which the OnClose event handler raises an exception. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On Tue, 12 Feb 2013, Sven Barth wrote: called whenever the user tries to close the form and if an assigned event handler raises an exception it seems that the calling code assumes that the form should not be closed. In my example I used OnDestroy which seems to be handled more gracefully. I'd suggest you to ask on the Lazarus list whether it is intentionally that you can't close a form of which the OnClose event handler raises an exception. This is also so in Delphi. Just tested. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
Giuliano Colla giuliano.co...@fastwebnet.it hat am 12. Februar 2013 um 13:29 geschrieben: [...] Why FormClose doesn't close the form in presence of an error (handled by a try..finally) when writing the ini file? Launching from command line, you have the same behavior, and an additional information when you select Cancel: WARNING: TLCLComponent.Destroy with LCLRefCount0. Hint: Maybe the component is processing an event? Try..except situation, from IDE and Debugger. Press the Close button. Debugger Notification. Pressing Continue my message dialog is shown. Pressing OK on my dialog the form is closed and the program is terminated. Launching from command line, no console messages. My conclusion is that one can't properly handle INI files with just a try..finally construct, as all examples show, because a possible error will propagate outside the construct, with unpredictable effects (in this case the FormClose procedure doesn't properly complete). The LCL has a default exception handler, so that the application notifies the user, that the application has a bug instead of simply crashing and vanishing silently. The programmr is reponsible to handle exceptions, show the user error messages and give the user choices (e.g. ignore, retry). BTW, the Ini.Free writes to disk, so it needs the try..except, the WriteValue calls do not need the try..except. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On Tue, 12 Feb 2013, Mattias Gaertner wrote: Giuliano Colla giuliano.co...@fastwebnet.it hat am 12. Februar 2013 um 13:29 geschrieben: [...] Why FormClose doesn't close the form in presence of an error (handled by a try..finally) when writing the ini file? Launching from command line, you have the same behavior, and an additional information when you select Cancel: WARNING: TLCLComponent.Destroy with LCLRefCount0. Hint: Maybe the component is processing an event? Try..except situation, from IDE and Debugger. Press the Close button. Debugger Notification. Pressing Continue my message dialog is shown. Pressing OK on my dialog the form is closed and the program is terminated. Launching from command line, no console messages. My conclusion is that one can't properly handle INI files with just a try..finally construct, as all examples show, because a possible error will propagate outside the construct, with unpredictable effects (in this case the FormClose procedure doesn't properly complete). The LCL has a default exception handler, so that the application notifies the user, that the application has a bug instead of simply crashing and vanishing silently. The programmr is reponsible to handle exceptions, show the user error messages and give the user choices (e.g. ignore, retry). BTW, the Ini.Free writes to disk, so it needs the try..except, the WriteValue calls do not need the try..except. That depends. if you disabled write caching, every write call will update the file. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
Giuliano Colla wrote: On 02/12/2013 10:02 AM, Mark Morgan Lloyd wrote: I admit that I was slightly trolling there, since Giuliano was complaining about exceptions that he wasn't seeing (because, it turns out, he wasn't catching them). You catch an exception if you can handle it. If a user for some reasons has write-protected a configuration file, there's nothing the application can do about it. One can usually rely on the system default exception handler to show the error message. If it doesn't happen, then there's something wrong somewhere. Yes, but the point that I'm trying to get across is that the earlier you make sure that you've got full access to the files (i.e. all directories in the path exist, the file either exists and is writable or you create it from a template) the easier you make life for yourself. If having the file is absolutely essential then check for it before you even open the main form and bomb if it's obvious that there's a problem. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 02/12/2013 01:58 PM, Mattias Gaertner wrote: The LCL has a default exception handler, so that the application notifies the user, that the application has a bug instead of simply crashing and vanishing silently. The programmr is reponsible to handle exceptions, show the user error messages and give the user choices (e.g. ignore, retry). That's what I was relying on. There's nothing the application can do if a user has write-protected the configuration files, or if there's a disk error while writing (I didn't think of a non existing .config/, because I've always found it there, before the last episode). So I was just happy with a system error, which in this case fails to show. As an additional information: in FormClose ini := TIniFile.Create(BadAppConfigFileName); try ini.WriteWhatever(... ... except on E: Exception do Application.ShowException(E); end; shows the error only on the console, but no visual dialog. While on E: Exception do MessageDlg(E.Message,mtError,[mbOk],0); shows a proper message dialog. Maybe this discussion should be moved to Lazarus list? Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 02/12/2013 02:46 PM, Mark Morgan Lloyd wrote: Giuliano Colla wrote: On 02/12/2013 10:02 AM, Mark Morgan Lloyd wrote: I admit that I was slightly trolling there, since Giuliano was complaining about exceptions that he wasn't seeing (because, it turns out, he wasn't catching them). You catch an exception if you can handle it. If a user for some reasons has write-protected a configuration file, there's nothing the application can do about it. One can usually rely on the system default exception handler to show the error message. If it doesn't happen, then there's something wrong somewhere. Yes, but the point that I'm trying to get across is that the earlier you make sure that you've got full access to the files (i.e. all directories in the path exist, the file either exists and is writable or you create it from a template) the easier you make life for yourself. If having the file is absolutely essential then check for it before you even open the main form and bomb if it's obvious that there's a problem. That's the point. The configuration file in this application is useful but not essential. It holds fine calibration data for a set of remote sensors. If you can't read it, you must click again on the Calibrate button a number of times, to display more precise values. One could even chose to write-protect it, to avoid overwriting a good calibration. It's not a DataBase application where if you don't set the right hostname, user and password you can't do a thing. That's why I would have been perfectly happy with a default system error box telling write error, or whatever, just to let know that the data have not been saved. What happens on the contrary is that, in case of failure, no error is shown, and, what's more annoying, that the form can't be closed, which can be quite confusing for a normal user. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Tree structure
On Tue, 12 Feb 2013, Leonardo M. Ramé wrote: Hi, I would like to know if there's a standard tree structure where each node is a TObject. With standard I mean, in a standard package, like fcl-base. there is one in the generics. But not as a regular class. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Tree structure
On 2013-02-12 16:13, Leonardo M. Ramé wrote: Hi, I would like to know if there's a standard tree structure where each node is a TObject. With standard I mean, in a standard package, like fcl-base. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal FCL_base does have one: avl_tree but so does LCL, which is named AvgLvlTree (found in LazUtils) I hope that helps... ;) Kind regards, Torsten Bonde Christiansen. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Tree structure
On Tue, 12 Feb 2013, Torsten Bonde Christiansen wrote: On 2013-02-12 16:13, Leonardo M. Ramé wrote: Hi, I would like to know if there's a standard tree structure where each node is a TObject. With standard I mean, in a standard package, like fcl-base. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal FCL_base does have one: avl_tree Does not allow multiple children, only left/right, no ? Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Tree structure
On 2013-02-12 16:36, Michael Van Canneyt wrote: On Tue, 12 Feb 2013, Torsten Bonde Christiansen wrote: On 2013-02-12 16:13, Leonardo M. Ramé wrote: Hi, I would like to know if there's a standard tree structure where each node is a TObject. With standard I mean, in a standard package, like fcl-base. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal FCL_base does have one: avl_tree Does not allow multiple children, only left/right, no ? Michael. True - but the original question gives no hint to whether this is desired or not... :) -Torsten. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Tree structure
From: Michael Van Canneyt mich...@freepascal.org To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Sent: Tuesday, February 12, 2013 12:36 PM Subject: Re: [fpc-pascal] Tree structure On Tue, 12 Feb 2013, Torsten Bonde Christiansen wrote: On 2013-02-12 16:13, Leonardo M. Ramé wrote: Hi, I would like to know if there's a standard tree structure where each node is a TObject. With standard I mean, in a standard package, like fcl-base. Leonardo M. Ramé http://leonardorame.blogspot.com FCL_base does have one: avl_tree Does not allow multiple children, only left/right, no ? Michael. Isn't that a balanced binary tree? I'm looking for a simple tree structure (http://en.wikipedia.org/wiki/Tree_%28data_structure%29) Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Tree structure
- Original Message - From: Michael Van Canneyt mich...@freepascal.org To: Leonardo M. Ramé martinr...@yahoo.com; FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Cc: Sent: Tuesday, February 12, 2013 12:28 PM Subject: Re: [fpc-pascal] Tree structure On Tue, 12 Feb 2013, Leonardo M. Ramé wrote: Hi, I would like to know if there's a standard tree structure where each node is a TObject. With standard I mean, in a standard package, like fcl-base. there is one in the generics. But not as a regular class. Michael Which one?. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Tree structure
On 2013-02-12 15:44, Leonardo M. Ramé wrote: Isn't that a balanced binary tree? I'm looking for a simple tree structure (http://en.wikipedia.org/wiki/Tree_%28data_structure%29) It should be rather simple to create. A simple Composite design pattern and about 30-45 minutes with some accompanied unit tests, and you should have everything you want. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Tree structure
- Original Message - From: Leonardo M. Ramé martinr...@yahoo.com To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Cc: Sent: Tuesday, February 12, 2013 12:45 PM Subject: Re: [fpc-pascal] Tree structure - Original Message - From: Michael Van Canneyt mich...@freepascal.org To: Leonardo M. Ramé martinr...@yahoo.com; FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Cc: Sent: Tuesday, February 12, 2013 12:28 PM Subject: Re: [fpc-pascal] Tree structure On Tue, 12 Feb 2013, Leonardo M. Ramé wrote: Hi, I would like to know if there's a standard tree structure where each node is a TObject. With standard I mean, in a standard package, like fcl-base. there is one in the generics. But not as a regular class. Michael Which one?. Well, I think TAvlTree fits the bill. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Tree structure
On 12.02.2013 16:44, Leonardo M. Ramé wrote: From: Michael Van Canneyt mich...@freepascal.org To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Sent: Tuesday, February 12, 2013 12:36 PM Subject: Re: [fpc-pascal] Tree structure On Tue, 12 Feb 2013, Torsten Bonde Christiansen wrote: On 2013-02-12 16:13, Leonardo M. Ramé wrote: Hi, I would like to know if there's a standard tree structure where each node is a TObject. With standard I mean, in a standard package, like fcl-base. Leonardo M. Ramé http://leonardorame.blogspot.com FCL_base does have one: avl_tree Does not allow multiple children, only left/right, no ? Michael. Isn't that a balanced binary tree? I'm looking for a simple tree structure (http://en.wikipedia.org/wiki/Tree_%28data_structure%29) You could take a look at $fpcdir/packages/fcl-stl/gtree.pp (only in 2.7.1). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Compiled program is a virus (seems to be internallinker problem)
On 12.02.2013 19:10, waldo kitty wrote: On 2/12/2013 06:18, Lukasz Sokol wrote: On 11/02/2013 23:19, Gerhard Scholz wrote: I switched to AVAST free Antivirus now, the problem does not occur here. This is not a pascal question, but maybe can give me a hint if AVAST is good or which software is more recommendable. (I do not really trust the tests I find in the internet because I do not know who pays them) I found myself recently quite comfortable using ZoneAlarm. apples and oranges... one is an anti-virus product and the other a firewall ;) No one forbids those growing apple trees to grow orange trees as well: http://www.zonealarm.com/security/en-us/zonealarm-free-antivirus-firewall.htm Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Compiled program is a virus (seems to be internallinker problem)
At 01:31 PM 2/12/2013, Sven Barth wrote: On 12.02.2013 19:10, waldo kitty wrote: On 2/12/2013 06:18, Lukasz Sokol wrote: On 11/02/2013 23:19, Gerhard Scholz wrote: I switched to AVAST free Antivirus now, the problem does not occur here. This is not a pascal question, but maybe can give me a hint if AVAST is good or which software is more recommendable. (I do not really trust the tests I find in the internet because I do not know who pays them) I found myself recently quite comfortable using ZoneAlarm. apples and oranges... one is an anti-virus product and the other a firewall ;) No one forbids those growing apple trees to grow orange trees as well: http://www.zonealarm.com/security/en-us/zonealarm-free-antivirus-firewall.htm Does it brew coffee and vacuum the floor as well? :-} Ralf ;-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Compiled program is a virus (seems to be internallinker problem)
On 12.02.2013 20:45, Ralf A. Quint wrote: At 01:31 PM 2/12/2013, Sven Barth wrote: On 12.02.2013 19:10, waldo kitty wrote: On 2/12/2013 06:18, Lukasz Sokol wrote: On 11/02/2013 23:19, Gerhard Scholz wrote: I switched to AVAST free Antivirus now, the problem does not occur here. This is not a pascal question, but maybe can give me a hint if AVAST is good or which software is more recommendable. (I do not really trust the tests I find in the internet because I do not know who pays them) I found myself recently quite comfortable using ZoneAlarm. apples and oranges... one is an anti-virus product and the other a firewall ;) No one forbids those growing apple trees to grow orange trees as well: http://www.zonealarm.com/security/en-us/zonealarm-free-antivirus-firewall.htm Does it brew coffee and vacuum the floor as well? :-} I so hope not... Note: If anyone wants to answer to this anti virus thread that was off topic to begin with, we should move over to fpc-other. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] download link on viewvc pages is missing
Hi, the (download) link (together with the (as text)) link that used to be next to (view) and (annotate) in viewvc revisions logs are missing, can this be enabled, please? Jesus Reyes A. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
Am 12.02.2013 um 13:29 schrieb Giuliano Colla:
I've made some further experiments with my minimal test.
Test form is just a Form with a Close button (BitBtn Kind=bkClose).
The full code is the following:
unit uinitfile;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs,
Buttons,IniFiles;
type
{ TForm1 }
TForm1 = class(TForm)
BitBtn1: TBitBtn;
procedure FormClose(Sender: TObject; var CloseAction: TCloseAction);
procedure FormCreate(Sender: TObject);
private
{ private declarations }
public
{ public declarations }
end;
var
Form1: TForm1;
ini: TIniFile;
AppConfigFileName: string;
SomeData: boolean;
SomeOtherData: boolean;
implementation
{$R *.lfm}
{ TForm1 }
procedure TForm1.FormCreate(Sender: TObject);
begin
AppConfigFileName:= '/not/existing/path/inifile.cfg';
ini := TIniFile.Create(AppConfigFileName);
try
SomeData:= ini.ReadBool('Section','Val',true);
SomeOtherData:= ini.ReadBool('Section','Val1',true);
finally
ini.Free;
end;
end;
procedure TForm1.FormClose(Sender: TObject; var CloseAction: TCloseAction);
begin
ini:= TIniFile.Create(AppConfigFileName);
{$DEFINE Finally}
{$IFDEF Finally}
try
ini.WriteBool('Section','Val',SomeData);
ini.WriteBool('Section','Val1',SomeOtherData);
finally
ini.Free;
end;
{$ELSE}
try
ini.WriteBool('Section','Val',SomeData);
ini.WriteBool('Section','Val1',SomeOtherData);
except
MessageDlg('Error while writing '+AppConfigFileName,mtError,[mbOK],0);
end;
ini.Free;
{$ENDIF}
end;
end.
I'm not sure if somebody else mentioned this already but I have the feeling
that Giuliano thinks that he has to decide to use try-finally OR try-except but
there are situations where you need both. One of the criteria is if the object
is local or global since for a global object it is likely that you place the
.Free (or for a global object better FreeAndNil()) into a destructor or
finalization section (which means that you have to stop the program in case of
an error and not continue showing just a dialog) so you'll need only the
try-except if you want to catch the exception. In case of a local object you'll
ALWAYS have the lines
Obj := Class.Create;
try
// do some code
finally
Obj.Free;
end;
otherwise you'll end up with memory leaks.
If you want to catch the exception in this situation you'll put try-except
extra around try-finally so you'll end up with
Obj := Class.Create;
try
try
// do some code
finally
Obj.Free;
end;
except
writeln('We have a problem);
halt the program or reraise the exception or raise a new one
end;
Regards
Michael___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
