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.
|
Might As Well Get Them Used To It
06/14/2007 11:31
Joe Wilcox in Microsoft Watch
spotted this kids' ride in a coffee shop. I
guess this is Early Windows User Training!
So Long, Tony
06/11/2007 08:23 Filed in: Personal
Then I thought about it for awhile, and this morning I've heard other opinions that sort of gel with where I've landed: You never hear the shot that kills you.
Phil didn't - he got it in the back of the head in front of (some of) his family. And think back to Tony and Bobby in the boat on the Adirondack lake earlier this season, talking about what happens when you die: "Everything just goes black".
The series didn't end at all, I think, it STOPPED. Tony's gone and no amount of rationalization by his wife or kids is ever going to take away the knowledge of who he was. Sort of a final come-uppance to people who routinely sold themselves out no matter what ethics they may or may not have espoused.
At any rate, it was a pretty good eight (?) years... now we can get back to Salt Lake City and Big Love, and wait for the return of The Wire. Take care, Tony, it was interesting knowing you.