 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Modules / DAO / VBA / September 2005Set string later use as filter
I have some code that I run to update my tables, and it also creates a filter statement as a string that I would like to use later for the form (not directly after I've run the code, so I can't just use the 'where' condition in the 'open form' method). How would I go about storing/accessing this string for later use when I open the form?  SignatureYo Yo Ma. Use a global variable as in Global [variableName] as String I always use 'glb_' as a prefix to my globals to indicate that the variable is a global and I stick them all in a free standing module named Global Variables just to have them all handy. > I have some code that I run to update my tables, and it also creates a filter > statement as a string that I would like to use later for the form (not > directly after I've run the code, so I can't just use the 'where' condition > in the 'open form' method). How would I go about storing/accessing this > string for later use when I open the form? Hi, you can for example store this filter in public variable, or you can use a local table to save filter there, and then retrieve when necessary SignatureAlex Dybenko (MVP) http://alexdyb.blogspot.com http://www.PointLtd.com >I have some code that I run to update my tables, and it also creates a >filter [quoted text clipped - 3 lines] > in the 'open form' method). How would I go about storing/accessing this > string for later use when I open the form? My aversion to global variables is exceeded only by my aversion to the GoTo. Here is a function that replaces the need (there really is never a need) for global variables. Function MyPubVar(Optional varPubVal As Variant) As Variant 'Returns current value if no parameter passed 'Stores value passed 'Establishes a default value for first call Static varSaveVal As Variant If IsMissing(varPubVal) Then If IsEmpty(varSaveVal) Then varSaveVal = "GotIt!" 'The initial value goes here End If Else varSaveVal = varPubVal End If MyPubVar = varSaveVal End Function > I have some code that I run to update my tables, and it also creates a filter > statement as a string that I would like to use later for the form (not > directly after I've run the code, so I can't just use the 'where' condition > in the 'open form' method). How would I go about storing/accessing this > string for later use when I open the form? Could you elaborate as to the differences between the two and your aversion to globals? > My aversion to global variables is exceeded only by my aversion to the GoTo. > Here is a function that replaces the need (there really is never a need) for [quoted text clipped - 22 lines] >>in the 'open form' method). How would I go about storing/accessing this >>string for later use when I open the form? The wider the scope of a variable, the more apt the value of the varialbe is to be suspect. If you are the only developer in an application, then it doesn't matter as much. In reality, there is not that much difference between the two. I quess I picked up the preference in other languages where globals are a little harder to manage. It is mostly style, as in avoiding the GoTo. Global variables can be over used, in other words, used when they are not necessary. So, if you put a taboo on them, you may not eliminate them, but hopefully make people think before using them. In this particular case, we don't really know where his code exists. Could it be in the same module that he does the updates that he calls the OpenForm? If so, a module level variable would be more appropriate. > Could you elaborate as to the differences between the two and your > aversion to globals? [quoted text clipped - 25 lines] > >>in the 'open form' method). How would I go about storing/accessing this > >>string for later use when I open the form? So then I wasn't wacked out in using Global's to replace multiple DLookup's of the same information across multiple SUBs? In my DB, the table tblTransports is more or less the core of the database. As such, I had multiple SUBs (createOutlookAppointment, createLedgerEntry, updateLedgerEntry, etc.) that used DLookups to grab the relevant information from the table - date, time, origination, destination, etc, etc. To streamline things, I created a SUB - loadTransport() that takes the record ID of the transport and sets related global variables for use in the various SUBS. The globals are set by using DAO to grab the record. The thinking is that it would be easier to use Globals as opposed to 10+ DLookups on the same table. David H > The wider the scope of a variable, the more apt the value of the varialbe is > to be suspect. If you are the only developer in an application, then it [quoted text clipped - 38 lines] >>>>in the 'open form' method). How would I go about storing/accessing this >>>>string for later use when I open the form? I don't think that is wacked out at all. There is valid justification for breaking almost any rule if the alternative makes sense by improving efficiency. > So then I wasn't wacked out in using Global's to replace multiple > DLookup's of the same information across multiple SUBs? In my DB, the [quoted text clipped - 52 lines] > >>>>in the 'open form' method). How would I go about storing/accessing this > >>>>string for later use when I open the form? >I have some code that I run to update my tables, and it also creates a filter >statement as a string that I would like to use later for the form (not >directly after I've run the code, so I can't just use the 'where' condition >in the 'open form' method). How would I go about storing/accessing this >string for later use when I open the form? Another place you can save a value is in a text box on an always open form, such as your startup form. This is a safer place than a Public variable in a standard module(reset on any unhandled error), but will not survive closing the database as putting it in a table will. SignatureMarsh MVP [MS Access] Nor will it survive if the FORM is closed. >>I have some code that I run to update my tables, and it also creates a filter >>statement as a string that I would like to use later for the form (not [quoted text clipped - 8 lines] > module(reset on any unhandled error), but will not survive > closing the database as putting it in a table will. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.