Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

ISO Plugin: Yes, it's wonderful, but it could be yet more wonderful...

May
855
0
Charles, It's been my habit over all my years of writing code to do complete error checking and reporting of found errors in terms that a human being who is not a programmer can understand, and I'm actually somewhat obsessive about doing that. That means that in code that I write a message such as ISO8601 plugin: D:\ShowTimeNonFailure.btm [6] Invalid time "abc" is not acceptable to me; I don't want to see where the message is coming from ("ISO8601 plugin:"), the name of the .btm file where the error occurred and the line number on which the error occurred (no further comment needed), and I even want to supply the exact error text myself so that it is worded in terms that the user can fully understand (specifically the ultimate source of the data that is in error). Well as far as I can tell the ISO plugin fails on all three counts. Specifically, the .btm file "ShowInvalidTimeProcessingResults.btm":
Code:
@Echo Off
SetLocal
Set BadTime=abc
@Echo Bad Time: %BadTime
On Error MsgBox /M /S OK Error!!!
@Echo >&NUL: %@TimePlus[%BadTime,0]
EndLocal
Quit 0
and the results of executing it:
Code:
[D:\]ShowInvalidTimeProcessingResults
Bad Time: abc
ISO8601 plugin: D:\ShowInvalidTimeProcessingResults.btm [6]  Invalid time "abc"
Note that the "On Error" didn't "catch" the error, the error message was printed despite the redirection of the error stream to null, and, of course, that's really not the message I want the user to see in the first place.

So, two possible ways to fix this:

1. Let the plugin "report" errors in the same manner as TCC does itself in batch files, i.e., the actual error message being redirectable to NUL: or any place of the user's choosing and the error being catchable by an "On Error" statement.

2. If that's not really practical because of the basic underlying architecture of the TCC "plugin" capability (I have no idea whether or not that is the case), alternatively a function could be supplied that can validate times (a similar function for dates would also be useful) either just generically verifying times in either AM/PM format or in 24 hour format, or maybe a parameter that can be used to specify which format is wanted by the user, or even a result of the function that indicates which particular format the time was in if the time was, in fact, valid.

For the short term I'll write my own code to do this, but it would be really nice if the plugin did this for me (and other users).

BTW, just so it doesn't get "lost in the crowd", again the plugin is really wonderful, just not quite perfect yet.

- Dan
 
Well, "perfection is not a human option", though software can asymptotically approach it. Furthermore, for software used by many perfection is in the eye of the beholder - my requirements (or desires) may be [actually, definitely are] different from those of anyone else.

Regardless, I do agree with Dan that it should be possible to intercept all error messages prior to display to the ultimate user. I do not know why neither "on error" nor redirection of STDERR captured the message without actually displaying it. I am curious...

Furthermore, it is very useful to know WHY a parameter is invalid. I do support the idea of a function or set of functions which do nothing more than validate strings to be used for a particular category of parameters (date, time, date-and-time, etc.) in other functions, and if necessary report why invalid. The value of such a function could be zero (0) for valid input, and a list of non-zero values for invalid input, the list - of course - dependent on what the input should be. Undoubtedly internally you already have the basic elements of such a function - to generate the very message Dan objects to. So this request is essentially not much more than asking that your internal function would have an external interface. So much more code... for you, and less for our own work.
 
Charles, It's been my habit over all my years of writing code to do complete error checking and reporting of found errors in terms that a human being who is not a programmer can understand, and I'm actually somewhat obsessive about doing that. That means that in code that I write a message such as ISO8601 plugin: D:\ShowTimeNonFailure.btm [6] Invalid time "abc" is not acceptable to me; I don't want to see where the message is coming from ("ISO8601 plugin:"), the name of the .btm file where the error occurred and the line number on which the error occurred (no further comment needed)....

That's exactly what I want to see! The source, the location, and the nature of the error.... And of course it mirrors the way TCC itself reports errors, not by coincidence.

Well as far as I can tell the ISO plugin fails on all three counts. Specifically, the .btm file "ShowInvalidTimeProcessingResults.btm":
Code:
@Echo Off
SetLocal
Set BadTime=abc
@Echo Bad Time: %BadTime
On Error MsgBox /M /S OK Error!!!
@Echo >&NUL: %@TimePlus[%BadTime,0]
EndLocal
Quit 0

