> It's fun to make kids, but no fun to have them afterwards ;-]
that was my thought exactly... and as a coder, i also know that i'd much rather
write code than docs... i won't even speak about docs that "the average joe"
can
understand regardless of their coding experience ;) some would call do
En/na Hans-Peter Diettrich ha escrit:
>
> Insert your exception handler in an more appropriate place, depending on
> the concrete application. The user can expect a diagnosis of what went
> wrong, and a chance for correcting his preceding input.
For data aware components (and probably for othe
Hans-Peter Diettrich wrote:
> Felipe Monteiro de Carvalho schrieb:
>
>> We are writting a book about it, but it's not yet ready ...
>>
>
> How can I contribute?
>
> DoDi
>
>
I, too, would like to contribute.
Chris
___
Lazarus mailing list
La
On Mon, 16 Mar 2009, Hans-Peter Diettrich wrote:
> Michael Van Canneyt schrieb:
>
> > Is there a reason why the default exception dialog has a cancel
> > button to kill the application ?
>
> An unhandled exception IMO is due to some software bug, which the user
> cannot cure in any way.
Tha
but i made it with lazarus under windows.
and i could not use customdraw method to draw anything.
> >
> > lv's viewstyle is vsReport,and i was going to place a progressbar on a
> > column,and that is what a downloader usually looks like.
> It is not possible to place a TProgressbar in a listview.
Michael Van Canneyt wrote:
>
> On Mon, 16 Mar 2009, Hans-Peter Diettrich wrote:
>
>> Michael Van Canneyt schrieb:
>>
>>> Is there a reason why the default exception dialog has a cancel
>>> button to kill the application ?
>> An unhandled exception IMO is due to some software bug, which the user
Michael Van Canneyt schrieb:
>> An unhandled exception IMO is due to some software bug, which the user
>> cannot cure in any way.
>
> That's a very restrictive definition of exception. An exception is
> a way to stop the normal logic and flow of the program.
ACK. And try-except clauses are the
On Tue, Mar 17, 2009 at 10:38 AM, Michael Van Canneyt
wrote:
>
> Borland explains this use in detail in chapter 14 of the Delphi 7
> manual.
Or chapter 13 in the Kylix 3 Developers Guide. ;-)
[...at least I still have one use for Kylix... It's help files and
documentation.]
Regards,
- Graeme
Michael Van Canneyt wrote:
> On Mon, 16 Mar 2009, Hans-Peter Diettrich wrote:
>
>
>> Michael Van Canneyt schrieb:
>>
>>
>>> Is there a reason why the default exception dialog has a cancel
>>> button to kill the application ?
>>>
>> An unhandled exception IMO is due to some software
Luca Olivetti wrote:
> En/na Hans-Peter Diettrich ha escrit:
>
>
>> Insert your exception handler in an more appropriate place, depending on
>> the concrete application. The user can expect a diagnosis of what went
>> wrong, and a chance for correcting his preceding input.
>>
>
> For data
On Tue, 17 Mar 2009, Martin Friebe wrote:
> Luca Olivetti wrote:
> > En/na Hans-Peter Diettrich ha escrit:
> >
> >
> >> Insert your exception handler in an more appropriate place, depending on
> >> the concrete application. The user can expect a diagnosis of what went
> >> wrong, and a chan
On Tue, 17 Mar 2009, Martin Friebe wrote:
> Michael Van Canneyt wrote:
> > On Mon, 16 Mar 2009, Hans-Peter Diettrich wrote:
>
> "In a GUI application, you rely on the program's event loop"
> Well, in my very personal opinion: This is just a bad design idea. If I
> throw an exception, I wr
Michael Van Canneyt wrote:
>> If a component throws an exception outside any call from your code
>> (which you can place in a "try except end"), a place like OnDataReceived
>> which is triggered automatically, then this component has a bug (IMHO).
>> The component *should* have something like an
Please note, I don't use db-aware components, but here follows the
help from Kylix 3.
On Tue, Mar 17, 2009 at 3:46 PM, Martin Friebe wrote:
>
> I have to admit, I have limited knowledge of the exact details of the
> data-aware components, and rather was making a general case about my
> perception
On Tue, Mar 17, 2009 at 3:46 PM, Martin Friebe wrote:
> Anyway, the point is, if we are looking at the original source of the
> discussion (the build-in exception dialog) => that is at best the most
> limited case of handling an exception (It is simply displaying it). It
> does not check any need
Michael Van Canneyt schrieb:
> In the OnValidate event of a TField, you are supposed to throw an exception
> to stop the user from entering wrong data in the field. This exception can
> only be caught by the program event loop. This is so by design, and the
> recommended way by Borland.
Even Bo
Martin Friebe schrieb:
> If a component throws an exception outside any call from your code
> (which you can place in a "try except end"), a place like OnDataReceived
> which is triggered automatically, then this component has a bug (IMHO).
ACK. Asynchronous operations never should throw excep
Graeme Geldenhuys wrote:
> Please note, I don't use db-aware components, but here follows the
> help from Kylix 3.
>
> On Tue, Mar 17, 2009 at 3:46 PM, Martin Friebe wrote:
>
>> I have to admit, I have limited knowledge of the exact details of the
>> data-aware components, and rather was making
On Tue, 17 Mar 2009, Martin Friebe wrote:
> Graeme Geldenhuys wrote:
> > Please note, I don't use db-aware components, but here follows the
> > help from Kylix 3.
> >
> > On Tue, Mar 17, 2009 at 3:46 PM, Martin Friebe wrote:
> >
> >> I have to admit, I have limited knowledge of the exact det
Michael Van Canneyt wrote:
> On Tue, 17 Mar 2009, Martin Friebe wrote:
>
>>> To reject the current value of the field from the OnValidate event
>>> handler, raise an exception.
>>>
>>>
>>>
>> Then to me the Delphi/Kylix implementation is flawed. Because it forces
>> me to do TWO thing
On Tue, 17 Mar 2009, Martin Friebe wrote:
> Michael Van Canneyt wrote:
> > On Tue, 17 Mar 2009, Martin Friebe wrote:
> >
> >>> To reject the current value of the field from the OnValidate event
> >>> handler, raise an exception.
> >>>
> >>>
> >>>
> >> Then to me the Delphi/Kylix imp
Hello:
A little off-topic and probably just a stupid idea.
I have wondered many times why there are two different sentences to
handle an exception and to clean objects etc. I have missed many times
in database work.
I mean:
try
try
..
except
end;
finally
end;
It would clean
On Tue, 2009-03-17 at 19:16 +0100, svaa wrote:
> A little off-topic and probably just a stupid idea.
Not a stupid idea. It is what the Python grammar permits for exception
handling.
It seems to be a limitation of the Object Pascal grammar -- and a wholly
unnecessary one at that.
Since introduci
Try this
LCL:
http://lazarus-ccr.sourceforge.net/docs/lcl/lclversion/index.html
Compiler:
http://lazarus-ccr.sourceforge.net/fpcdoc/prog/progsu38.html#x45-430001.1.38
2009/3/16 Brad Campbell :
> G'day all,
>
> When I'm compiling an app I can include all my fpc details with {$I
> %Rhubarb%}.
>
>
svaa schrieb:
> It would cleaner if it could be written:
>
> try
>..
> except
>
> finally
>
> end;
There was such a discussion in a Delphi group, some time ago. I don't
remember the arguments, but finally the consens was *not* to combine
except and finally into one try block.
Do
Bram Kuijvenhoven wrote:
> Thank you. I don't have a Sybase server or even a Sybase ODBC driver here,
> but after modifying your code to connect to a MySQL server that I have
> running, I also got an exception (an Access Violation actually).
>
> However, when I use the SQLDB and ODBConn units fr
Why can't we (FPC) support all of it? I have absolutely no idea what the
implications would be...
You could have it only available with certain compiler directives,
defaulting to not supporting it?
On Tue, Mar 17, 2009 at 9:23 PM, Hans-Peter Diettrich
wrote:
> svaa schrieb:
>
> > It would clean
This thread would be better located at one of the Free Pascal mailling lists.
--
Felipe Monteiro de Carvalho
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
28 matches
Mail list logo
