On Mon, 11 Feb 2013, Giuliano Colla wrote:
3) But if also the *path* to the file doesn't yet exist, it just crashes
without rising an exception that the user application can handle somehow.
This is incorrect. It does tell you why it fails.
This is rather unpleasant, because the path provi
On 2/10/13, Michael Van Canneyt wrote:
> You expect wrong. No supposition is made whatsoever on the value.
> Every write in the list triggers a change.
>
> This is how delphi implements it, and that is how we implemented it.
That's why I mentioned I might be horribly wrong.
So Delphi compatibili
Il 11/02/2013 09:21, Michael Van Canneyt ha scritto:
On Mon, 11 Feb 2013, Giuliano Colla wrote:
3) But if also the *path* to the file doesn't yet exist, it just
crashes without rising an exception that the user application can
handle somehow.
This is incorrect. It does tell you why it fail
On Mon, 11 Feb 2013, Bart wrote:
On 2/10/13, Michael Van Canneyt wrote:
You expect wrong. No supposition is made whatsoever on the value.
Every write in the list triggers a change.
This is how delphi implements it, and that is how we implemented it.
That's why I mentioned I might be horr
On Mon, 11 Feb 2013, Giuliano Colla wrote:
Il 11/02/2013 09:21, Michael Van Canneyt ha scritto:
On Mon, 11 Feb 2013, Giuliano Colla wrote:
3) But if also the *path* to the file doesn't yet exist, it just crashes
without rising an exception that the user application can handle somehow.
T
Giuliano Colla wrote:
However, what I've learned from this episode is that while attempting to
save configuration data using TINIFile on program termination you should
never use a try..finally construct, as it's suggested everywhere, but
rather a try..except (or both). Otherwise you'll never b
Il 11/02/2013 12:40, Mark Morgan Lloyd ha scritto:
Giuliano Colla wrote:
However, what I've learned from this episode is that while attempting
to save configuration data using TINIFile on program termination you
should never use a try..finally construct, as it's suggested
everywhere, but rath
Il 11/02/2013 12:35, Michael Van Canneyt ha scritto:
On Mon, 11 Feb 2013, Giuliano Colla wrote:
Il 11/02/2013 09:21, Michael Van Canneyt ha scritto:
On Mon, 11 Feb 2013, Giuliano Colla wrote:
3) But if also the *path* to the file doesn't yet exist, it just
crashes without rising an excep
Am 11.02.2013 13:06, schrieb Giuliano Colla:
Il 11/02/2013 12:35, Michael Van Canneyt ha scritto:
On Mon, 11 Feb 2013, Giuliano Colla wrote:
Il 11/02/2013 09:21, Michael Van Canneyt ha scritto:
On Mon, 11 Feb 2013, Giuliano Colla wrote:
3) But if also the *path* to the file doesn't yet e
On 2013-02-11 11:29, Giuliano Colla wrote:
>
> This is true only if you invoke the program from command line, which is
> something the end user will never do.
Wrong. This is something you are doing wrong in your GUI application
then. I have loads of fpGUI 'gui' applications, that report excepti
On Mon, 11 Feb 2013, Giuliano Colla wrote:
This is true only if you invoke the program from command line, which is
something the end user will never do.
That is not the problem of TIniFile, but of the application programmer.
TIniFile properly reports any error, as it should, with an excep
On 2/11/13, Michael Van Canneyt wrote:
> I am aware of this.
>
> But the impact of changing it is impossible to guess, so it is not
> subject to change.
>
Which is fine by me.
I just wondered, and now I'm informed...
And with that new knowledge I can improve my code.
Thanks.
Bart
_
On Mon, 11 Feb 2013, Bart wrote:
On 2/11/13, Michael Van Canneyt wrote:
I am aware of this.
But the impact of changing it is impossible to guess, so it is not
subject to change.
Which is fine by me.
I just wondered, and now I'm informed...
And with that new knowledge I can improve my co
Giuliano Colla wrote:
Il 11/02/2013 12:40, Mark Morgan Lloyd ha scritto:
Giuliano Colla wrote:
However, what I've learned from this episode is that while attempting
to save configuration data using TINIFile on program termination you
should never use a try..finally construct, as it's suggeste
On 02/11/2013 01:57 PM, Michael Van Canneyt wrote:
On Mon, 11 Feb 2013, Giuliano Colla wrote:
It can be helped both by reducing the likelihood of the event, as
you've done, and by not suggesting to use in that case a try..finally
construct in a GUI application, which would mask the errors.
Th
On 02/11/2013 01:34 PM, Graeme Geldenhuys wrote:
On 2013-02-11 11:29, Giuliano Colla wrote:
This is true only if you invoke the program from command line, which is
something the end user will never do.
Wrong. This is something you are doing wrong in your GUI application
then. I have loads of f
Lost in the shuffle, wasn't this originally found in Lazarus? Sounds like
a bug report for incorrect handling of INI files when the config directory
is missing needs to be filed in their bug tracker.
Jeff.
___
fpc-pascal maillist - fpc-pascal@lists.fr
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.
On 11.02.2013 13:18, Sven Barth wrote:
Am 11.02.2013 13:06, schrieb Giuliano Colla:
Il 11/02/2013 12:35, Michael Van Canneyt ha scritto:
On Mon, 11 Feb 2013, Giuliano Colla wrote:
Il 11/02/2013 09:21, Michael Van Canneyt ha scritto:
On Mon, 11 Feb 2013, Giuliano Colla wrote:
3) But if
On Mon, 11 Feb 2013 17:02:39 +0100
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 docume
On 11.02.2013 17:16, Mattias Gaertner wrote:
On Mon, 11 Feb 2013 17:02:39 +0100
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 :-)
An
On 02/11/2013 04:45 PM, DaWorm wrote:
Lost in the shuffle, wasn't this originally found in Lazarus? Sounds
like a bug report for incorrect handling of INI files when the config
directory is missing needs to be filed in their bug tracker.
INI files and related stuff are part of the fcl libra
On Mon, Feb 11, 2013 at 1:48 PM, Giuliano Colla <
giuliano.co...@fastwebnet.it> wrote:
> On 02/11/2013 04:45 PM, DaWorm wrote:
>
>> Lost in the shuffle, wasn't this originally found in Lazarus? Sounds
>> like a bug report for incorrect handling of INI files when the config
>> directory is missing
On 02/11/2013 05:12 PM, Sven Barth wrote:
On 11.02.2013 13:18, Sven Barth wrote:
Am 11.02.2013 13:06, schrieb Giuliano Colla:
Il 11/02/2013 12:35, Michael Van Canneyt ha scritto:
On Mon, 11 Feb 2013, Giuliano Colla wrote:
Il 11/02/2013 09:21, Michael Van Canneyt ha scritto:
On Mon, 11 F
On 11.02.2013 21:10, Giuliano Colla wrote:
I don't see why the extra code should create a problem, but, by adding
one piece after the other I should be able to find out where the problem
comes from. However, replacing the original try..finally with a
try..except, the main application behaves prop
Platform: Win32, FPC2.7.1, Virusscanner Avira Free Antivirus
The compiled program is assumed to be a virus.
Name:TR/Crypt.XPACK.Gen2 (according to Avira, shall be a trojan)
Compile line:
ppc386 -vv -al -CioOrt -Cs600-gclt -Mobjfpc -O1 -OpPENTIUM
With the external linker ( -Xe ) t
Am 11.02.2013 21:22, schrieb Gerhard Scholz:
> Platform: Win32, FPC2.7.1, Virusscanner Avira Free Antivirus
>
> The compiled program is assumed to be a virus.
>
> Name:TR/Crypt.XPACK.Gen2 (according to Avira, shall be a trojan)
>
> Compile line: ppc386 -vv -al -CioOrt -Cs600-gclt -Mo
On 11/02/2013 20:22, Gerhard Scholz wrote:
Platform: Win32, FPC2.7.1, Virusscanner Avira Free Antivirus
The compiled program is assumed to be a virus.
Name:TR/Crypt.XPACK.Gen2 (according to Avira, shall be a trojan)
Compile line: ppc386 -vv -al -CioOrt -Cs600-gclt -Mobjfpc
-O1 -Op
@Martin:
Compile line: ppc386 -vv -al -CioOrt -Cs600 -Mobjfpc -O1 -OpPENTIUM
(dropping the -gclt) helped.
It seems you were right.
Gerhard
- Original Message -
From: "Martin"
To: "FPC-Pascal users discussions"
Sent: Monday, February 11, 2013 10:08 PM
Subject: Re: [fpc-pascal] C
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
-
30 matches
Mail list logo
