Re: [Lazarus] Where are the manuals?
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 docs that i've written technical docs but i've had many long time coders write to me for explanations of the docs and the code given :| -- NOTE: NEW EMAIL ADDRESS!! _\/ (@@) Waldo Kitty, Waldo's Place USA __ooO_( )_Ooo_ telnet://bbs.wpusa.dynip.com _|_|_|_|_|_|_ http://www.wpusa.dynip.com |_|_|_|_|_| ftp://ftp.wpusa.dynip.com _|_Eat_SPAM_to_email_me!_YUM!__|_ wkitty42 -at- windstream.net ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
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 others too), Application.OnException is the only place, otherwise you cannot trap exception that are no caused by your program flow but by intrinsic processing by the component (e.g. during post the database could reject the data due to failed constraints, you could trap BeforePost or AfterPost but not DuringPost). Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 (Ext.133) Fax +34 93 5883007 ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Where are the manuals?
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 Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
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. That's a very restrictive definition of exception. An exception is a way to stop the normal logic and flow of the program. In a GUI application, you rely on the program's event loop to catch the exception (so it is definitely handled) and to show it to the user. If you don't want it to be shown, use the Abort exception. Borland explains this use in detail in chapter 14 of the Delphi 7 manual. Michael. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Unable to use method AdvancedCustomDrawItem and, AdvancedCustomDrawSubItem
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. (item.data does nothing, it's for user defined data independent of the LCL) What you have have to do is to draw a own bar, e.g. with two or more rectangles (see canvas) Benito ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
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 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. In a GUI application, you rely on the program's event loop to catch the exception (so it is definitely handled) and to show it to the user. If you don't want it to be shown, use the Abort exception. Borland explains this use in detail in chapter 14 of the Delphi 7 manual. while i tend to agree wholeheartedly with both side, i have to suppress a LOL at the last statement because this ain't borland's code or definition of pascal in any flavo(u)r... this is FPC's definition and even moreso, lazarus' definition at least as far as lazarus is concerned with the code that it compiles ;) hopefully that's taken in the spirit it is offered from an old TP2/TP3 coder :) -- NOTE: NEW EMAIL ADDRESS!! _\/ (@@) Waldo Kitty, Waldo's Place USA __ooO_( )_Ooo_ telnet://bbs.wpusa.dynip.com _|_|_|_|_|_|_ http://www.wpusa.dynip.com |_|_|_|_|_| ftp://ftp.wpusa.dynip.com _|_Eat_SPAM_to_email_me!_YUM!__|_ wkitty42 -at- windstream.net ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
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 way to catch exceptions. In a GUI application, you rely on the program's event loop to catch the exception I never did so, for my own or otherwise expected exceptions. (so it is definitely handled) and to show it to the user. If you don't want it to be shown, use the Abort exception. Please don't confuse exception catching and handling. Only catching exceptions can (mostly will) leave the application in an invalid state, so that an abort is the only reasonable handling. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
On Tue, Mar 17, 2009 at 10:38 AM, Michael Van Canneyt mich...@freepascal.org 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 - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
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 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. In a GUI application, you rely on the program's event loop to catch the exception (so it is definitely handled) and to show it to the user. If you don't want it to be shown, use the Abort exception. there is a different between an unhandled exception and an exception An exception is indeed a very valid thing, that can and maybe should occur within many applications. But any exception should have some code, that handles it. And this handling code should not be the build-in Lazarus-exception dialog. Because the build-in dialog does not know what the exception meant and what should be done. It could not clean-up, it could not make sure that any memory allocated and referred only by local variables is freed. So an *unhanded* exception is a software bugs. an unhandled exception in most languages will simply crash the application. The fact that a Lazarus app does ask the user, if he wants to try and continue (and maybe be able to save his work) is a benefit. But never the less ending up there is a bug. The user doesn't know if he hit an exception for which the programmer intended to fall back on the build-in dialog (and therefore that the app will still run stable); or if this was an exception the programmer did not foresee, and the app will no be unstable, more exceptions may happen, data be corrupted. 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 write a handler for it. Best regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
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 OnError event on which it can call your code. Or it should have a flag/state, on which it said that an error occurred. An Exception may be, if an OnError event is provided, but not assigned. Why ? 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. 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 of proper exception use. I just googled = can you point me to some documentation on it? Following you description, I have no problem if an OnValidate allows the code to use an exception to signal the component some-error state. IMHO the component should have a well defined behaviour on getting this exception. and IMHO the component should then handle it instead of passing it on (that may require the exception to be of a defined class, so the component knows that the exception is meant for the component) I wonder what the benefit of passing such an exception to the main-loop is? If I want to do anything else (anything except signalling the component / anything like informing the user): It would be far easier to do this where I detect the problem (in the OnValidate Method). Example: different TField.OnValidate may point do different onValidate handlers. each knows what to tell the user, and which options to present to the user. - If they throw an Exception to stop the Component from writing to the DB = fine - If they throw an exception, to have the mainloop handling the user-error = that would mean, they have to pack all the information required for error handling into the exception? Why bother, if you can handle the exception locally? There would be a benefit, if you want to handle exceptions from various OnValidate handlers in one place. Then you could use an exception-class that is not caught by the component. BUT then it was your decision that the exception should go to the main class. It would not be a default 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 for cleanup, or other actions, or user-help .. So then you would want to use Application.OnException or similar. The point with the build in dialog is. that even for Exceptions that have otherwise been handled (like try/finally) and that only need to be displayed. This should be done by your own code, or the Exception should in some other way be marked as handled, display needed only. Otherwise if you relay on the build-in dialog to do this work for you, you mix up 2 crucially different cases: 1) The just described display-only exception = which wants an OK button only 2) Any exception that occurs, that was not expected, and eaves the application potentially unstable. = Which should warn the user, to save his work, and quit the app asap. And that should display a terminate app now button ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
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 laza...@mfriebe.de 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 of proper exception use.
I just googled = can you point me to some documentation on it?
Following you description, I have no problem if an OnValidate allows the
code to use an exception to signal the component some-error state.
IMHO the component should have a well defined behaviour on getting this
exception.
==[ Kylix 3 help ]
OnValidate event (TField)
-
Occurs just before the data is written to the record buffer.
Delphi syntax:
property OnValidate: TFieldNotifyEvent;
C++ syntax:
__property TFieldNotifyEvent OnValidate = {read=FOnValidate, write=FOnValidate};
Description
Write an OnValidate event handler to validate changes made to the data
in the field, just before the data is written to the current record
buffer. The EditMask property allows validation of the data on a
character by character basis while it is being entered by the user.
OnValidate allows an application to validate the data as a whole.
When the value of a field component is assigned programmatically,
validation by the EditMask is bypassed, since there is no data-aware
control to enforce adherence to the mask. OnValidate allows an
application to validate such data before it is posted to the database
table.
To reject the current value of the field from the OnValidate event
handler, raise an exception.
When writing the value of a field to the current record buffer, the
following steps occur:
1. The OnValidate event handler is called to validate the data.
2. If the OnValidate event handler does not raise an exception, the
data is written to the current record buffer.
3. If writing the data does not raise an exception, the OnChange event
handler is called to allow a response to the change.
==
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
On Tue, Mar 17, 2009 at 3:46 PM, Martin Friebe laza...@mfriebe.de 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 for cleanup, or other actions, or user-help .. So then you would want to use Application.OnException or similar. In the case of the TField.OnValidate, I tend to agree with you. I would image that to stop the system from writing data to the db you need to raise a more specific exception like a custom EMyAppValidationError instead of simply Exception. That way you can display it correctly in the Application.OnException with a simple OK button. Anything else unknown can use the default dialog - which signifies that the system is now in a possible unstable state. For the latter, application termination is probably the best choice for the user. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
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 laza...@mfriebe.de 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 of proper exception use. I just googled = can you point me to some documentation on it? Following you description, I have no problem if an OnValidate allows the code to use an exception to signal the component some-error state. IMHO the component should have a well defined behaviour on getting this exception. ==[ Kylix 3 help ] OnValidate event (TField) - Occurs just before the data is written to the record buffer. . 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 things, even if I want to do only one of them. There should be: - an ExceptionClass TDataValitaionException (or whatever) which can be used to abort writing the data, but not defer error handling to the mainloop - any other exception, that aborts the write, and transfers error handling to the main loop There are usages for both scenarios, so they should both be possible. Best Regards Martin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] About try blocks
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
