A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Using Forms
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

To vbProper or not to vbProper



 
 
Thread Tools Display Modes
  #1  
Old January 22nd, 2006, 03:33 AM posted to microsoft.public.access.forms
external usenet poster
 
Posts: n/a
Default To vbProper or not to vbProper

Hello,
This is my first post on this forum, so bare with me.
I am trying to code a form., but having problems getting the results in the
way I want.......
My problem is with a vbProper setting... But this could actually be used for
any function that executes on the AfterUpdate. But I'll use the vbProper for
my example. So I have the function to capitalize each word when you tab off
of a field by calling the function on the AfterUpdate. BUT, there are times
when you want the user to be able to move to the next field without executing
the called function therefor leaving the text just as it was typed.
So what I am looking for is a way to code another key, perhaps a function key,
to tab from field to field, on the tab stops you set, without calling the
vbproper function.
Hope I'm making sense
A short example.........Tab or "Other Key"
With Tab
Your on field one.....
You type "ABC Company" then tab...
Moves to field two, field one changes to "Abc Company"
With "other Key" ......say "F10"
Your on field one...
You type "ABC Company" then "F10"
Moves to field two, field one remains "ABC Company"

The more I think about this putting the code on the Afterupdate event might
not be best... But I'm open to any suggestions.

Any thoughts on how to code this?
Thanks
  #2  
Old January 22nd, 2006, 04:27 AM posted to microsoft.public.access.forms
external usenet poster
 
Posts: n/a
Default To vbProper or not to vbProper

Curtis,

The After Update event of the control will fire regardless of how you
move the focus off it.

The purpose here is to "manually" control whether the data is modified
by the code. Am I right? So your thought was to manually control this
via the key used to tab from the control, right? How about this idea
instead... Place a checkbox (probably unbound) on the form, next to the
control, maybe labelled something like 'Retain as entered'. If you know
you are about to enter data which you do not want converted to proper
case, such as "ABC Company", tick the checkbox before entering the data.
Then, your After Update code could be something like this...

If Me.NameOfCheckbox Then
Me.NameOfCheckbox = 0
Else
Me.NameOfTextbox = StrConv(Me.NameOfTextbox, 3)
End If

Here would be another approach... Set a form-level variable to store the
value of the control as entered, before the string conversion takes
place. So your control's After Update code is like this...

YourStringVariable = Me.NameOfTextbox
Me.NameOfTextbox = StrConv(Me.NameOfTextbox, 3)

And then, have a little Command Button next to the control, which you
can click to revert back to the text as entered, via code something like
this...
Me.NameOfTextbox = YourStringVariable

--
Steve Schapel, Microsoft Access MVP


Curtis wrote:
Hello,
This is my first post on this forum, so bare with me.
I am trying to code a form., but having problems getting the results in the
way I want.......
My problem is with a vbProper setting... But this could actually be used for
any function that executes on the AfterUpdate. But I'll use the vbProper for
my example. So I have the function to capitalize each word when you tab off
of a field by calling the function on the AfterUpdate. BUT, there are times
when you want the user to be able to move to the next field without executing
the called function therefor leaving the text just as it was typed.
So what I am looking for is a way to code another key, perhaps a function key,
to tab from field to field, on the tab stops you set, without calling the
vbproper function.
Hope I'm making sense
A short example.........Tab or "Other Key"
With Tab
Your on field one.....
You type "ABC Company" then tab...
Moves to field two, field one changes to "Abc Company"
With "other Key" ......say "F10"
Your on field one...
You type "ABC Company" then "F10"
Moves to field two, field one remains "ABC Company"

The more I think about this putting the code on the Afterupdate event might
not be best... But I'm open to any suggestions.

Any thoughts on how to code this?
Thanks

  #3  
Old January 23rd, 2006, 02:26 AM posted to microsoft.public.access.forms
external usenet poster
 
Posts: n/a
Default To vbProper or not to vbProper

I'm sure this would work..... But.......... Not as simple as I want.
I currently work with some software that does this, using the Tab key and F10
keys. I know it was built in Access, so........ I know there is a way.
I think I might see if one of thier programers will tell me how they did it.

I have been playing with some code but it still has one error...... Maybe you
know why........

