Access form changes the case of the letter "i" to "I" (capitalizes)

[MLH]

I have a textbox control used to enter a single
alphanumeric character. It changes the case
of "i" to upper case. But it does not do so with
the letter "g". Its left as "g" - not changed to "G"?

Although Access's attempts at keeping me
gramatically correct, it isn't helping me in this
particular case. Can I turn that behavior off
at will - on a case-by-case basis?

[fredg]

On Fri, 17 Jun 2005 14:36:54 -0400, MLH wrote:

I have a textbox control used to enter a single
alphanumeric character. It changes the case
of "i" to upper case. But it does not do so with
the letter "g". Its left as "g" - not changed to "G"?

Although Access's attempts at keeping me
gramatically correct, it isn't helping me in this
particular case. Can I turn that behavior off
at will - on a case-by-case basis?

Your input "i" is being corrected to "I" by AutoCorrect.
To stop that from occurring either
1) set that controls AllowAutoCorrect property to No (only that
control is affected).
or
2) deleting that item from
Tools + AutoCorrect Options
as well as unchecking the Capitalize first letter of sentences box
(which will affect all Office applications).
--
Fred
Please only reply to this newsgroup.
I do not reply to personal email.

[David W. Fenton]

fredg <fg******@example.invalid> wrote in
news:cn******************************@40tude.net:

On Fri, 17 Jun 2005 14:36:54 -0400, MLH wrote:

I have a textbox control used to enter a single
alphanumeric character. It changes the case
of "i" to upper case. But it does not do so with
the letter "g". Its left as "g" - not changed to "G"?

Although Access's attempts at keeping me
gramatically correct, it isn't helping me in this
particular case. Can I turn that behavior off
at will - on a case-by-case basis?

Your input "i" is being corrected to "I" by AutoCorrect.
To stop that from occurring either
1) set that controls AllowAutoCorrect property to No (only that
control is affected).
or
2) deleting that item from
Tools + AutoCorrect Options
as well as unchecking the Capitalize first letter of sentences box
(which will affect all Office applications).

This is another example of a "feature" put into Access by people who
have absolutely no comprehension of what a database is for.
AutoCorrect adds a level of intervention between the user and the
data store that is controlled externally, and a developer cannot be
certain what will be in the AutoCorrect list.

This is another candidate for a subroutine that opens all the forms
in an MDB, walks through the Controls collection and sets the
AllowAutoCorrect property to FALSE. I can't see every using this
property myself, but if they provided it, they should have set it
OFF by default. And the property should not even exist at all for
controls that are designed for the purpose of validating data, such
as combo boxes.

This is an example of the kind of complete idiocy that Microsoft
produces because their product design is often driven more by
marketing than by technical requirements. Default Autocorrect
violates every principle of how a database application should work.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[MLH]

<censored>
I agree with you, David. Is there a way to change the default setting
to Off - maybe some kind of option setting???

This is another candidate for a subroutine that opens all the forms
in an MDB, walks through the Controls collection and sets the
AllowAutoCorrect property to FALSE. I can't see every using this
property myself, but if they provided it, they should have set it
OFF by default. And the property should not even exist at all for
controls that are designed for the purpose of validating data, such
as combo boxes.

<censored>

[MLH]

AaaaHaaa! Very sneaky. OK, though. Was able to
fix it. At least this behavior can be turned on/off at
the control level. Whew! I have a lot of controls!
Not all of them will be adversely affected by the
self-imposed automation. But I'll still have to look
at 'em all to determine even that much. Oh well.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

On Fri, 17 Jun 2005 20:16:47 GMT, fredg <fg******@example.invalid>
wrote:

On Fri, 17 Jun 2005 14:36:54 -0400, MLH wrote:

I have a textbox control used to enter a single
alphanumeric character. It changes the case
of "i" to upper case. But it does not do so with
the letter "g". Its left as "g" - not changed to "G"?

Although Access's attempts at keeping me
gramatically correct, it isn't helping me in this
particular case. Can I turn that behavior off
at will - on a case-by-case basis?

