I'm with you. I started a post yesterday but canceled it as I was the lone wolf at the time and figured I must be missing the point. I still don't see the point unless maybe this was for sight impaired users and the name of the field was being converted to speech, but that's not indicated. I started with "Isn't this what labels are for??"
But the code you added ALREADY would force you to release a new FE. Basically, there is almost no time (I did say "almost") that you want any code at all in the BE. The ONLY time I ever put code in the BE is to prevent anyone from directly opening it without me knowing about it. Everything else I did, I did from the FE and releasing a new FE isn't that much of a problem.
No, it would not. The OP is putting the hint table in the back end as far as i can tell
If you want tool tips instead of the message box then simply change the code to the following.
Code:
Public Function DisplayHint()
'Screen.ActiveControl.Parent.txtHint = DLookup("field_hint", "field_t", "field_name = """ & Screen.ActiveControl.ControlSource & """")
Screen.ActiveControl.ControlTipText = DLookup("field_hint", "field_t", "field_name = """ & Screen.ActiveControl.ControlSource & """")
End Function
I might not do it exactly like this, but I see a lot of utility. I can think of filling out financial forms where you would need a long discussion of what that field really is and where you get the data. I would probably have a double click for hint and a message comes up. But with the table idea you can this pop that message up anywhere in the db on a given field.
And what event will run the BE code to do this? Events are governed by actions of, and are in the context of, the FE. When the BE is opened implicitly, it doesn't run events in the same way that it would if you opened it directly. (I've tried.)
Don't care WHERE the data goes... the forms and their controls are elements of the FE because if you HAVE an FE, that is what you launched to GET to the BE data. THAT is what is in Workspace(0).
I have no idea what you are saying. The OP has a table of hints in the backend. If he needs to modify the hints for certain fields he goes to the backend and updates the hint. Maybe we are thinking two different things. Obviously he is not adding hints because that would infer adding fields. In that case you have to get a new FE/BE. What exactly are you talking about? I split the db. Changed field field_hint and guess what? A new message.
And what event will run the BE code to do this? Events are governed by actions of, and are in the context of, the FE. When the BE is opened implicitly, it doesn't run events in the same way that it would if you opened it directly. (I've tried.)
Don't care WHERE the data goes... the forms and their controls are elements of the FE because if you HAVE an FE, that is what you launched to GET to the BE data. THAT is what is in Workspace(0).
The hint is pulled from the table linked to the backend. So if any changes is needed to do, Ill just go to the table in the backend and change the hint of that existing field. No need to deploy a new front end version if I was to use control tips. And also, control tips have a max of 255 characters which is not enough. For this example, I used short text, but it’s basically long text.
Oh yes, this is exactly what I wanted to do, but not to scare you, I have over 400 fields, that will take too long to create extra label underneath, but thanks for this example. I will use it for another project where I have less field
No, it would not. The OP is putting the hint table in the back end as far as i can tell
If you want tool tips instead of the message box then simply change the code to the following.
Code:
Public Function DisplayHint()
'Screen.ActiveControl.Parent.txtHint = DLookup("field_hint", "field_t", "field_name = """ & Screen.ActiveControl.ControlSource & """")
Screen.ActiveControl.ControlTipText = DLookup("field_hint", "field_t", "field_name = """ & Screen.ActiveControl.ControlSource & """")
End Function
I might not do it exactly like this, but I see a lot of utility. I can think of filling out financial forms where you would need a long discussion of what that field really is and where you get the data. I would probably have a double click for hint and a message comes up. But with the table idea you can this pop that message up anywhere in the db on a given field.
I have thought about it too, but the user doesnt like to double click, then click ok every single time. They do nee the Hint to show up most of the time. I have over 400 fields with hint for this project, and I don't think any user remembers how to fill properly for all those 400 fields
Another approach that I use is to have an unbound label whose caption provides a hint when the user moves the mouse over a control. The caption font is large (20 pt) and a bright colour (magenta) so its easy to spot.
When the mouse moves away from the control the caption is reset to an empty string or hidden.
I prefer this to a textbox or tool tip as its faster and the appearance is customisable. It also doesn't disrupt program flow unlike a message box.
I have thought about it too, but the user doesnt like to double click, then click ok every single time. They do nee the Hint to show up most of the time. I have over 400 fields with hint for this project, and I don't think any user remembers how to fill properly for all those 400 fields
If you are going to do this throughout the db, then you will have different textboxes to display the hint. You may want to modify the code
Code:
Public Function DisplayHint(txtHint As TextBox)
On Error Resume Next
txtHint.Value = DLookup("field_hint", "field_t", "field_name = """ & Screen.ActiveControl.ControlSource & """")
End Function
then when you call it
=displayHint([txtboxname])
this would allow hints on a main and sub forms, or at least on different forms in different controls.
The purpose of populating the name of the control was for me to be able to use it for dlookup for that field name over another table. I wasn’t able to get that active name in order to do the dlookup. The 255 characters was to explain why I didn’t use control tips or status bar only. Now everything is solved now
If you are going to do this throughout the db, then you will have different textboxes to display the hint. You may want to modify the code
Code:
Public Function DisplayHint(txtHint As TextBox)
On Error Resume Next
txtHint.Value = DLookup("field_hint", "field_t", "field_name = """ & Screen.ActiveControl.ControlSource & """")
End Function
then when you call it
=displayHint([txtboxname])
this would allow hints on a main and sub forms, or at least on different forms in different controls.
Awesome!! This solve what I needed. At first, I put the hint textbox on the main form, but I wasn’t able to get the active field from
The subform, so I move it to the subform, now I can move it back to the main form awesome !
Awesome!! This solve what I needed. At first, I put the hint textbox on the main form, but I wasn’t able to get the active field from
The subform, so I move it to the subform, now I can move it back to the main form awesome
Actually not sure if you are doing like I set it up. I had a box on the main form and the subform. If you want one box you have to do like this. If the subform wants to display on the main form it would be like
=DisplayHint([Forms]![supplier_frm]![txtHint2])
where txtHint2 is on the main form.
But bottom line there is some available syntax to display the hint for a field either on the parent or on the subform, you just need to provide the correct syntax based on where the function is called and where the hint text box resides.
It's a real pain in the toches, but the way I did this to get the effect I think I am seeing was to put code in the GotFocus routine for each control that said, in effect,
Code:
[Hint]="Enter the person's full name"
(And for consistency, the LostFocus code set the [Hint] box to "".)
If you wanted this to be variable, do a DLookup there in the GotFocus routine. Look up whatever hint you need. But the more options you have, the more options you have that can fail individually.
If your problem is different locations for the [Hints] box, that is probably a fixed location for any given control even though many different controls can use many different [Hints] box. I.e. the same control will probably always use the same [Hints] box. If so, that makes it pretty much a static decision.
I must say that the implied "fluidity" of this design is confusing to me. I hope your users will take well to it.
Entity/Attribute type schema where each attribute wasn't a separate column in a table but in fact was a separate row. Tool tips are unobtrusive and the user can pay attention or not but if you pop something in his face every time he moves to a new control that the user is going to have to dismiss, my guess is you are not long for this position. That will seriously annoy the users.
Did you look at the OPs example? There is nothing that pops ups and needs to be dismissed. The hint is shown in a textbox or potentially label at the bottom of the form. The OP uses an entity attribute. The columns contain field names and hints. Two columns.
