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. |
|
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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 | |
|
|