Do you use tags (prefixes) for the UNO controls? And if so, which ones?

[eeigor]

UnoControl Service Reference
Something like that (incomplete).

E.g.
Button - btn,
Edit - edt,
RadioButton - rad (?),
FixedText - lbl (?),
etc.
Of course, in VBA I used the ‘cmd’ tag for CommandButton, or ‘txt’ for TextBox and ‘opt’ for OptionButton in Frame (same as RadioButton in GroupBox), or lbl for Label (same as FixedText) respectively.
Give a complete list of tags (prefixes) or provide a link.

For example,

Sub cmdHelp_actionPerformed(oEvent As com.sun.star.awt.ActionEvent)
	Call RunHelpDialog
End Sub

It is possible to bind the button event directly to the ‘RunHelpDialog’ procedure, but specifying the name of the button with the event to execute serves better for the purpose of self-documenting the code.
If you use tags (prefixes), please share.

UPDATED:
I no longer use Hungarian notation for variables in my code like I did before (I use, though short: o, s, n, b, and so on, where n stands for numeric). However, for controls, I still find this useful.
See: Hungarian Notation Naming Conventions
I would not want to alter all this in my own way, but I would like to adopt the established practice in naming controls.

[Lupp]

If you assign a routine to be executed on any specific event whichj may be risen by more than one control object, you needn’t define a routine with a specific prefix designating this object. You can branch the execution based on an ordinary propety of the object. I prefer the .Tag property of type string for this purpopse. If I need to pass parmeters I use this property with a syntax as if it is the query part of an URL. (ident=listbox77&row=15&temperature=22.5°C&state=tired) e.g. You may also have a part in front and a delimiter “#” (e.g.) at the end to be even more flexible.
Editing the object with the Engtlish UI this property is named “Additional information”. (Misleading is funny?)
I don’t feel sure if this can help you.

[eeigor]

@Lupp thanks for the quick reply. But the question was about naming of controls (e.g., btnHelp button control, edtTopic Edit control; here I mean the prefix for tag). In general, programming style issues are very important.

As for using the ‘Tag’ property of controls, I also use it to pass parameters: Tag1=Value1;Tag2=Value2. For this purpose, I’ve been using 2 VBA classes for a long time: ‘TaggedValues’, which implements a collection of tag/value pairs, and ‘TaggedValue’. Works here too.

UPDATED:
I later noticed that some of the controls in the dialog toolbar are named differently than in the model. So, when creating controls, they receive the following names by default in the dialog window: Button is named as CommandButton1, ‘Text Box’ as TextField1, ‘Option Button’ as OptionButton1, ‘Label field’ as Label1. This means that you can use the same prefixes: cmd, txt, opt, lbl. However, when added to the sheet, these form controls are named slightly differently: ‘Push Button’ as ‘Push Button 1’, ‘Text Box’ as ‘Text Box 1’, ‘Option Button’ as ‘Option Button 1’, Label as ‘Label Field 1’.
Are these all the same controls (Button, Edit, RadioButton, FixedText) respectively? Or am I confusing something?
It looks like the same thing but was done by different people.
Link

Screenshot



Pay attention to the control prefixes. How do you solve this task?

[Lupp]

Well, I felt sure that I couldn’t be sure. You see, being wrong I was right.

I never came from VBA, and only looked into VBA code superficially, but I used Delphi/Lazarus with its VCL years ago quite a lot. What you expect/hope seems to me a similar behavior where an object inspector is usable to create a hull for an “!individualized OnClick routine” (primarily only for the already named object) assigning it at the same time as the handler to the respective event of the object. Libo API/Basic don’t work this way.

I also never programmed for complex tasks in LibO on a professional basis, but mainly did some small projects of the kind as the “experimental part” of my interest-driven studies (and for helping).
Also my Delphi/Lazarus studies were only “professional” in the way that I needed some understanding to be able to use these “RDE systems” in my teaching concerning IT.

Concerning LibO API/Basic I’m afraid: There’s no well supported way to automatically prefix a name or whatever to an arbitrary property. There’s only the automatic naming of the object itself.
Also there’s no automated creation of individualized handlers (anyway only the hull possible, of course).
I wouldn’t see this as an actual disadvantage.

The confusion between names used by the API implementation and those used for the (English) UI is a long-time annoyance. The .Tag case I already mentioned is just a tiny example, but cost me about an hour to find out some years ago. I simply don’t understand how rational development by competent people can create such a nonsense. In addition there seems to be no table API<-->UI anywhere. How development can decide to subject these parts of the UI under the spilling over “l10n” is a mystery to me. A developer on the document-supporting level needs to know the API terms anyway, the localized names are misleading, and an ordinary user should never directly tamper with object properties. Thus the l10n in this filed can’t help anybody to ease his work, but always makes things more complicated and error-prone.

[eeigor]

Yes, questions remain. This doesn’t seem to matter, but I don’t want to neglect styling in the interest of code self-documenting. However, not all controls can be named according to this scheme, but only those with which the code is associated.

[karolus]

Give sense-full names wich give some information to the reader ( “reader” includes yourself but Months|Years later). IHMO prefixed and|or numerated things tells nothing.

[eeigor]

@karolus, the meaningful names in the example dialog above have already been given, but the control prefix and event name indicate who and when calls the procedure without additional comment.
See: cboTopics_textChanged (because there is also a txtTopic control for displaying the topic)

UPDATED:
For the sake of clarity, we are discussing a perfectly working schema in VBA, which does not work here, but can be accepted and used.

[Lupp]

The main problem I see:
LibO documents can’t be made fully UserSafe. They can’t be compiled making the implemented functionality unchangeable to the end-user. If there once may be one feeling to be the better developer, he(f/m) will find a way to tamper with everything. Lack of understanding or any kind of error may then damage the functionality - which may remain unnoticed for a long time, and may cause secondary errors by the millions.
Where data reliability is essential, but data must be edited / maintained / appended due to the established workflow, only full-grown rights management including the frontend components can help, and this will only be (hopefully) provided by a professional database.
The little dilemma is that databases thwart creative use.
Well, there are some possible precautions, and I may miss a lot…