My muddiness when it comes to OpenArgs

I was getting an syntax error message when I clicked on a New button on the Equipment Quick Finder form.  The equipment form in the Granite Fleet Manager executes a reasonable amount of code on startup. 

I had added that New button to the Quick Finder form when I created it and all was well.  Trouble is I added some code in the Equipment form that required the OpenArgs start with "New" when the record did not exist.   And now the code was causing me troubles. While I fixed the immediate problem I realized I had a larger issue.

When testing I realized that if I'm updating a piece of equipment then the OpenArgs will legitimately be empty.

So I added the following code in the forms Open Event.

     If IsNull(Me.OpenArgs) And Len(Me.Filter) = 0 Then _
         MsgBox "OpenArgs is null and Filter is empty."

I also did a Find through all the code looking for OpenForm "Equipment" just to ensure I didn't have any other problems hidden away somewhere else.

The lesson is that if you are depending that OpenArgs have values in it ensure that values are always present.  Pop up a message for the programmer to give him (or her) a kick.

This is a follow up to the Watch out for Null OpenArgs blog posting.   (And I sincerely hope my clients never chip in to purchase the chair mentioned at Microsoft: We Share Your Pain.)

Published Wed, Nov 26 2008 14:37 by Tony
Filed under: , , ,

Comments

# re: My muddiness when it comes to OpenArgs

This is one of the reasons I don't like to overload OpenArgs with too much functionality. In my opinion, if you're doing more than one thing in OpenArgs, you're in for trouble. Any time I need more than one piece of data in a form opened with OpenArgs, I switch to using a class module for storage of the data I'd be passing via OpenArgs. This makes things *much* easier to troubleshoot, in my opinion, as well as a lot more flexible in terms of adding new items of info that you want to pass to the form, and without effecting how the form is used in other places. Some day I'll get around to finishing working up my "Report Switchboard" sample, which uses class modules for setting up complex report filtering.

--

David W. Fenton

http://dfenton.com/DFA/

Thursday, November 27, 2008 6:35 PM by David W. Fenton

# re: My muddiness when it comes to OpenArgs

Now I have to admit I've never quite understood class modules so I generally stay away from them unless I'm using imported code.   So that's one of my weaknesses.

That said in this case I should've been doing a better job of ensuring that I always passed in an argument if a new record.   I only ever pass in two different values.  "New" for regular equipment or "New Customer Equipment" if being opened from the Custome Equipment Quick Find form.

Thursday, November 27, 2008 6:53 PM by Tony

# re: My muddiness when it comes to OpenArgs

My point, Tony, is that if you are using a mechanism for passing the information that forces the information to be structured (as a class module does), it's much harder to get it wrong.

Add to that the fact that class modules have an Initialize() event that can be used to provide default values, and you've got a whole lot of capability there that is going to make it much easier to pass information from one part of your app to another.

A class module also maintains the independence of the calling form and the target form, in that neither have to know anything about each other -- all they have to know about is the class module structure that both rely on. For me, this is far, far easier to work with than trying to remember how to code and delimit your OpenArgs.

--

David W. Fenton

David Fenton Associates

http://dfenton.com/DFA/

Saturday, November 29, 2008 6:07 PM by David W. Fenton

Leave a Comment

(required) 
(required) 
(optional)
(required) 
If you can't read this number refresh your screen
Enter the numbers above: