AL
AL copied to clipboard
microsoft
Add Tooltip property to fields in the Table and Table Extension objects.
Lately I've been adding Tooltips to some of our extensions, and I've noticed that I end up writing almost every tooltip twice: once for the list page associated to a table, and then again for its card page.
I can understand that sometimes can be interesting to have different Tooltips, for the same field, depending on the page. But, most of time the Tooltip is a description of the field's purpose, and that doesn't change across pages.
Wouldn't it make sense to treat Tooltip the same way as the Caption property, and add the option to define them both in the Table and Page object?
As a bonus: fields added through the Page Designer would have tooltips.
Could we imagine the same for 'Actions'? Most of the actions are present on both the Card and List pages. Mostly they're defined using the same properties (Image, RunObject, Tooltip, ...). Could be somewhat trickier than for fields, since there's no shared 'Action' object on table level or no common reusable 'TableX_ActionY_Tooltip' label.
Thanks for the suggestion. We will consider it for the long term backlog.
Any news on this, now over half a year later 😸 ---pretty pretty please with a cherry on top...
This is extremely important for LS Retail as we have a large ISV solution in multiple languages
Could we imagine the same for 'Actions'? Most of the actions are present on both the Card and List pages. Mostly they're defined using the same properties (Image, RunObject, Tooltip, ...). Could be somewhat trickier than for fields, since there's no shared 'Action' object on table level or no common reusable 'TableX_ActionY_Tooltip' label.
It would be great to define actions on the table level and just import them (caption, tooltip, image, code, and all) into multiple pages.
This seems similar to how some GUI frameworks (or popular app development libraries over them) provide ways to consolidate the notion of 'describe and enable doing a thing' in one place for multiple callers to use.
I concede that presentational stuff like that doesn't really seem like the purview of the table. But then, an app-specific framework like this is never going to attain totally perfect separation of model and view. So it might be worth concessions there to make things far easier for app developers.
I just noticed that someone has created an idea for this ticket, so I thought it would be nice to link it here so that anyone that finds this ticket can vote it: https://experience.dynamics.com/ideas/idea/?ideaid=24c500e3-b974-ea11-99e5-0003ff68dcc1
Please...
It is something so basic that it is hard to believe why it was not defined from the beginning at a table-field level.
Things like this are a must have with DRY (Don't Repeat Yourself) philosophy