Regarding redirection of the error message from the function: We get this question from time to time, not always about plugins. It's not a plugin issue; you can see the same thing with internal functions:

Code:
echo %@diskfree[] >& nul:

What's going on is that the functions -- all variables, in fact -- are expanded before the redirection takes place. Otherwise, you couldn't use functions (variables, etc.) in the filename! There is a simple workaround: use parentheses to force the redirection before the command is expanded:

Code:
( echo %@diskfree[] ) >& nul:

As for ON ERROR, it doesn't trap custom error messages, i.e. negative return codes. I think it would be possible for it to work that way, but that's really for Rex to decide. (Whether it's possible, and whether it's desirable!) If you really want this, you'll have to submit a feature request to him. I'll be interested to hear what he has to say about the notion.

2. If that's not really practical because of the basic underlying architecture of the TCC "plugin" capability (I have no idea whether or not that is the case), alternatively a function could be supplied that can validate times (a similar function for dates would also be useful) either just generically verifying times in either AM/PM format or in 24 hour format, or maybe a parameter that can be used to specify which format is wanted by the user, or even a result of the function that indicates which particular format the time was in if the time was, in fact, valid.

We already have @ISDATE to validate dates. (Say that ten times fast.) An @ISTIME function wouldn't be hard to add. But how should it work? Should it just return 1 for "good" and 0 for "bad", as @ISDATE does, or should it returns info on the time supplied -- 12-hour vs. 24-hour, were seconds specified, were milliseconds specified...?
 
We already have @ISDATE to validate dates. (Say that ten times fast.) An @ISTIME function wouldn't be hard to add. But how should it work? Should it just return 1 for "good" and 0 for "bad", as @ISDATE does, or should it returns info on the time supplied -- 12-hour vs. 24-hour, were seconds specified, were milliseconds specified...?

No, @ISTIME should return 1 or 0, as @ISDATE does. If you want to indicate what components were specified, two new functions should be created:
@DATEPARTS and @TIMEPARTS which would return a bit-encoded number, each bit indicating that a component was specified. @DATEPARTS would have bits for year, month, and date; @TIMEPARTS would have bits for hour, minute, second, millisecond, and am/pm indicator (and maybe offset from UTC). (And that would allow detection of a partial date, like 31-Dec.)
 
No, @ISTIME should return 1 or 0, as @ISDATE does. If you want to indicate what components were specified, two new functions should be created:
@DATEPARTS and @TIMEPARTS which would return a bit-encoded number, each bit indicating that a component was specified. @DATEPARTS would have bits for year, month, and date; @TIMEPARTS would have bits for hour, minute, second, millisecond, and am/pm indicator (and maybe offset from UTC). (And that would allow detection of a partial date, like 31-Dec.)

You read my mind, Dave. I have already implemented @ISTIME and @TIMEPARTS, both exactly as you say! (Both are trivial; most of the work is just documentation....)

I don't think @DATEPARTS will happen, though. My ParseDate() routine doesn't return that info, and there are just too many ways of specifying a date: as year-month-day, as a julian, year-day, year-week-day, as an offset from today's date....
 
Thank you very, very, much Charles, and I had kind of suspected that that would be the case for catching errors created by plugins, which is why I specifically added the second option as being a viable (truthfully, maybe even more viable) option. I had written all of the code to do this myself (code that could potentially have some performance impact because it had more logic than could be put into a TCC function and therefore had to be called or EXECSTR'd) because I considered it to be a requirement in the application that I am writing, code that will now be (happily!) abandoned. :)

Oh, and I think that it is asymptotically reaching perfection; it is so close and yet so close! :)

- Dan
 
A suggestion not a complaint: Since you took the time to add the time functionality to the plugin (again, thank you very, very, much :)) you might want to mention that it's there on http://www.unm.edu/~cdye/plugins/index.html. Give yourself some credit and other people an idea that it's there if they have a need for it.

- Dan
 

Similar threads

Back
Top