My machine crashed at the time I was trying to post this last night *grumbling at the class browser*
>Yeah. This is just about how my ON ERROR procedure interface looks right now. I presume 'this' is the handle you use to determine the context in which the error occured and thereby customize the handling of the error. At runtime, is it possible to use 'this' to derive THISFORM and/or other objects which are further up the execution control hierarchy. For example, right now I pass the variable pcErr to my ON ERROR routine which determines its response based on the value of pcErr. At key points in a procedure, I set the value of pcErr to correspond to 'the current state of processing'. Is that how you use 'this'? ;-)
this is a reference to the object that has had the error. ObjError() can then do whatever it wants with that object. It could walk the .parent containership hierarchy etc.
>Also, more generally, are there other attributes that you've built into your own baseclasses that you find apply to just about any project? Error handling is a natural, and I'm thinking the same thing about environment variable initialization. Anything else?
I don't have much in my first level classes.
cLabel - sets AutoSize = .t., BackStyle = transparent cCheckbox sets .Value = .f. so it can be tested as a logical everywhere, I added a mlReadOnly flag to make it really readonly inside a grid cCombobox - I save/alter/restore _DBLCLICK in GotFocus/LostFocus, Added an array property and methods like SQL and GetArray to support lookups. cForm - does a whole pile of stuff cOptionGroup - propogates Enabled and BackStyle down through the buttons cPageFrame - adds one of my PageRefresher object to each page cSpinner - has code in LostFocus so Keyboarded values stay within the SpinnerHi/Lo values cTextBox - has code in KeyPress to prevent backspace from exiting the control, GotFocus does some mouse based SelectOnEntry logic