Private Sub Form_Load()
Me.KeyPreview = True
End Sub

Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
If KeyCode = vbKeyTab Then
Screen.ActiveControl = StrConv(Screen.ActiveControl, 3)
Else
End If
End Sub

This works when text is already in the field. For example, I created a simple
DB with one form two text fields.
Type into field one, press enter, moves to field two leaves field one as
typed. BUT if you type into field one and Tab to field two, it deltes text
from field one.
Once text is in records, you can tab or enter from field to field and it
changes accordingly.
SO..... Why is it deleting the text if you Tab on the first time??



Steve Schapel wrote:
Curtis,

The After Update event of the control will fire regardless of how you
move the focus off it.

The purpose here is to "manually" control whether the data is modified
by the code. Am I right? So your thought was to manually control this
via the key used to tab from the control, right? How about this idea
instead... Place a checkbox (probably unbound) on the form, next to the
control, maybe labelled something like 'Retain as entered'. If you know
you are about to enter data which you do not want converted to proper
case, such as "ABC Company", tick the checkbox before entering the data.
Then, your After Update code could be something like this...

If Me.NameOfCheckbox Then
Me.NameOfCheckbox = 0
Else
Me.NameOfTextbox = StrConv(Me.NameOfTextbox, 3)
End If

Here would be another approach... Set a form-level variable to store the
value of the control as entered, before the string conversion takes
place. So your control's After Update code is like this...

YourStringVariable = Me.NameOfTextbox
Me.NameOfTextbox = StrConv(Me.NameOfTextbox, 3)

And then, have a little Command Button next to the control, which you
can click to revert back to the text as entered, via code something like
this...
Me.NameOfTextbox = YourStringVariable

Hello,
This is my first post on this forum, so bare with me.

[quoted text clipped - 25 lines]
Any thoughts on how to code this?
Thanks


--
Message posted via http://www.accessmonster.com
  #4  
Old January 23rd, 2006, 03:35 AM posted to microsoft.public.access.forms
external usenet poster
 
Posts: n/a
Default To vbProper or not to vbProper

No problem, Curtis. Apparently you and I have different idea of what
"simple" means :-).

The problem here is that you are trying to change the value of a control
before the value has been updated into the control. So in the case of
your new record, at the point where you press the Tab key, the value of
the control is Null, and converting Null to proper case still leaves you
with Null. I have no idea whether this will work or not, but should be
easy to test... try it like this:
If KeyCode = vbKeyTab Then
Me.Dirty = False
Screen.ActiveControl = StrConv(Screen.ActiveControl, 3)
End If

Another idea...
If KeyCode = vbKeyTab Then
Screen.ActiveControl.Text = StrConv(Screen.ActiveControl.Text, 3)
End If

Otherwise, we'll try and think of something else!

--
Steve Schapel, Microsoft Access MVP


Curtis via AccessMonster.com wrote:
I'm sure this would work..... But.......... Not as simple as I want.
I currently work with some software that does this, using the Tab key and F10
keys. I know it was built in Access, so........ I know there is a way.
I think I might see if one of thier programers will tell me how they did it.

I have been playing with some code but it still has one error...... Maybe you
know why........

Private Sub Form_Load()
Me.KeyPreview = True
End Sub

Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
If KeyCode = vbKeyTab Then
Screen.ActiveControl = StrConv(Screen.ActiveControl, 3)
Else
End If
End Sub

This works when text is already in the field. For example, I created a simple
DB with one form two text fields.
Type into field one, press enter, moves to field two leaves field one as
typed. BUT if you type into field one and Tab to field two, it deltes text
from field one.
Once text is in records, you can tab or enter from field to field and it
changes accordingly.
SO..... Why is it deleting the text if you Tab on the first time??

  #5  
Old January 23rd, 2006, 10:29 PM posted to microsoft.public.access.forms
external usenet poster
 
Posts: n/a
Default To vbProper or not to vbProper

Bingo!
The Me.Dirty = False
Does the trick. Now you click "Tab" to change to proper case "Enter" to leave
as typed.
Now THATS what I call simple
Thank you very much! This one has been frustrating!



Steve Schapel wrote:
No problem, Curtis. Apparently you and I have different idea of what
"simple" means :-).