Your input "i" is being corrected to "I" by AutoCorrect.
To stop that from occurring either
1) set that controls AllowAutoCorrect property to No (only that
control is affected).
or
2) deleting that item from
Tools + AutoCorrect Options
as well as unchecking the Capitalize first letter of sentences box
(which will affect all Office applications).

[David W. Fenton]

MLH <CR**@NorthState.net> wrote in
news:a1********************************@4ax.com:

This is another candidate for a subroutine that opens all the
forms in an MDB, walks through the Controls collection and sets
the AllowAutoCorrect property to FALSE. I can't see every using
this property myself, but if they provided it, they should have
set it OFF by default. And the property should not even exist at
all for controls that are designed for the purpose of validating
data, such as combo boxes.

I agree with you, David. Is there a way to change the default
setting to Off - maybe some kind of option setting???

No, there's no global option. It's something you have to set for
every control with an editable textbox. That means combo boxes and
text boxes.

The code to do this is pretty simple:

Public Sub GetRidOfAutoCorrect()
' Turns off AutoCorrect for all text boxes and combo boxes
' on all forms in an MDB
Dim cnt As DAO.Container
Dim doc As DAO.Document
Dim strForm As String
Dim ctl As Control

For Each cnt In CurrentDB.Containers
If cnt.Name = "Forms" Then
For Each doc In cnt.Documents
strForm = doc.Name
DoCmd.OpenForm strForm, acDesign
For Each ctl In Forms(strForm).Controls
If ctl.ControlType = acTextBox _
Or ctl.ControlType = acComboBox Then
ctl.AllowAutoCorrect = False
End If
Next ctl
DoCmd.Close acForm, strForm, acSaveYes
Next doc
End If
Next cnt

Set cnt = Nothing
Set doc = Nothing
Set ctl = Nothing
End Sub

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Bas Cost Budde]

David W. Fenton wrote:

For Each cnt In CurrentDB.Containers
If cnt.Name = "Forms" Then

Funny, why do you do this with foreach? Just curious

--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html

[Trevor Best]

Bas Cost Budde wrote:

David W. Fenton wrote:

For Each cnt In CurrentDB.Containers
If cnt.Name = "Forms" Then

Funny, why do you do this with foreach? Just curious

Perhaps it saves him declaring a db variable and clearing it up after as
you'd need one to set cnt to db.containers("Forms") as using CurrentDb
directly has the potential to go out of scope straight after using it.

--
[OO=00=OO]

[Bas Cost Budde]

Trevor Best wrote:

Perhaps it saves him declaring a db variable and clearing it up after as
you'd need one to set cnt to db.containers("Forms") as using CurrentDb
directly has the potential to go out of scope straight after using it.

uh-huh, that's true. So CurrentDb doesn't go out of scope because it's
referenced in a loop structure? Great.
--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html

[David W. Fenton]

Bas Cost Budde <b.*********@heuvelqop.nl> wrote in
news:d9**********@localhost.localdomain:

Trevor Best wrote:

Perhaps it saves him declaring a db variable and clearing it up
after as you'd need one to set cnt to db.containers("Forms") as
using CurrentDb directly has the potential to go out of scope
straight after using it.

uh-huh, that's true. So CurrentDb doesn't go out of scope because
it's referenced in a loop structure? Great.

Well, the alternative to a For/Each loop is a counter, and that
requires declaring a variable, then knowing the index base for the
collection. A For/Each loop using the data type of the items within
the collection eliminates any need to know all of that.

The counter-based loop could also use the direct reference to the
collection without needing to instantiate a variable for it.

The nested For/Each loops in my code require a variable declaration
only for the object types used in the For/Each construct. That seems
to me to be efficient coding.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Bas Cost Budde]

David W. Fenton wrote:

Well, the alternative to a For/Each loop is a counter, and that
requires declaring a variable, then knowing the index base for the
collection. A For/Each loop using the data type of the items within
the collection eliminates any need to know all of that.

