Hi Glenn,
Are global constants susceptible to getting lost like global variables? For this reason, I use database properties instead of global variables. I do, however, see the value of exploring this. As more people move to 64-bit and apps need to also run on 32, compiler directives become necessary. For instance, the Analyzer for Microsoft Access is enabled for 32 and 64.
Warm Regards,
Crystal
*
(: have an awesome day :)
*
On Saturday, December 20, 2014 7:06 AM, "'Glenn Lloyd' argeedblu@gmail.com [MS_Access_Professionals]" <MS_Access_Professionals@yahoogroups.com> wrote:
The advantage of using a compiler directive is that switching from one compile version to another takes only as long as it takes to type the directive and assign its value (~.1 sec) if you use a global directive.
Glenn
From: MS_Access_Professionals@yahoogroups.com [mailto:MS_Access_Professionals@yahoogroups.com]
Sent: Friday, December 19, 2014 3:07 PM
To: MS_Access_Professionals@yahoogroups.com
Subject: Re: [MS_AccessPros] Late Binding question
Sent: Friday, December 19, 2014 3:07 PM
To: MS_Access_Professionals@yahoogroups.com
Subject: Re: [MS_AccessPros] Late Binding question
good idea, Glenn ~ thanks. I try to keep it more simple but I suppose that is fairly simple too ~ just a matter of changing my habit ;) ~
Warm Regards,
Crystal
*
(: have an awesome day :)
*
On Friday, December 19, 2014 5:28 AM, "'Glenn Lloyd' argeedblu@gmail.com [MS_Access_Professionals]" <MS_Access_Professionals@yahoogroups.com> wrote:
Crystal,
Have you considered using a compiler directive rather than commenting in/out to make the switch?
Glenn
From: MS_Access_Professionals@yahoogroups.com [mailto:MS_Access_Professionals@yahoogroups.com]
Sent: Thursday, December 18, 2014 8:48 PM
To: MS_Access_Professionals@yahoogroups.com
Subject: Re: [MS_AccessPros] Late Binding question
Sent: Thursday, December 18, 2014 8:48 PM
To: MS_Access_Professionals@yahoogroups.com
Subject: Re: [MS_AccessPros] Late Binding question
Hi Jim,
I normally put 2 sets of declaration statements in -- one for early and one for late binding -- and comment one or the other (depending if it in in development or for deployment). As I am coding, I substitute constants with their numeric values since changing versions is a constant issue. The performance is not as good ... but who cares about nanoseconds? More important is the ability to run! ... and keep running!
When you Dim as Something.Application, you must have a reference to that 'Something' Object Library. This is fine while you are developing, but when you deploy, users might have a different version of the software and that means that your object reference library may not be the same as theirs. In order to run the application, they would need to edit the References and then compile. For non-programmers, this is a daunting task.
If, on the other hand, you Dim as Object ... then when you go to run the application, Access will get the information it needs at runtime and use whatever object library version the user has. In other words, late-binding makes your application version-independent
So why use early binding at all?
While you are developing, it is nice to have the Intellisense to help complete statements. If the object library is not referenced AND the variable is not DIMmmed with early binding, that cannot happen.
If you use any constants, the number has to be looked up for late-binding to work.
Lets say you want to open a report in preview mode.
In Access, the statement would be:
DoCmd.OpenReport "Reportname", acViewPreview
... but acViewPreview is a constant that is only known if the Access Object Library is referenced. This is fine for Access, but what about automation from other products? While most of us do control code from Access, the same concept applies to, for instance, Excel, so I use this an an example.
acViewPreview is a constant you can use for the View parameter of OpenReport. If we were in something else doing late binding to Access, we would have to use 2 instead of the constant.
To determine the numerical value of a constant:
Ctrl-G
Goto the debuG (Immediate) window
type -->
? acViewPreview
and then press ENTER
so, in code, this is one way to document what the number means:
'~~~~~~~~~~~~~~~~~~~~~~~~~~
DoCmd.OpenReport "Reportname", 2 '2 = acViewPreview
'~~~~~~~~~~~~~~~~~~~~~~~~~~
or... if you have an option frame for the output type named fraOutput
WHERE
1 is preview
2 is print
then you might do the code this way:
'~~~~~~~~~~~~~~~~~~~~~~~~~~
' acViewPreview: 0 = acViewNormal, 2 = acViewPreview
If me.fraOutput = 2 then
DoCmd.OpenReport "Reportname", 0
else
'I make the default go to the screen
DoCmd.OpenReport "Reportname", 2
endif
'~~~~~~~~~~~~~~~~~~~~~~~~~~
If, on the other hand, you Dim as Object ... then when you go to run the application, Access will get the information it needs at runtime and use whatever object library version the user has. In other words, late-binding makes your application version-independent
So why use early binding at all?
While you are developing, it is nice to have the Intellisense to help complete statements. If the object library is not referenced AND the variable is not DIMmmed with early binding, that cannot happen.
If you use any constants, the number has to be looked up for late-binding to work.
Lets say you want to open a report in preview mode.
In Access, the statement would be:
DoCmd.OpenReport "Reportname", acViewPreview
... but acViewPreview is a constant that is only known if the Access Object Library is referenced. This is fine for Access, but what about automation from other products? While most of us do control code from Access, the same concept applies to, for instance, Excel, so I use this an an example.
acViewPreview is a constant you can use for the View parameter of OpenReport. If we were in something else doing late binding to Access, we would have to use 2 instead of the constant.
To determine the numerical value of a constant:
Ctrl-G
Goto the debuG (Immediate) window
type -->
? acViewPreview
and then press ENTER
so, in code, this is one way to document what the number means:
'~~~~~~~~~~~~~~~~~~~~~~~~~~
DoCmd.OpenReport "Reportname", 2 '2 = acViewPreview
'~~~~~~~~~~~~~~~~~~~~~~~~~~
or... if you have an option frame for the output type named fraOutput
WHERE
1 is preview
2 is print
then you might do the code this way:
'~~~~~~~~~~~~~~~~~~~~~~~~~~
' acViewPreview: 0 = acViewNormal, 2 = acViewPreview
If me.fraOutput = 2 then
DoCmd.OpenReport "Reportname", 0
else
'I make the default go to the screen
DoCmd.OpenReport "Reportname", 2
endif
'~~~~~~~~~~~~~~~~~~~~~~~~~~
btw, I normally do NOT substitute numbers for Access constants since Access is usually what I am controlling from, but this is an easy example to understand so I have used it ;) ~
~~~
here are other reference links on binding:
Late Binding in Microsoft Access, by Tony Toews
http://www.granite.ab.ca/access/latebinding.htm
http://www.granite.ab.ca/access/latebinding.htm
Dick's Clicks, Early Binding vs. Late Binding, by Dick Kusleika (Excel)
http://www.dicks-clicks.com/excel/olBinding.htm
Using early binding and late binding in Automation, Microsoft
http://support.microsoft.com/kb/245115
Warm Regards,
Crystal
Code Documenter for Access, Excel, Word, & PowerPoint
http://www.accessmvp.com/strive4peace/CodeDocumenter.htm
http://www.accessmvp.com/strive4peace/CodeDocumenter.htm
*
(: have an awesome day :)
*
On Thursday, December 18, 2014 11:32 AM, "Jim Wagner luvmymelody@yahoo.com [MS_Access_Professionals]" <MS_Access_Professionals@yahoogroups.com> wrote:
IT gave me a laptop with Office 2013 installed so that I can test my 50 databases in the new version. So I know that someday the company will make it standard. But my experience with changing versions have been all over the place. I have seen versions from 2000 to 2010 in all the years. My big concern is changing to late binding for all of the emailing processes that we have.
So today I was testing a database and noticed that automatically the 2013 version added the reference to the new vba reference without me doing anything. I have never experienced that before. I even had to change a personal database to late binding because I thought it would error out on me. But this development changes some things. I have read that early binding can be a little better on performance than late binding so I really do not want to make a change. We do not change versions very often, so I am not sure of the need to make the change. What are the thoughts of the group.
Thank You
Jim Wagner
__._,_.___
Posted by: Crystal <strive4peace2008@yahoo.com>
Reply via web post | • | Reply to sender | • | Reply to group | • | Start a New Topic | • | Messages in this topic (6) |
.
__,_._,___
Tidak ada komentar:
Posting Komentar