Apache OpenOffice (AOO) Bugzilla – Issue 25885
"Private" tag BASIC subs and functions would be helpful
Last modified: 2013-02-24 21:06:56 UTC
(Apologies beforehand if this isn't quite where this should be filed.) I've done a small bit of VBA hacking in MS Office, and one thing that was very helpful in terms of simplifying module interfaces was the "Private" tag. I could have a basic module with one publicly available module for simple scripting. When the user would click through Tools -> Macros -> Macro, they would see the module name, and the single procedure they could run. In OOo, I often find myself presented with 10+ procedure names, as helper procedures that are useful only within the context of the module are exposed to the end user. Basic developers are limited to procedure names like "Main", and making sure that the main procedure is the first in the module to ensure it's on the top of the list. Enabling the "Private" keyword for use in procedure definitions would allow for much cleaner module interfaces, and the use of more informative procedure names. Helper procedures should not be exposed outside the module.
forwarding to responsible developer
see also issue 26140
Has to be evaluated, probably too late for OOo 2.0 -> OOo later, P3 -> P4 because the problem may be annoying but not really serious
While discussing about i26140 with tbe I've realised that I don't like this idea. First, the Tools/Macros/Macro... dialog is not only about letting macros run but also about managing them in general. If I want to choose a sub in a big module to edit it's not very helpful if it isn't displayed in the list. Besides this I think the private tag would be overinterpreted here. It does only mean that a sub cannot be called from outside the module - and even this has not been working until recently. To interprete private as "not executable" is not stringent in my opinion. So I don't think that this makes sense -> Resolve / WONTFIX
However, the ultimate issue remains -- if you're sending a doc with macros to an end-user, i.e. someone with no need or interest to be mucking about with macros aside from running them, having a list potentially as long as your arm can be overwhelming and confusing. Even should Private methods be visible from the Macro dialog, and your editing example is certainly a valid reason to keep them so, could there not be some way of setting them apart visually, perhaps by greying out their names? Secondly, > [Private] does only mean that a sub cannot be called from outside the module - > and even this has not been working until recently. To interprete private as > "not executable" is not stringent in my opinion. "Cannot be called from outside the module" is exactly what I was thinking -- that a private method can only be called from within the module, i.e. *not* from the GUI, but only by another method in that module. Perhaps I am too keen on keeping a sharp division between interface and implementation, but I would very much appreciate some visual cue in the macro dialog indicating private methods. ---- Another more radical thought is to either rework how Private works, or introduce some "Friendly" analog. Specifically, implement some mechanism to keep methods from being called from outside that *library*, rather than module. This way, all ugly internal-only code can be sequestered in its own module(s), with another clearly delineated user interface module containing only those methods for end-users (including other devs) to run. ... However, that's looking like a major PITA the more I think about it. The grey-out idea above is probably much more useful, and easier to implement.
I see the point but the Tools / Macro / Macro dialog is not intended in the first place to start macros but to organise macros. So it provides a more developer than end- user related view. Anyway for me this dialog seems to be too complicated for "simple" end-users even if private macros are disabled or grayed out. So if I sent macros to end- users within a document I wouldn't expect them to start this macro by using the Tools / Macro / Macro dialog. I would always provide a (or serveral) button(s) or toolbar entries and bind the macros to them. The user then only has to click at the right place. For OOo 2.0 there will be a seperate "Run Macro... " menu entry / dialog where ideas like yours may be more reasonable because this functionality is nearer to the end-user. I reassign this task as a suggestion to Noel Power who is respon- sible for the Scripting Framework project that covers this new dialog.
Andreas, back to you again.:-)
This would make sense in certain contexts, e.g. in the Run Macro dialog or the dialogs to assign macros to events. But the implemen- tation is not so easy. So it has to be evaluated if this is important enough to justify the effort.
I don't see a lot of usefulness in it either, also because Private is already a known keyword. But if somebody wants to implement this feature, why not, so this issue should be kept open for others to see what they can do.
I want to give some background information why this is not so easy to realise. The main problem is that the information if a sub is private or not is only avai- lable inside the Basic core. But the Run/Assign Macro dialogs are based on the Scripting Framework API. So the information has to be provided somehow, probably by a new property the ScriptProvider for Basic has to support. And then the question occurs if it makes sense to provide a new property for this only reason or if it makes more sense to design a more general interface to provide information about subs/functions/methods (in the Scripting Framework context not only for Basic of course). I don't like a quick and dirty solution only to filter private Basic methods in UI.
STARTED, but realisation currently is not very likely
Test
.
Reassign to requirements
Clear resolution