Issue 25885

Summary: "Private" tag BASIC subs and functions would be helpful
Product: App Dev Reporter: erikanderson3 <erikanderson3>
Component: apiAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P4 CC: issues
Version: 3.3.0 or older (OOo)Keywords: oooqa
Target Milestone: ---   
Hardware: PC   
OS: Windows 2000   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---

Description erikanderson3 2004-02-26 07:30:08 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.
Comment 1 ooo 2004-03-04 10:25:31 UTC
forwarding to responsible developer
Comment 2 flibby05 2004-03-12 13:30:52 UTC
see also issue 26140
Comment 3 ab 2004-03-31 13:13:14 UTC
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
Comment 4 ab 2004-04-26 14:30:16 UTC
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
Comment 5 erikanderson3 2004-04-27 02:22:58 UTC
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.  
Comment 6 ab 2004-04-27 08:54:44 UTC
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.
Comment 7 Mathias_Bauer 2005-03-31 15:15:23 UTC
Andreas, back to you again.:-)
Comment 8 ab 2005-08-18 14:02:26 UTC
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.
Comment 9 christianjunker 2005-08-18 23:16:59 UTC
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.
Comment 10 ab 2005-08-19 06:42:37 UTC
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.
Comment 11 ab 2006-05-18 10:23:43 UTC
STARTED, but realisation currently is not very likely 
Comment 12 ab 2007-06-21 08:04:43 UTC
Test
Comment 13 tkr 2007-06-21 09:37:57 UTC
.
Comment 14 joerg.skottke 2008-11-07 10:32:38 UTC
Reassign to requirements
Comment 15 joerg.skottke 2008-11-07 10:33:08 UTC
Clear resolution