The counter-based loop could also use the direct reference to the
collection without needing to instantiate a variable for it.

The nested For/Each loops in my code require a variable declaration
only for the object types used in the For/Each construct. That seems
to me to be efficient coding.

Great. I see that.
Does it outweigh the performance issue linked to performing the test n-1
times?

--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html

[David W. Fenton]

Bas Cost Budde <b.*********@heuvelqop.nl> wrote in
news:d9**********@localhost.localdomain:

David W. Fenton wrote:

Well, the alternative to a For/Each loop is a counter, and that
requires declaring a variable, then knowing the index base for
the collection. A For/Each loop using the data type of the items
within the collection eliminates any need to know all of that.

The counter-based loop could also use the direct reference to the
collection without needing to instantiate a variable for it.

The nested For/Each loops in my code require a variable
declaration only for the object types used in the For/Each
construct. That seems to me to be efficient coding.

Great. I see that.
Does it outweigh the performance issue linked to performing the
test n-1 times?

Eh? With a For/Each loop you don't care about the index base of the
collection, so there's no calculation required to determine N-1 (and
some collections are *not* 0-based). It runs exactly as many times
as the .Count of the collection indicates -- it's built into the
structure to do that.

So, basically, I have no idea whatsoever what question you're
asking!

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Bas Cost Budde]

David W. Fenton wrote:

Eh? With a For/Each loop you don't care about the index base of the
collection, so there's no calculation required to determine N-1 (and
some collections are *not* 0-based). It runs exactly as many times
as the .Count of the collection indicates -- it's built into the
structure to do that.

So, basically, I have no idea whatsoever what question you're
asking!

Grin. I apologize for being far too short-worded.

Inside the For...Each, which runs .Count times indeed, you test for a
name that we expect to occur only once. That means you flush .Count-1
passes of the For. This, I expect, eats up a little time.

Describing this, I feel the extra time involved may shrink to nothing
compared to the assignments you would need in the other scenario.
Especially since the Containers collection is fairly small.

Thanks for listening to me, then. :-)
--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html

[David W. Fenton]

Bas Cost Budde <b.*********@heuvelqop.nl> wrote in
news:d9**********@localhost.localdomain:

David W. Fenton wrote:

Eh? With a For/Each loop you don't care about the index base of
the collection, so there's no calculation required to determine
N-1 (and some collections are *not* 0-based). It runs exactly as
many times as the .Count of the collection indicates -- it's
built into the structure to do that.

So, basically, I have no idea whatsoever what question you're
asking!
Grin. I apologize for being far too short-worded.

Inside the For...Each, which runs .Count times indeed, you test
for a name that we expect to occur only once. That means you flush
.Count-1 passes of the For. This, I expect, eats up a little time.

Well, you could Exit the For, just as you can Exit Loops when you
are looking only for the first match:

Public Sub GetRidOfAutoCorrect()
' Turns off AutoCorrect for all text boxes and combo boxes
' on all forms in an MDB
Dim cnt As DAO.Container
Dim doc As DAO.Document
Dim strForm As String
Dim ctl As Control

For Each cnt In CurrentDB.Containers
If cnt.Name = "Forms" Then
For Each doc In cnt.Documents
strForm = doc.Name
DoCmd.OpenForm strForm, acDesign
For Each ctl In Forms(strForm).Controls
If ctl.ControlType = acTextBox _
Or ctl.ControlType = acComboBox Then
ctl.AllowAutoCorrect = False
End If
Next ctl
DoCmd.Close acForm, strForm, acSaveYes
Next doc
Exit For '<===============Exit here
End If
Next cnt

Set cnt = Nothing
Set doc = Nothing
Set ctl = Nothing
End Sub
Describing this, I feel the extra time involved may shrink to
nothing compared to the assignments you would need in the other
scenario. Especially since the Containers collection is fairly
small.

That's a reason for not bothering with it in the original code, but
I think it's better practice to exit a loop when you're looking for
a single match (or a first match).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc