Improving the Experience
06/29/2007 08:10 Filed in: PolicePro
The old truth in software is that the easier a
program or function is to use, the more work some
poor guy had to do to make it that way. Here is one
tiny detail that emerged during the v9 rewrite for
PolicePro as an example.
We do a ton of monthly reporting in PolicePro: incidents by Type, Incidents by Zone/Post, UCR, (soon) IBR, Clery reports for college security, Officer activity, you name it. To capture the date ranges to be reported on, we use Global fields on dialog boxes where the user enters a simple string: 6/2007 for June 2007, for example. The input field is a Text field, as opposed to a Date based field, since to get that same month result in a global Date field would require the user to enter 6/1/2007...6/30/2007 - who wants to do that if they don't have to?
But to display an English month and date on the resulting printed report, we had to have the users put that in as well under the existing system, or be stuck with a report that said "All Incidents Report 6/2007". I never much liked either alternative.
So I decided to write some calculations against that entry field, the gDateForSearch field, which would pull out the results I wanted with one simple entry field.
The Report Title is based on two more globals, gMonth and gYear. The gYear was easy: a Right function, pulling the last four characters from the gDateForSearch, since there will always be a four digit year in the string.
Whenever a Print report script runs then, the gMonth and gYear get populated by a calculation that runs in a two-step subscript:
The gMonth though? Yikes! Since it can be one or two characters, you have to look for the first incidence of the slash character... so that means adding a Position function inside a Left function, but the Left calc looking at that always INCLUDES the damn thing. Okay, then we'll run a Filter on the result to get rid of the slash... then we've still gotta turn the result into text.
And the Filter function? If you filter for 0123456789, the calc engine will drop the 0 every time, and 10/2007 will evaluate as January, 2007! Turns out the 0 has to be at the END of the string. It took ten minutes just to figure that part out! I could not initially get why the 0 kept dropping. (Of course, all I had to do was wrap the filter values in quotes, but hey, it was a long day!)
Two hours of trial and error, fighting with every semicolon, every parenthesis, on and on till it was right:
I originally thought this would be a nice, easy Month calc, but it doesn't work on a text field, and we already talked about why the entry field couldn't be a Date field.
This is now going to get a Length calc wrapped around the whole thing so it won't attempt to evaluate a string with the day in it, indicating a part of a month: 6/21/2007, or 6/1/2007...6/10/2007. In that case it will default to the actual date range entered straight out of the gDateForSearch field.
We do a ton of monthly reporting in PolicePro: incidents by Type, Incidents by Zone/Post, UCR, (soon) IBR, Clery reports for college security, Officer activity, you name it. To capture the date ranges to be reported on, we use Global fields on dialog boxes where the user enters a simple string: 6/2007 for June 2007, for example. The input field is a Text field, as opposed to a Date based field, since to get that same month result in a global Date field would require the user to enter 6/1/2007...6/30/2007 - who wants to do that if they don't have to?
But to display an English month and date on the resulting printed report, we had to have the users put that in as well under the existing system, or be stuck with a report that said "All Incidents Report 6/2007". I never much liked either alternative.
So I decided to write some calculations against that entry field, the gDateForSearch field, which would pull out the results I wanted with one simple entry field.
The Report Title is based on two more globals, gMonth and gYear. The gYear was easy: a Right function, pulling the last four characters from the gDateForSearch, since there will always be a four digit year in the string.
Whenever a Print report script runs then, the gMonth and gYear get populated by a calculation that runs in a two-step subscript:
The gMonth though? Yikes! Since it can be one or two characters, you have to look for the first incidence of the slash character... so that means adding a Position function inside a Left function, but the Left calc looking at that always INCLUDES the damn thing. Okay, then we'll run a Filter on the result to get rid of the slash... then we've still gotta turn the result into text.
And the Filter function? If you filter for 0123456789, the calc engine will drop the 0 every time, and 10/2007 will evaluate as January, 2007! Turns out the 0 has to be at the END of the string. It took ten minutes just to figure that part out! I could not initially get why the 0 kept dropping. (Of course, all I had to do was wrap the filter values in quotes, but hey, it was a long day!)
Two hours of trial and error, fighting with every semicolon, every parenthesis, on and on till it was right:
I originally thought this would be a nice, easy Month calc, but it doesn't work on a text field, and we already talked about why the entry field couldn't be a Date field.
This is now going to get a Length calc wrapped around the whole thing so it won't attempt to evaluate a string with the day in it, indicating a part of a month: 6/21/2007, or 6/1/2007...6/10/2007. In that case it will default to the actual date range entered straight out of the gDateForSearch field.
|