The problem here is that you are trying to change the value of a control
before the value has been updated into the control. So in the case of
your new record, at the point where you press the Tab key, the value of
the control is Null, and converting Null to proper case still leaves you
with Null. I have no idea whether this will work or not, but should be
easy to test... try it like this:
If KeyCode = vbKeyTab Then
Me.Dirty = False
Screen.ActiveControl = StrConv(Screen.ActiveControl, 3)
End If

Another idea...
If KeyCode = vbKeyTab Then
Screen.ActiveControl.Text = StrConv(Screen.ActiveControl.Text, 3)
End If

Otherwise, we'll try and think of something else!

I'm sure this would work..... But.......... Not as simple as I want.
I currently work with some software that does this, using the Tab key and F10

[quoted text clipped - 23 lines]
changes accordingly.
SO..... Why is it deleting the text if you Tab on the first time??


--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...forms/200601/1
  #6  
Old January 23rd, 2006, 10:36 PM posted to microsoft.public.access.forms
external usenet poster
 
Posts: n/a
Default To vbProper or not to vbProper

One more question on this so I understand it correctly........
The Me.Dirty = False
This is telling the record has not been changed? So does it force access to
save it before running the next line of code?

Thanks again
Curtis



Curtis wrote:
Bingo!
The Me.Dirty = False
Does the trick. Now you click "Tab" to change to proper case "Enter" to leave
as typed.
Now THATS what I call simple
Thank you very much! This one has been frustrating!

No problem, Curtis. Apparently you and I have different idea of what
"simple" means :-).

[quoted text clipped - 22 lines]
changes accordingly.
SO..... Why is it deleting the text if you Tab on the first time??


--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...forms/200601/1
  #7  
Old January 23rd, 2006, 10:46 PM posted to microsoft.public.access.forms
external usenet poster
 
Posts: n/a
Default To vbProper or not to vbProper

Curtis,

Curtis via AccessMonster.com wrote:
... So does it force access to
save it before running the next line of code?


Exactly!

--
Steve Schapel, Microsoft Access MVP
  #8  
Old January 23rd, 2006, 11:01 PM posted to microsoft.public.access.forms
external usenet poster
 
Posts: n/a
Default To vbProper or not to vbProper

Lovely! Poetry in motion, eh?

I would be interested in knowing if my idea using the .Text property
would also solve the problem.

--
Steve Schapel, Microsoft Access MVP


Curtis via AccessMonster.com wrote:
Bingo!
The Me.Dirty = False
Does the trick. Now you click "Tab" to change to proper case "Enter" to leave
as typed.
Now THATS what I call simple
Thank you very much! This one has been frustrating!

  #9  
Old January 24th, 2006, 12:06 AM posted to microsoft.public.access.forms
external usenet poster
 
Posts: n/a
Default To vbProper or not to vbProper

Yes, this works also.
But I'm not sure why
You specify the control to be text? So why would that work and not without it?


And now.......... Which is better to use?




Steve Schapel wrote:
Lovely! Poetry in motion, eh?

I would be interested in knowing if my idea using the .Text property
would also solve the problem.

Bingo!
The Me.Dirty = False
Does the trick. Now you click "Tab" to change to proper case "Enter" to leave
as typed.
Now THATS what I call simple
Thank you very much! This one has been frustrating!


--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...forms/200601/1
  #10  
Old January 24th, 2006, 12:34 AM posted to microsoft.public.access.forms
external usenet poster
 
Posts: n/a
Default To vbProper or not to vbProper

Curtis,

Curtis via AccessMonster.com wrote:
Yes, this works also.


Ok, thanks for confirmation... saves me having to set up a test case :-).

But I'm not sure why
You specify the control to be text? So why would that work and not without it?


The default property of a control is the Value property. So...
Screen.ActiveControl = Screen.ActiveControl.Value
The Value of a control is the data after it has been updated into the
control.
On the other hand, the Text property relates to the data currently
displayed in the control, so
Screen.ActiveControl.Text
should give you the data you have typed in, even though this has not
been saved.

And now.......... Which is better to use?


The .Text approach will only work if the control has the focus at the
time. The .Dirty approach would be awkward if you didn't want the
record saved for some reason, for example data "required" in a field
that you hadn't got to yet, or some such. Other than that, I can't
think of much to choose between them.

--
Steve Schapel, Microsoft Access MVP
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 01:05 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.