UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
2 Pages V  1 2 >  (Go to first unread post)
   Reply to this topicStart new topic
> Global Variables, Access 2016    
 
   
whitechair
post Dec 27 2017, 10:01 AM
Post#1



Posts: 436
Joined: 26-June 08



I am trying to learn a little bit about global variables.
I have the following code in the Module for my dashboard form:
CODE
Public gvAgentID As Long
Public gvWindowsUserName As String
Option Explicit

Public Sub Init_Globals()
gvWindowsUserName = Environ("USERNAME")
gvAgentID = DLookup("[AgentCodeID]", "tblAgentCode", "[AgentWindowsLogin] = '" & gvWindowsUserName & "'")
End Sub

Private Sub Form_Load()
    Dim vWeek2 As Long
        vWeek2 = DatePart("ww", Date)

    Call Init_Globals

End Sub

When I run the code in break mode I see that it has saved the value to the global variable. My understanding is that now I can use gvAgentID in any other module and the value will still be there. Or do I need to call Init_Globals every time I need to use gvAgentID?

I tried using gvAgentID to enter a value into a textbox on the OnLoad event of another form and it showed gvAgentID as empty.

What am I missing?

--------------------
Jeff Moseler
Access 2007
Go to the top of the page
 
kfield7
post Dec 27 2017, 10:13 AM
Post#2



Posts: 859
Joined: 12-November 03
From: Iowa Lot


Whether global or any other variable, you only need to assign a value to a variable when there is cause for that value to change.
Go to the top of the page
 
whitechair
post Dec 27 2017, 10:19 AM
Post#3



Posts: 436
Joined: 26-June 08



If that is the case, then if I have already run the previous code, why won't this code work?
CODE
Private Sub Form_Load()

    Me.txtAgentID.Value = gvAgentID

End Sub

It shows gvAgentID as empty.

--------------------
Jeff Moseler
Access 2007
Go to the top of the page
 
GroverParkGeorge
post Dec 27 2017, 10:27 AM
Post#4


UA Admin
Posts: 33,038
Joined: 20-June 02
From: Newcastle, WA


In Access "empty", means that no value has been designated yet.

What you are doing, it would appear, is creating a PUBLIC variable, not a GLOBAL variable. Note that the referenced MSDN article refers to a Static variable, but is the equivalent of a Global.

--------------------
Go to the top of the page
 
BruceM
post Dec 27 2017, 10:46 AM
Post#5


UtterAccess VIP
Posts: 7,502
Joined: 24-May 10
From: Downeast Maine


I haven't used global variables much since the advent of TempVars (Access 2007). However, if using global variables I would put the variable declarations and the public sub that sets them into a standard code module rather than a form's code module.
Go to the top of the page
 
PhilS
post Dec 27 2017, 11:57 AM
Post#6



Posts: 484
Joined: 26-May 15
From: The middle of Germany


QUOTE
I am trying to learn a little bit about global variables.
I have the following code in the Module for my dashboard form:

Global variables have to be in a normal Module, not in a (class) module of a form.

--------------------
Go to the top of the page
 
whitechair
post Dec 27 2017, 02:15 PM
Post#7



Posts: 436
Joined: 26-June 08



Phil, I put it in a normal module and it worked great. I'm learning some cool stuff. Thanks everyone!

--------------------
Jeff Moseler
Access 2007
Go to the top of the page
 
BruceM
post Dec 27 2017, 02:48 PM
Post#8


UtterAccess VIP
Posts: 7,502
Joined: 24-May 10
From: Downeast Maine


I made the same point, and also suggested that public procedures be placed in standard (aka normal, I guess) modules.

In one sense there is no need for a public procedure, since it will only be called once in the Load event of the dashboard form. However, there is a caveat: global variables can lose their values, particularly if there are unhandled code errors. Using error handling in all procedures is one way to minimize this risk. It would be a sensible precaution (and overkill, perhaps) to test the global variables before using them, and call Init_Globals if they are empty. Or perhaps trap any errors caused by empty global variables, and use the error handler to call Init_Globals if that happens.

Note that global variables cannot be used directly outside of VBA. For that you will need procedures to retrieve the value:
CODE
Public Function GetAgentID () As Long

  GetAgentID = gvAgentID

End If


TempVars do not have either of these limitations.
Go to the top of the page
 
pdanes
post Dec 27 2017, 07:25 PM
Post#9



Posts: 81
Joined: 19-June 10



You can put a sort-of global variable in a form's code module. Howevere, you have to preface references to it with the name of the form in dot notation, and it will vanish when the form is closed. But while the form is open, a variable declared there as public will be visible to the world.
This post has been edited by pdanes: Dec 27 2017, 07:57 PM
Go to the top of the page
 
GroverParkGeorge
post Dec 27 2017, 08:43 PM
Post#10


UA Admin
Posts: 33,038
Joined: 20-June 02
From: Newcastle, WA


Not really. The DEFINITION of global variable is one that doesn't depend on any particular form being open. It's global, meaning it's present in memory as long as the accdb is open -- and it hasn't been lost because of an error.

It's PUBLIC, to be sure, but that's why we refer to GLOBAL, PUBLIC and PRIVATE as three different kinds of variables.

--------------------
Go to the top of the page
 
pdanes
post Dec 28 2017, 05:14 AM
Post#11



Posts: 81
Joined: 19-June 10



"Not really", meaning what? Are you saying these variables don't work that way I wrote? How, then?

And global variables DO lose their value on reset, even when the db is still open. It's one of the things that I find extremely annoying about the ribbon construct. A reset causes all ribbon references to vanish, and since the ribbon is only directly accessible once, on database load, I have to completely close and reopen the database to set them again.

Although, I'm now wondering if the TempVars that BruceM mentioned might not be the solution to that. I've never used them, didn't even know about them, but if they retain their values through a reset, maybe I can use a TempVar to set ribbon references, and they will survive a reset, Time for some experiments.

Go to the top of the page
 
JonSmith
post Dec 28 2017, 05:28 AM
Post#12



Posts: 3,576
Joined: 19-October 10



George means that your 'sort of Global' definition makes things more confusing, one could say a public variable is 'sort of like a global' and a private one is 'sort of like a public'.

Mixing up the language is confusing, stick to the correct definitions. Forms don't have global variables.

As for the ribbon being annoying. You most certainly can get the ribbon object after a reset, you just need to cache the ribbon ID and you can reference the ribbon object again in VBA and call invalidate etc to update any values.
I would argue however that you should just handle all your errors and prevent a reset from occurring.
Go to the top of the page
 
pdanes
post Dec 28 2017, 06:19 AM
Post#13



Posts: 81
Joined: 19-June 10



"Cache" it how? Whenever a reset occurs, all variables, including the ones referring to ribbon objects are reset, and when I start a form again, they are NOT reloaded.

And I do handle errors. The resets occur when I am doing development work, and something crashes unexpectedly. The ribbon references are lost, and I have no way the get them again, so I have to close and reopen the database in order for the ribbon load events to fire again.

If you know of some way to get around this, I would love to hear it, and HOW, not just 'yes, it is possible'.
Go to the top of the page
 
JonSmith
post Dec 28 2017, 07:38 AM
Post#14



Posts: 3,576
Joined: 19-October 10



But if you've crashed don't you need to reset the entire ribbon and start again anyway? The variables holding the state of a button or a checkbox wouldn't matter cause, as you said, you crashed. All forms are reset etc etc.

So, the only thing you need to worry about is the ribbon ID. With that you can reference the ribbon object and invalidate the ribbon. Meaning all the controls will reset.
Sorry if thats not what you want to hear but I don't really see what issue you have with the ribbon. I am telling you its not only accessible of database load so therefore your problems don't seem to be issues.

JS
Go to the top of the page
 
BruceM
post Dec 28 2017, 07:38 AM
Post#15


UtterAccess VIP
Posts: 7,502
Joined: 24-May 10
From: Downeast Maine


Regarding TempVars, you can use them as long as all users have Access 2007 or later. It could be like this:
CODE
Public Sub Init_Globals()
  TempVars!WinUserN = Environ("USERNAME")
  TempVars!AgID = DLookup("[AgentCodeID]", "tblAgentCode", "[AgentWindowsLogin] = '" & TempVars!WinUserN & "'")
End Sub

Thereafter you can do:
CODE
Dim strUser As String

strUser = TempVars!WinUserN

You can call a TempVar directly in a query or a Control Source expression by using TempVars!WinUserN

There are other ways to set and recall TempVars. To set a TempVar:

TempVars.Add "WinUserN", Environ("USERNAME")

To recall a TempVar:

TempVars.Item("WinUserN")

User Remove instead of Item in the preceding line to remove a TempVar.

Other than Remove I just use the TempVars!WinUserN syntax.

I have abbreviated the variable names, but you can use whatever naming system you like, including the use of prefixes for string, long, etc.

There is quite a bit of documentation out there, but there isn't all that much to TempVars. In any case, this brief description may help you understand the more detailed explanations.

Go to the top of the page
 
pdanes
post Dec 28 2017, 08:14 AM
Post#16



Posts: 81
Joined: 19-June 10



JonSmith

Yes, after crashing, I need to reload everything - that's the whole point. I specifically need to reload all the ribbon variables, and since my reference to the ribbon object is one of the things that is cleared during a reset, I have no way to load them again, since the OnLoad event of the ribbon object does not fire again when restarting a form that uses it. Nothing that I have discovered makes that OnLoad event fire again, except closing and reopening the entire database. If you know how to make that happen WITHOUT closing and reopening, how about posting it here?
Go to the top of the page
 
pdanes
post Dec 28 2017, 08:20 AM
Post#17



Posts: 81
Joined: 19-June 10



BruceM

Thank you, that helps quite a lot. Some Access stuff is documented rather well, some almost not at all. I've been working with Access for close to twenty years, and this is the first I remember hearing of TempVars. Of course, I do other things as well, and the product is constantly evolving, so it's hard to stay on top of everything it can do.

Yes, I use 2007 or newer exclusively, so that shouldn't be a problem.
Go to the top of the page
 
JonSmith
post Dec 28 2017, 08:44 AM
Post#18



Posts: 3,576
Joined: 19-October 10



Gonna disagree with you here, I think most of it is documented pretty well, however if you think a particular aspect is lacking let me know what you think isn't documented as I am happy to be corrected. You just have to look for it. You might say how do you look for new stuff that didn't exist before. Easy, the way you should be reviewing the new features released in new versions of Office.
For example here are a couple of old posts from Microsoft about new features released, there are plenty of non MS blogs about the subjects too.
Some of the info in these posts is now so old its been deprecated I think such as the Outlook data collector thing (correct me if I'm wrong).

https://msdn.microsoft.com/en-us/library/bb...office.12).aspx
https://support.office.com/en-us/article/Wh...f7-6def0f1821b8

You cannot learn Access, or any IT thing 20 years ago and not constantly be trying to learn new things. I specifically test any prospective employees knowledge of newer features of Office to ensure they are keeping up to date otherwise I am not interested. I have so many issues with inherited tools that have Legacy code that was deprecated 10 years ago and kept in a few further releases for compatibility. When you try to update Office then the whole bloody thing needs changing, if the people writing that code had attempted to update there methods to the current standards that mess wouldn't have needed cleaning up.

So I recommend spending some time learning of the new features from 2007 up to the version of Access you use (no point going further ahead really, I am pretty ignorant of Office 365 or 2016 for example). Bear in mind, not all new features are good, alot of people around here would recommend against things like MVF's or lookup fields. Attachment fields are a mix of pro's and con's. You should know about them all though I think, at least the ones implemented 10 years ago.
Go to the top of the page
 
JonSmith
post Dec 28 2017, 08:46 AM
Post#19



Posts: 3,576
Joined: 19-October 10



Blog post about getting the ribbon back after loss of state which is one of the top hits when googling 'get ribbon after loss of state'

Blog talks about Excel but the same can be done in Access, just store the ribbon ID somewhere.

https://blogs.office.com/en-us/2011/05/19/a...object/?eu=true
Go to the top of the page
 
jleach
post Dec 28 2017, 09:11 AM
Post#20


UtterAccess Editor
Posts: 9,922
Joined: 7-December 09
From: Staten Island, NY, USA


TempVars just take the problem of global variable use and make it even worse (not scope/reset issues, but deeper architectural issues with the code).

Rather than trying to find a way to retain/reload state after a loss of state, one should prevent the loss of state in the first place. This is like trying different methods to sew your toe back on after shooting it off, when maybe the safety should have been on before it was pointed at your foot.

Cheers,


--------------------
Go to the top of the page
 
2 Pages V  1 2 >


Custom Search
RSSSearch   Top   Lo-Fi    19th July 2018 - 06:27 PM