Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Access 2010 #Name? error. Assign variable to textbox.
2,768 views
Skip to first unread message
Greg (codepug@gmail.com)
Dec 19, 2013, 7:57:26 PM12/19/13
to
I have an app that worked great in access 2000. When attempting to run to 2010 I have a number of fields that are displaying #Name? errors.
The commonality is that each of these textboxes have variables in the control source. For example on the properties setting for the control source
in one case I have = strName. This is simply a Public text variable in VBA code that takes on a select value in the Form when a key is pressed. The
variable displays just fine in a MessageBox, but not in the Form. It works fine in XP on Access 2000.
If this is no longer permissible, how do I display a variables value on the form? I researched this for hours, and cannot find the answer. By the way
I tried using Public variables at many levels, and also created Public functions to pass the variable = PassVar(strName) without success.
Windows7 Access2010
The commonality is that each of these textboxes have variables in the control source. For example on the properties setting for the control source
in one case I have = strName. This is simply a Public text variable in VBA code that takes on a select value in the Form when a key is pressed. The
variable displays just fine in a MessageBox, but not in the Form. It works fine in XP on Access 2000.
If this is no longer permissible, how do I display a variables value on the form? I researched this for hours, and cannot find the answer. By the way
I tried using Public variables at many levels, and also created Public functions to pass the variable = PassVar(strName) without success.
Windows7 Access2010
Patrick Finucane
Dec 19, 2013, 8:29:55 PM12/19/13
to
=Tempvars!variableName
Greg (codepug@gmail.com)
Dec 19, 2013, 11:45:03 PM12/19/13
to
My research, while disappointing, has concluded. It appears that standard coded variables are not meant to be passed through the Control Source
of a textbox. It worked for me in Access 2000, however, Not in 2010. So, I will leave the textboxes that I planned on assigning variable values
to, UnBound. And, I will pass the variable value to the textbox in VBA code. Ex me.txtBox = strName
Since a few of these fields were meant to be calculated fields, I will likely create a coded procedure where all the calculations and value assignments take place.
It is here that the variable value will be passed to the textbox me.txtBox2 = varSum + me.txtBoxEntry. I will have to call this procedure in the AfterUpdate Event of any textbox in my form that may be subject to associated data entry, and probably place in the Forms OnCurrent Event as well. This will assure that the calculation that takes place carries over to the Forms calculation fields for display ( dynamic).
of a textbox. It worked for me in Access 2000, however, Not in 2010. So, I will leave the textboxes that I planned on assigning variable values
to, UnBound. And, I will pass the variable value to the textbox in VBA code. Ex me.txtBox = strName
Since a few of these fields were meant to be calculated fields, I will likely create a coded procedure where all the calculations and value assignments take place.
It is here that the variable value will be passed to the textbox me.txtBox2 = varSum + me.txtBoxEntry. I will have to call this procedure in the AfterUpdate Event of any textbox in my form that may be subject to associated data entry, and probably place in the Forms OnCurrent Event as well. This will assure that the calculation that takes place carries over to the Forms calculation fields for display ( dynamic).
Albert D. Kallal
Dec 20, 2013, 3:08:24 AM12/20/13
to
wrote in message
news:486d5ea5-1e8d-45e9...@googlegroups.com...
>My research, while disappointing, has concluded. It appears that standard
>coded variables are not meant to be passed through the Control Source
>of a textbox. It worked for me in Access 2000, however
The above could not have worked before.
You could NEVER place VBA variables in a forms control expression.
(and you cannot do the same in the sql query builder either)
You could not do this in Access 97, nor in Access 2000, or 2002.
If this was possible and along the way say in Access 2007 or 2010 REMOVED
this ability then the Access blogs, articles and a
outright MASSIVE HUGE BIG GREAT HEFTY HUMONGOUS GIGANTIC COLOSSAL VAST LARGE
SPECTACULAR AMAZING
amount of applications would all of a sudden stop working!
And boy, it would be VERY cool if you could use VBA variables in controls
expressions.
I mean if we spend some time thinking about this, then if in the past if
such a feature existed and was removed then when did this occur?
So to answer your question?
No, it was was not possible in the past to use VBA variables in a text box
control source expression.
So no local or global Access variables can be used in control expressions
and they NEVER could be in past versions of Access.
You can use public VBA functions, but not VBA variables. (so some of those
functions can thus return a VBA variable).
As much as I wish this was possible now or in the past - it never been
possible in Access.
best regards,
--
Albert D. Kallal (Microsoft Access MVP)
Edmonton, Alberta Canada
PleaseNoS...@msn.com
Technical Editor: Access 2010 Programmers Reference
Technical Editor: Microsoft Access in a SharePoint World
Contributor: Access Solutions (Tips, Tricks and Secrets from Microsoft
MVP's)
news:486d5ea5-1e8d-45e9...@googlegroups.com...
>My research, while disappointing, has concluded. It appears that standard
>coded variables are not meant to be passed through the Control Source
>of a textbox. It worked for me in Access 2000, however
You could NEVER place VBA variables in a forms control expression.
(and you cannot do the same in the sql query builder either)
You could not do this in Access 97, nor in Access 2000, or 2002.
If this was possible and along the way say in Access 2007 or 2010 REMOVED
this ability then the Access blogs, articles and a
outright MASSIVE HUGE BIG GREAT HEFTY HUMONGOUS GIGANTIC COLOSSAL VAST LARGE
SPECTACULAR AMAZING
amount of applications would all of a sudden stop working!
And boy, it would be VERY cool if you could use VBA variables in controls
expressions.
I mean if we spend some time thinking about this, then if in the past if
such a feature existed and was removed then when did this occur?
So to answer your question?
No, it was was not possible in the past to use VBA variables in a text box
control source expression.
So no local or global Access variables can be used in control expressions
and they NEVER could be in past versions of Access.
You can use public VBA functions, but not VBA variables. (so some of those
functions can thus return a VBA variable).
As much as I wish this was possible now or in the past - it never been
possible in Access.
best regards,
--
Albert D. Kallal (Microsoft Access MVP)
Edmonton, Alberta Canada
PleaseNoS...@msn.com
Technical Editor: Access 2010 Programmers Reference
Technical Editor: Microsoft Access in a SharePoint World
Contributor: Access Solutions (Tips, Tricks and Secrets from Microsoft
MVP's)
Greg (codepug@gmail.com)
Dec 20, 2013, 9:28:39 AM12/20/13
to
> So no local or global Access variables can be used in control expressions and > they NEVER could be in past versions of Access. You can use public VBA
> functions, but not VBA variables.
Albert:
> functions, but not VBA variables.
Thank you for your reply. I'm perplexed. I am using Access2000(w/SP3) on Windows XP, and my app has run fine for years. When I updated to Access2010 on Windows2007, I have a number of txtBoxes showing #Name$. And, so do others incidentally, but not the outcry that you would expect. I just went into the VBA code of my Form, and I have variable assignments (Public strMode as String, Public intNumber as Integer, etc...) In the Form_Open event I assign values: strMode = "Apples" intNumber = 5. In a textBox Control on the form, through properties, I place in the Control Source the following: =[strMode]. And in another txtBox I place =[intNumber], and the results display just fine when the form is viewed. Not in Access 2010 however???
Additionally, in an effort to pass a variable through the Control Source of a txtBox in Access 2010, I created a Function to pass a value - as many suggest this works. But, I continue to get #Name$, and not the passed value?
Public Function PassVarValue(X As Variant) As Variant
PassVarValue = X
End Function
In Access 2010
= strMode ; Does not work
= PassVarValue(strMode) ; Does not work
= "Apple" ; This works
= PassVarValue ("Apple") ; This works
Any Thoughts ?
Ulrich Möller
Dec 20, 2013, 2:35:01 PM12/20/13
to
i just try to reproduce the problem from Greg and i must confirm, that
at least in Access2000 it was possible to assign a public variable as a
controlsource and it works. After opening the same database in
access2010, the textbox shows "#Name?" as Greg described. Converting the
mdb in accdb do not make any changes to that behavior and in both cases
it will not produce any error message.
Ulrich
Albert D. Kallal
Dec 20, 2013, 2:52:53 PM12/20/13
to
You cannot use VBA variables in a control source expression.
Further, you talking about the forms on-load event (you cannot modify values
of BOUND controls in a forms on-open event).
And unless those VBA variables are declared at the MODULE level, they go out
of scope anyway.
So if you created the VBA variables in one routine (such as on-load or
on-open), then when the routine is finished, then the variable NO LONGER
exist and thus cannot supply values to controls.
I mean, this works:
Private Sub Form_Load()
Dim strV1 As String
strV1 = "='hello'"
Me.Text71 = strV1
End Sub
Of course the above just sets the control to a string value. (the control
can be bound to a column, or even be un-bound).
This also works:
Private Sub Form_Load()
Dim strV1 As String
strV1 = "='hello'"
Me.Text71.ControlSource = strV1
End Sub
So you can certainly change/set the control source to an expression, but
once again the expression cannot have any VBA variables.
The ONLY way what you have could have worked if the form was bound to a
query or table that had columns of the same name as those variables.
The previous application must have had a property called strMode (a column
from a table), or a control on the form.
And if the data source of a control is an expression, then you CAN NOT edit
those controls. So once the values were set then those controls could not
edit data but ONLY display? (right??).
Could/did you edit those controls on the form in the past when entering
data?
If you could edit those controls, then they were bound to a column - not a
VBA var.
>>>In Access 2010
= strMode ; Does not work
= PassVarValue(strMode) ; Does not work
= "Apple" ; This works
= PassVarValue ("Apple") ; This works
The above sounds 100% correct - no surprise.
And use of a bound control such as:
= PassVarValue ([Some Control Name]) -- this also should work.
You could in a PUBLIC module decleare this:
Public Function strMode() as string
strMode = some global VBA var
End Function
So you CAN pass a control value to the VBA fucntion as per above [FirstName]
or [strMode]. This assumes that FirstName or strMode exists as a control on
the form.
So while something in the past was working, it was NOT doing what you think
it was.
Fire up a machine with access 2000, and build a TINY test form that attempts
to do what you are thinking here - it will not work and never did. Just
place ONE text box on the form, and set the control source to your magical
supposed idea, and run it.
You either had some controls on the form with the same name as the VBA vars,
or something else was going on here.
Simply put:
What code you had before might have been running, but it was NOT doing what
you thought it did!!!
You cannot and NEVER could use VBA variables in a control source. You can
use other controls on the form, and public functions however.
Fire up Access 2000 on a machine. Create a blank form with one simple text
box. Now in the on-load attempt to set one variable and have a control with
an expression that supposed reference expression to that variable does not
work and NEVER could and NEVER did. (you have to start with a new form since
older existing forms have auto-generated properrties based on the original
table)
And hey if you CAN build such super duper simple form then you have the HUGE
JOY of throwing HUGE egg on my face in public here!
I been a Access MVP for 10 years, contributed to books on Access and was a
technical editor for Access 2010 Programmers reference. In other words,
would it not be cool to throw egg on me in public if you can create + build
such a simple form in Access 2000 that does what you say?
Remember – create a new Access 2000 database from scratch with Access 2000
and create that simple form with your variable and expression. You will find
it does not work. The end result here is your existing form code is not
doing what you think it is doing.
Best regards,
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Further, you talking about the forms on-load event (you cannot modify values
of BOUND controls in a forms on-open event).
And unless those VBA variables are declared at the MODULE level, they go out
of scope anyway.
So if you created the VBA variables in one routine (such as on-load or
on-open), then when the routine is finished, then the variable NO LONGER
exist and thus cannot supply values to controls.
I mean, this works:
Private Sub Form_Load()
Dim strV1 As String
strV1 = "='hello'"
Me.Text71 = strV1
End Sub
Of course the above just sets the control to a string value. (the control
can be bound to a column, or even be un-bound).
This also works:
Private Sub Form_Load()
Dim strV1 As String
strV1 = "='hello'"
Me.Text71.ControlSource = strV1
End Sub
So you can certainly change/set the control source to an expression, but
once again the expression cannot have any VBA variables.
The ONLY way what you have could have worked if the form was bound to a
query or table that had columns of the same name as those variables.
The previous application must have had a property called strMode (a column
from a table), or a control on the form.
And if the data source of a control is an expression, then you CAN NOT edit
those controls. So once the values were set then those controls could not
edit data but ONLY display? (right??).
Could/did you edit those controls on the form in the past when entering
data?
If you could edit those controls, then they were bound to a column - not a
VBA var.
>>>In Access 2010
= strMode ; Does not work
= PassVarValue(strMode) ; Does not work
= "Apple" ; This works
= PassVarValue ("Apple") ; This works
And use of a bound control such as:
= PassVarValue ([Some Control Name]) -- this also should work.
You could in a PUBLIC module decleare this:
Public Function strMode() as string
strMode = some global VBA var
End Function
So you CAN pass a control value to the VBA fucntion as per above [FirstName]
or [strMode]. This assumes that FirstName or strMode exists as a control on
the form.
So while something in the past was working, it was NOT doing what you think
it was.
Fire up a machine with access 2000, and build a TINY test form that attempts
to do what you are thinking here - it will not work and never did. Just
place ONE text box on the form, and set the control source to your magical
supposed idea, and run it.
You either had some controls on the form with the same name as the VBA vars,
or something else was going on here.
Simply put:
What code you had before might have been running, but it was NOT doing what
you thought it did!!!
You cannot and NEVER could use VBA variables in a control source. You can
use other controls on the form, and public functions however.
Fire up Access 2000 on a machine. Create a blank form with one simple text
box. Now in the on-load attempt to set one variable and have a control with
an expression that supposed reference expression to that variable does not
work and NEVER could and NEVER did. (you have to start with a new form since
older existing forms have auto-generated properrties based on the original
table)
And hey if you CAN build such super duper simple form then you have the HUGE
JOY of throwing HUGE egg on my face in public here!
I been a Access MVP for 10 years, contributed to books on Access and was a
technical editor for Access 2010 Programmers reference. In other words,
would it not be cool to throw egg on me in public if you can create + build
such a simple form in Access 2000 that does what you say?
Remember – create a new Access 2000 database from scratch with Access 2000
and create that simple form with your variable and expression. You will find
it does not work. The end result here is your existing form code is not
doing what you think it is doing.
Best regards,
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Ulrich Möller
Dec 20, 2013, 3:13:01 PM12/20/13
to
hard to believe, but with this little code in ACC2000 in added to a
bound form (nwind/customer table) you should be able to reproduce the
behavior:
Public intNumbers As Integer
Private Sub Befehl4_Click()
intNumbers = intNumbers + 1
Me.Recalc
End Sub
Private Sub Form_Load()
intNumbers = 0
txtTest.ControlSource = "=[intNumbers]"
End Sub
Add this lines of code , a textbox and a button and you will be surprised.
Ulrich
Greg (codepug@gmail.com)
Dec 20, 2013, 4:13:24 PM12/20/13
to
Mr Kallal, I have nothing but the utmost respect for you, and do not seek the egg thing. You have saved all of us many hours of grief. Before I commented, I created from scratch a simple FORM, and passed the variable through the textbox ControlSource as I formerly described (Access2000-SP3, W-XP). This is simply my observation - no desire to offend. Please try this with the above environment, maybe it was a since abandoned attempt on the part of MS to offer this feature?
Respectfully
Greg
Greg (codepug@gmail.com)
Dec 20, 2013, 4:38:33 PM12/20/13
to
Option Compare Database
Option Explicit
Public strMode As String
Public intNumber As Integer
--------------------------
Private Sub Form_Open(Cancel As Integer)
strMode = "Apple"
intNumber = 9
End Sub
; In a totally new project (Access2000-Sp3, WXP)
; In the ControlSource for one txtbox I typed in = [strMode]
; In the ControlSource for another txtbox I typed in = [intNumber]
;
; It displays the variables
Option Explicit
Public strMode As String
Public intNumber As Integer
--------------------------
Private Sub Form_Open(Cancel As Integer)
strMode = "Apple"
intNumber = 9
End Sub
; In a totally new project (Access2000-Sp3, WXP)
; In the ControlSource for one txtbox I typed in = [strMode]
; In the ControlSource for another txtbox I typed in = [intNumber]
;
; It displays the variables
Albert D. Kallal
Dec 20, 2013, 4:55:36 PM12/20/13
to
"Ulrich Möller" wrote in message news:l928ca$v6t$1...@dont-email.me...
>Hallo Albert,
>
>hard to believe, but with this little code in ACC2000 in added to a bound
>form (nwind/customer table) you should be able to reproduce the behavior:
You are correct!
I have never seen this before. And your code works in 2003 (figures if it
worked in 2000).
So I STAND corrected.
I have to run, but later today I will check if such code runs in 2007.
Access 2010 received a new version of VBA, so I don’t' know if its due to
VBA, or when the Access UI was changed.
As we say:
Some high quality EGG is on my face!
I do thank you for your persistence. someone here I saying;
No - that NEVER worked.
And the back call is :
yes, sir, but sir it REALLY did work! - I feel the headmaster in Oliver or
some such when I small child asks:
Please sir, may I have some more!!!!
So to all here:
I am SIMPLE DEAD wrong. Placing a variable in the control source
(surrounded by square brackets) DID WORK IN THE PAST.
IT DOES NOT WORK in 2010.
I shall try 2007 - but this is a big surprise to me. Few people if anyone
realized this works - including me!!
Perhaps Eval() might work, but I shall dig a bit deeper later today.
My apologies to the poster - not trying to come down hard, but I was simple
sure of this and I was DEAD wrong.
This is good and ok. In fact this is WHY I much post in these groups - I
STILl learn!
And often needs a thick layer of skin these groups, but one ALSO needs to be
able to tip a hat and bow when required.
Today I get to eat some high quality egg on my face!.
As the poster KINDLY states this is not about throwing eggs or even how to
cook eggs.
The poster SIMPLE wants to get some work done here!
While I dig myself out of this hole, I shall do some digging around to see
what I find
As noted, it not a personal thing - but again kindly point out to everyone I
am 100% wrong here!
Gee, my ignorance on this means I never used this feature and thus I have
nothing to worry about (golly, now I know what "ignorance is bliss"
means!!!).
Best regards,
--
Albert D. Kallal ((Access MVP)
Edmonton, Alberta Canada
PleaseNoS...@msn.com
>Hallo Albert,
>
>hard to believe, but with this little code in ACC2000 in added to a bound
>form (nwind/customer table) you should be able to reproduce the behavior:
I have never seen this before. And your code works in 2003 (figures if it
worked in 2000).
So I STAND corrected.
I have to run, but later today I will check if such code runs in 2007.
Access 2010 received a new version of VBA, so I don’t' know if its due to
VBA, or when the Access UI was changed.
As we say:
Some high quality EGG is on my face!
I do thank you for your persistence. someone here I saying;
No - that NEVER worked.
And the back call is :
yes, sir, but sir it REALLY did work! - I feel the headmaster in Oliver or
some such when I small child asks:
Please sir, may I have some more!!!!
So to all here:
I am SIMPLE DEAD wrong. Placing a variable in the control source
(surrounded by square brackets) DID WORK IN THE PAST.
IT DOES NOT WORK in 2010.
I shall try 2007 - but this is a big surprise to me. Few people if anyone
realized this works - including me!!
Perhaps Eval() might work, but I shall dig a bit deeper later today.
My apologies to the poster - not trying to come down hard, but I was simple
sure of this and I was DEAD wrong.
This is good and ok. In fact this is WHY I much post in these groups - I
STILl learn!
And often needs a thick layer of skin these groups, but one ALSO needs to be
able to tip a hat and bow when required.
Today I get to eat some high quality egg on my face!.
As the poster KINDLY states this is not about throwing eggs or even how to
cook eggs.
The poster SIMPLE wants to get some work done here!
While I dig myself out of this hole, I shall do some digging around to see
what I find
As noted, it not a personal thing - but again kindly point out to everyone I
am 100% wrong here!
Gee, my ignorance on this means I never used this feature and thus I have
nothing to worry about (golly, now I know what "ignorance is bliss"
means!!!).
Best regards,
--
Albert D. Kallal ((Access MVP)
Edmonton, Alberta Canada
PleaseNoS...@msn.com
Ulrich Möller
Dec 20, 2013, 6:27:51 PM12/20/13
to
please be assured, that i always appreciate your posts here.
I have had the same problem a few month ago and solved it easily by
using the text property of the textbox. I tried to make a smart
workaround with the obvious eval command, but i did not managed it.
So we should notice here, that this could be a migration issue and
perhaps it might end in a lot of work.
Ulrich
Albert D. Kallal
Dec 20, 2013, 7:29:55 PM12/20/13
to
Great stuff.
And I DO HAVE a solution after checking around and asking my peers. in our
private group.
The change is NOT due to VBA, but the expression service for JET/ACE that
can be sandboxed.
in 2003 a sand box mode was introduced.
If you change this setting in 2010, you code will work.
So you can either choose 2 (Access runs and allows un-safe expressions, but
non Access programs cannot use un-safe expressions),
or a setting of 0 - Both JET and non access programs + Access does not use
sandbox mode.
How to change the value is outlined here:
http://office.microsoft.com/en-us/access-help/use-sandbox-mode-in-access-2010-HA010342092.aspx
However, the above regkey is for windows 32, I found the sandbox mode for
Access 2010 on windows 7 here:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Access
Connectivity Engine\Engines
so change the sandbox mode to 2 or better yet 0
If you do this, then your code + expressions will work.
Again, thanks for me having to dig up this issue and find a solution.
And a yes - a good bit of egg on me is a VERY good thing - it teaches me
some humility and I rather happy to be wrong because at the end of the day
we have a solution - one that is now shared with the public here - that's
the power of these communities and why I still post here and will continue
to do so!
Best regards, and best of the season to you!
-
And I DO HAVE a solution after checking around and asking my peers. in our
private group.
The change is NOT due to VBA, but the expression service for JET/ACE that
can be sandboxed.
in 2003 a sand box mode was introduced.
If you change this setting in 2010, you code will work.
So you can either choose 2 (Access runs and allows un-safe expressions, but
non Access programs cannot use un-safe expressions),
or a setting of 0 - Both JET and non access programs + Access does not use
sandbox mode.
How to change the value is outlined here:
http://office.microsoft.com/en-us/access-help/use-sandbox-mode-in-access-2010-HA010342092.aspx
However, the above regkey is for windows 32, I found the sandbox mode for
Access 2010 on windows 7 here:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Access
Connectivity Engine\Engines
so change the sandbox mode to 2 or better yet 0
If you do this, then your code + expressions will work.
Again, thanks for me having to dig up this issue and find a solution.
And a yes - a good bit of egg on me is a VERY good thing - it teaches me
some humility and I rather happy to be wrong because at the end of the day
we have a solution - one that is now shared with the public here - that's
the power of these communities and why I still post here and will continue
to do so!
Best regards, and best of the season to you!
-
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
PleaseNoS...@msn.com
Edmonton, Alberta Canada
Ulrich Möller
Dec 20, 2013, 7:39:52 PM12/20/13
to
Ulrich
Access Developer
Dec 20, 2013, 8:31:26 PM12/20/13
to
Albert, will you post to some online album a 'selfie' with that uncooked egg
running down your cheeks? We could use a laugh around here. <SMILE>
To all: enjoy this occasion -- it's rare enough to be 'quite remarkable'
when Albert posts in error. On the other hand, I'd have said the same. And,
also on the other hand, I've been using Access since version 1.0, and have
cranked out a lot of code without ever using a VBA variable in the
properties of a control. There have been times that I set a control (usu. a
textbox) to the value of a variable... but the variable was in code, or a
function, or ???.
--
Larry Linson
Microsoft
"Albert D. Kallal" <PleaseNOS...@msn.com> wrote in message
news:d13tu.15062$tR7....@fx22.iad...
> "Ulrich M�ller" wrote in message news:l928ca$v6t$1...@dont-email.me...
running down your cheeks? We could use a laugh around here. <SMILE>
To all: enjoy this occasion -- it's rare enough to be 'quite remarkable'
when Albert posts in error. On the other hand, I'd have said the same. And,
also on the other hand, I've been using Access since version 1.0, and have
cranked out a lot of code without ever using a VBA variable in the
properties of a control. There have been times that I set a control (usu. a
textbox) to the value of a variable... but the variable was in code, or a
function, or ???.
--
Larry Linson
Microsoft
"Albert D. Kallal" <PleaseNOS...@msn.com> wrote in message
news:d13tu.15062$tR7....@fx22.iad...
> "Ulrich M�ller" wrote in message news:l928ca$v6t$1...@dont-email.me...
Greg (codepug@gmail.com)
Dec 20, 2013, 11:37:56 PM12/20/13
to
Thank you Albert.
I consider myself strangely privileged to have elicited your ire and interest, and that of the other gurus.
Your expertise and character precedes you. Keep up the great work!
You have another new fan.
Greg
Albert D. Kallal
Dec 23, 2013, 3:00:58 AM12/23/13
to
"Access Developer" wrote in message
news:bhk9bd...@mid.individual.net...
>Albert, will you post to some online album a 'selfie' with that uncooked
>egg running down your cheeks? We could use a laugh around here. <SMILE>
Actually, I could post a link to a picture in which I was tricked in blowing
a big French horn that wraps around 270 to my face.
The problem is they filled the horn with baking flour before they handed it
to me and told me to blow as hard as I can!
We were skiing and at this Bar they told me if I can blow this horn as hard
as possible and the horn makes a loud sound I get a big free picture of
beer!!
And yes the flour flew out like a huge white cloud exploding on my face!
The whole bar was on the floor in in absolute stitches all laughing at me.
Apparently they play this trick often on unsuspecting fools who are new to
town!
This is down in a Bar in Kalispell - called Moose's Saloon I believe!
I was down there skiing with a bunch of friends at Big Mountain
picture here:
https://skydrive.live.com/redir?resid=B18A57CB5F6AF0FA!1553&authkey=!ADn0pwj_xcwYdHI&v=3&ithint=photo%2c.jpg
Kind of wish someone had a picture of me holding this big horn RIGHT before
I blew as hard as I can!!
Anway, it was fun to have everyone laugh - a great memory on my part!
>To all: enjoy this occasion -- it's rare enough to be 'quite remarkable'
>when Albert posts in error.
I think it even MORE important s how one reacts when shown to be wrong!
If we not open to being wrong then we NOT open to learning!
To you and all there: All the best during this season.
Best regards,
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
PleaseNoS...@msn.com
news:bhk9bd...@mid.individual.net...
>Albert, will you post to some online album a 'selfie' with that uncooked
>egg running down your cheeks? We could use a laugh around here. <SMILE>
a big French horn that wraps around 270 to my face.
The problem is they filled the horn with baking flour before they handed it
to me and told me to blow as hard as I can!
We were skiing and at this Bar they told me if I can blow this horn as hard
as possible and the horn makes a loud sound I get a big free picture of
beer!!
And yes the flour flew out like a huge white cloud exploding on my face!
The whole bar was on the floor in in absolute stitches all laughing at me.
Apparently they play this trick often on unsuspecting fools who are new to
town!
This is down in a Bar in Kalispell - called Moose's Saloon I believe!
I was down there skiing with a bunch of friends at Big Mountain
picture here:
https://skydrive.live.com/redir?resid=B18A57CB5F6AF0FA!1553&authkey=!ADn0pwj_xcwYdHI&v=3&ithint=photo%2c.jpg
Kind of wish someone had a picture of me holding this big horn RIGHT before
I blew as hard as I can!!
Anway, it was fun to have everyone laugh - a great memory on my part!
>To all: enjoy this occasion -- it's rare enough to be 'quite remarkable'
>when Albert posts in error.
If we not open to being wrong then we NOT open to learning!
To you and all there: All the best during this season.
Best regards,
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
PleaseNoS...@msn.com
tamcq...@gmail.com
Mar 1, 2014, 9:51:46 PM3/1/14
to
I am also currently using Access 2010, and #Name? also shows in my textboxes.
In the past versions, I just put =[Surname]+", "+[First Name]+" "+[Middle Name] using the expression builder in the Control Source. However, #Name? now shows in Form view.
I'm no IT expert. I'm trying to understand the options posted in this thread but to no avail. Could anyone here help me with this and provide an actual solution for this particular problem. Minus the jargon please. Thanks!
In the past versions, I just put =[Surname]+", "+[First Name]+" "+[Middle Name] using the expression builder in the Control Source. However, #Name? now shows in Form view.
I'm no IT expert. I'm trying to understand the options posted in this thread but to no avail. Could anyone here help me with this and provide an actual solution for this particular problem. Minus the jargon please. Thanks!
Phil
Mar 2, 2014, 4:29:19 AM3/2/14
to
space after each word.
=Surname & ", " & [First Name] &" " & [Middle Name]
Incidentally, If you have a space in a field name, then you need the [] round
it, which is an unnecessary complication
FirstName and MiddleName is just as easy to understand
Phil
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
David Hare-Scott
Mar 2, 2014, 2:28:09 AM3/2/14
to
expression directly from the builder to a post here.
D
da...@ghaea.org
Nov 1, 2015, 12:51:44 AM11/1/15
to
--
_______________________________________________________________
*This e-mail (including attachments) is covered **by the Electronic
Communication Privacy Act, 18 U.S.C. 2510-2521, and is confidential. **In
addition, any student related information contained in this e-mail
(including attachments) **is protected by the Family Educational Rights and
Privacy Act of 1994. **If you are not the intended recipient, you are
hereby notified that **any retention, dissemination, distribution or
copying of this communication is strictly prohibited. **Please reply to the
sender that you have received this message in error, then delete it. Thank
you.*
Patrick Finucane
Nov 1, 2015, 12:05:59 PM11/1/15
to
=Tempvars!MyVar.value
will work just fine. They work fine in queries as well
0 new messages