Right you are! And if I had written the app, that's how it would work.
But right now it's more expedient for me to fix error reporting than to
go through the system (it's really a set of apps) and change untold
dozens of data entry points.
Thanks Craig -
Phil
[email protected] wrote:
It seems far more important, and far easier in the long run, to validate
entry data before it gets anywhere close to being mishandled. Check to see if
numbers are numbers, dates are dates, etc. I would bet that the errors fall
into a very few categories, and these can all be screened early on.
Many newbie (ahem) error posts are of just this type, for example, an
errant char in the second line of a field, and only the first line is visible,
where the contents of the field has some math done to it. So another level of
checking that I use all the time is to act only on line 1 of the field that
purportedly has valid data in it. But even this should really be vetted at
entry time.
Craig Newman
In a message dated 6/10/09 4:34:53 PM, [email protected] writes:
I help maintain some software whose users can sometimes generate an
error by entering malformed data in a given field (e.g. non-numeric
data where math is done after data is moved into temp variables).
What I'm looking for is some code that displays the contents of the
variables containing malformed data. However, the error handling
code is in a libraried stack so I assume I can't just "get the
variableNames" from there and work with those, since the error
occurred in the script of a different stack.
--
Phil Davis
PDS Labs
Professional Software Development
http://pdslabs.net
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
