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  

Show code meaning rather than code value



 
 
Thread Tools Display Modes
  #11  
Old February 10th, 2010, 05:58 PM posted to microsoft.public.access.forms
Jeff Boyce
external usenet poster
 
Posts: 8,621
Default Show code meaning rather than code value

Alternate reasons (other than offending the gods) ... (since the folks who
respond here are volunteering their time) ...

1) nobody's home
2) nobody knows
3) nobody's available ("busy helping other customers"...)

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

"oldblindpew" wrote in message
...
Thanks for reading and replying. I fear I've offended the gods as some of
my
recent questions have met with silence.

When a new record is added via my form, some of the fields are populated
from other tables, and this is the data I wish to protect. The key
question
is whether the Before Update event will interfere with the addition of the
new record and automatic population of certain of its fields. Should be
easy
enough to try and see. I have not yet needed the different events other
than
On Click.

In the past I've created a separate form for updating vs. adding. I'm
thinking one cannot simultaneously allow and disallow editing in the same
form. Perhaps this is why a traditional approach uses modes: Add, Delete,
Update, and Browse. Obviously I have more to learn.

Thanks Again,
Pew

"AccessVandal via AccessMonster.com" wrote:

oldblindpew wrote:
I also mentioned locking the controls, but this isn't right either.
When I
lock the control, no data can be enterered at all. I don't want to
completely prevent data entry, but I just don't want the user to
accidentally
change anything.


You can use the Textbox beforeupdate event to cancel the input. Like

Private Sub Text1_BeforeUpdate(Cancel as Interger)
If Me.Text1.OldValue Me.Text1 Then
msgbox "You can't change the value"
me.text1.undo
Cancel = True
Else
' do nothing
End If
End Sub

You might also want to deal with the Form's Dirty property.

--
Please Rate the posting if helps you.

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...forms/201002/1

.



  #12  
Old February 10th, 2010, 07:26 PM posted to microsoft.public.access.forms
oldblindpew
external usenet poster
 
Posts: 128
Default Show code meaning rather than code value

Sorry, I forget that tongue-in-cheek comments often don't come across as
intended.
Pew

"Jeff Boyce" wrote:

Alternate reasons (other than offending the gods) ... (since the folks who
respond here are volunteering their time) ...

1) nobody's home
2) nobody knows
3) nobody's available ("busy helping other customers"...)

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

"oldblindpew" wrote in message
...
Thanks for reading and replying. I fear I've offended the gods as some of
my
recent questions have met with silence.

When a new record is added via my form, some of the fields are populated
from other tables, and this is the data I wish to protect. The key
question
is whether the Before Update event will interfere with the addition of the
new record and automatic population of certain of its fields. Should be
easy
enough to try and see. I have not yet needed the different events other
than
On Click.

In the past I've created a separate form for updating vs. adding. I'm
thinking one cannot simultaneously allow and disallow editing in the same
form. Perhaps this is why a traditional approach uses modes: Add, Delete,
Update, and Browse. Obviously I have more to learn.

Thanks Again,
Pew

"AccessVandal via AccessMonster.com" wrote:

oldblindpew wrote:
I also mentioned locking the controls, but this isn't right either.
When I
lock the control, no data can be enterered at all. I don't want to
completely prevent data entry, but I just don't want the user to
accidentally
change anything.

You can use the Textbox beforeupdate event to cancel the input. Like

Private Sub Text1_BeforeUpdate(Cancel as Interger)
If Me.Text1.OldValue Me.Text1 Then
msgbox "You can't change the value"
me.text1.undo
Cancel = True
Else
' do nothing
End If
End Sub

You might also want to deal with the Form's Dirty property.

--
Please Rate the posting if helps you.

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...forms/201002/1

.



.

  #13  
Old February 11th, 2010, 01:58 AM posted to microsoft.public.access.forms
AccessVandal via AccessMonster.com
external usenet poster
 
Posts: 461
Default Show code meaning rather than code value

What you have asked might be difficult to answer. The sample code I gave
should fire up the BeforeUpdate event of your control even if the auto-fill
is in the new record and if the control is being edited it should fire up the
control event. But I'm not certain of how your auto-fill works like - does
the record is save first? If it is, it should work.

The best way to learn is to do a trail and error.

oldblindpew wrote:
Thanks for reading and replying. I fear I've offended the gods as some of my
recent questions have met with silence.

When a new record is added via my form, some of the fields are populated
from other tables, and this is the data I wish to protect. The key question
is whether the Before Update event will interfere with the addition of the
new record and automatic population of certain of its fields. Should be easy
enough to try and see. I have not yet needed the different events other than
On Click.

In the past I've created a separate form for updating vs. adding. I'm
thinking one cannot simultaneously allow and disallow editing in the same
form. Perhaps this is why a traditional approach uses modes: Add, Delete,
Update, and Browse. Obviously I have more to learn.

Thanks Again,
Pew


--
Please Rate the posting if helps you.

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...forms/201002/1

  #14  
Old February 11th, 2010, 02:23 AM posted to microsoft.public.access.forms
AccessVandal via AccessMonster.com
external usenet poster
 
Posts: 461
Default Show code meaning rather than code value

As for the hiding of the combobox button, you can't hide it but you can make
it invisible.

