I get it but like I mentioned, if there is adjustment to do, if can done via the table instead of the need to release a new front end.
Populate the name of the active control on focus in a form. (1 Viewer)
- Thread starter calvinle
- Start date
I get it but like I mentioned, if there is adjustment to do, if can done via the table instead of the need to release a new front end.
Gasman
Enthusiastic Amateur
- Local time
- Today, 07:32
- Joined
- Sep 21, 2011
- Messages
- 14,222
You can set the ControlTooltip property a lot easier.
Same with the Status Bar
https://docs.microsoft.com/en-us/office/vba/outlook/how-to/general/how-to-specify-control-tip-text-for-controls
HTH
Same with the Status Bar
https://docs.microsoft.com/en-us/office/vba/outlook/how-to/general/how-to-specify-control-tip-text-for-controls
HTH
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??"
- Local time
- Today, 01:32
- Joined
- Feb 28, 2001
- Messages
- 27,131
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.
MajP
You've got your good things, and you've got mine.
- Local time
- Today, 02:32
- Joined
- May 21, 2018
- Messages
- 8,525
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 FunctionI 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.
Demo includes the Msgbox.
Last edited:
- Local time
- Today, 01:32
- Joined
- Feb 28, 2001
- Messages
- 27,131
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).
MajP
You've got your good things, and you've got mine.
- Local time
- Today, 02:32
- Joined
- May 21, 2018
- Messages
- 8,525
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.
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.
Thanks everyone for your input.
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
Thanks
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
Thank you
isladogs
MVP / VIP
- Local time
- Today, 07:32
- Joined
- Jan 14, 2017
- Messages
- 18,209
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.
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.
MajP
You've got your good things, and you've got mine.
- Local time
- Today, 02:32
- Joined
- May 21, 2018
- Messages
- 8,525
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 Functionthen 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.
Seriously?, we started off with 'Populate the name of the active control on focus in a form.
' and now 255 characters is not enough?
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
Thanks everyone
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 !
MajP
You've got your good things, and you've got mine.
- Local time
- Today, 02:32
- Joined
- May 21, 2018
- Messages
- 8,525
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.
Last edited:
- Local time
- Today, 02:32
- Joined
- Feb 19, 2002
- Messages
- 43,213
I have done the tool tip definition using a table for an application that used an 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.
If the database is a normal schema where fields are mapped to specific controls, I would simply use the form. I would not try to make this more "efficient" by using a table and forcing each control to run event code to update the ToolTip. Most tables are bound to a single form for updating. It is really rare that you would use multiple forms to update the same data. Not impossible but very rare. So there is no "efficiency" to be had and the definitions change so infrequently that it isn't a burden to update the ToolTip if you ever need to.
If the database is a normal schema where fields are mapped to specific controls, I would simply use the form. I would not try to make this more "efficient" by using a table and forcing each control to run event code to update the ToolTip. Most tables are bound to a single form for updating. It is really rare that you would use multiple forms to update the same data. Not impossible but very rare. So there is no "efficiency" to be had and the definitions change so infrequently that it isn't a burden to update the ToolTip if you ever need to.
- Local time
- Today, 01:32
- Joined
- Feb 28, 2001
- Messages
- 27,131
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,
(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.
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.
- Local time
- Today, 01:32
- Joined
- Feb 28, 2001
- Messages
- 27,131
MajP in re post #27. I agree that we are probably looking at two different issues because, let's be honest, it IS a confusing problem.