1. Create a textbox and in the properties make it invisible or if you would
prefer make the combobox invisible. (both control is bound to the same
controlsource, you may need to modify your auto-fill)

2. Make both the textbox and combobox the same width and height and put them
in the same position in the Form. The trick here is to make them visible with
your form's current event and combobox event, so that the correct control
will always be visible.

If isnull(combobox) then
' do nothing
else
' make textbox visible and combobox invisible
end if

oldblindpew wrote:
Thanks for reading and replying. I fear I've offended the gods as some of my
recent questions have met with silence. snip...


--
Please Rate the posting if helps you.

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...forms/201002/1

  #15  
Old February 11th, 2010, 05:22 PM posted to microsoft.public.access.forms
Jeff Boyce
external usenet poster
 
Posts: 8,621
Default Show code meaning rather than code value

I tend to use TIC marks for that... G!

Jeff B.

"oldblindpew" wrote in message
...
Sorry, I forget that tongue-in-cheek comments often don't come across as
intended.
Pew

"Jeff Boyce" wrote:

Alternate reasons (other than offending the gods) ... (since the folks
who
respond here are volunteering their time) ...

1) nobody's home
2) nobody knows
3) nobody's available ("busy helping other customers"...)

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

"oldblindpew" wrote in message
...
Thanks for reading and replying. I fear I've offended the gods as some
of
my
recent questions have met with silence.

When a new record is added via my form, some of the fields are
populated
from other tables, and this is the data I wish to protect. The key
question
is whether the Before Update event will interfere with the addition of
the
new record and automatic population of certain of its fields. Should
be
easy
enough to try and see. I have not yet needed the different events
other
than
On Click.

In the past I've created a separate form for updating vs. adding. I'm
thinking one cannot simultaneously allow and disallow editing in the
same
form. Perhaps this is why a traditional approach uses modes: Add,
Delete,
Update, and Browse. Obviously I have more to learn.

Thanks Again,
Pew

"AccessVandal via AccessMonster.com" wrote:

oldblindpew wrote:
I also mentioned locking the controls, but this isn't right either.
When I
lock the control, no data can be enterered at all. I don't want to
completely prevent data entry, but I just don't want the user to
accidentally
change anything.

You can use the Textbox beforeupdate event to cancel the input. Like

Private Sub Text1_BeforeUpdate(Cancel as Interger)
If Me.Text1.OldValue Me.Text1 Then
msgbox "You can't change the value"
me.text1.undo
Cancel = True
Else
' do nothing
End If
End Sub

You might also want to deal with the Form's Dirty property.

--
Please Rate the posting if helps you.

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...forms/201002/1

.



.



  #16  
Old February 11th, 2010, 08:16 PM posted to microsoft.public.access.forms
oldblindpew
external usenet poster
 
Posts: 128
Default Show code meaning rather than code value

Dear self,

To use a Text Box to display the Code's Meaning from a separate Lookup
Table, just go to the Query Builder for the form's Record Source, click on
Show Table, and add the Lookup Table.

Next, create a link between the Lookup Table's Code field and the
corresponding field in the child table. This relationship is only used in
the query, and will not affect the relationships shown under Database Tools
/Relationships.

Next, add the Code and Meaning fields from the Lookup Table to your query,
(or just specify all fields, since there are only the two).

Finally, specify the Meaning field's name as your Control Source for the
Text Box in your form.

Best of Luck,
OldBlindPew

"oldblindpew" wrote:

Jeff, thanks for replying.

I have a lookup table with two fields: Code and Meaning. Sample values
would be "A" and "Active", respectively.

My child table has a field for the Code as a foreign key, but I want my
form's textbox to show Meaning rather than Code, e.g. "Active" rather than
"A". As stated previously, I know a Combo Box will do this, and I know how
to make it work, so this was not my question. My question is how to do it
with a Text Box.

My reason for wanting a Text Box is aesthetic. In my form, this control
will be display-only. I don't see any point in presenting a non-functional
Combo Box to the user. In fact, I think a locked Combo Box should change
appearance to look like a locked Text Box. If it's locked (read-only) why
should there even be a down arrow/selector button followed by a drop-down
pick list, which the user is not going to be able to use anyway?

Thanks,
Pew

"Jeff Boyce" wrote:

Not sure how you're using the term "meaning"...

Are you saying you have a table somewhere that has a couple of fields, a
code and a "meaning" (is that the same as a title, or description or ...)?
And that you want to see that second part instead of the code?

Then yes, a combobox can do that quite easily.

First build a query that returns both code and "...". Then base your
combobox on that query.

In the design view, highlight the combobox, and set 2 columns, and set the
width of the first column (i.e., the code) to 0 (zero).

Now when you use the combobox, the code is what the combobox is storing in
the underlying field, but the "..." is what it is displaying in the form.

Good luck!

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

"oldblindpew" wrote in message
...
I have a text box in a form that is displaying (as it should) the value of
a
code that is stored in the bound field (hope I'm saying this right). I
want
to display the code's meaning rather than its value.

I know a combo box would do it, and I'll use one if I have to, but I only
want to display the meaning, whereas a combo box is for picking a value.

Thanks,
OldBlindPew



.

 




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 08:11 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.