Issue 26140

Summary: BASIC procedures requiring parameters or returning values should not show in Macros GUI dialog
Product: App Dev Reporter: erikanderson3 <erikanderson3>
Component: apiAssignee: AOO issues mailing list <issues>
Status: UNCONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: issues
Version: 3.3.0 or older (OOo)Keywords: oooqa
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---

Description erikanderson3 2004-03-05 01:15:20 UTC
I've discovered that functions (as opposed to subs) are also displayed when the
user clicks "Tools -> Macro -> Macros..."  This makes little sense, as functions
generally have return values, which a GUI user would not be able to do anything

Furthermore, subs and functions that require parameters should definitely not be
displayed in the GUI macro list, as attempting to run them directly from the
dialog does nothing but generate an error message stating "BASIC runtime error.
Argument is not optional."

NOTE:  This may be loosely related to Issue # 25885.
Comment 1 erikanderson3 2004-03-05 01:16:24 UTC
Specifying in the summary that this is a BASIC issue.
Comment 2 flibby05 2004-04-22 20:31:19 UTC
changing Defect -> Enhancement
Comment 3 ooo 2004-04-26 13:33:45 UTC
this is not an API issue, forwarding
Comment 4 thomas.benisch 2004-04-26 14:56:03 UTC
The Macro dialog (Tools/Macros/Macro...) is part of the Basic IDE, whose main
users are macro developers. In the right list box all macros of a module are
that means subs, functions, with and without parameters. I think this makes sense,
because a macro developer wants to edit, delete or run those macros.
A macro developer may also want to run a function for testing purposes. Also subs
with parameters may run successful, if the parameters are not used inside the sub.
If an error appears, the Basic IDE displays the error.
Therefore I strongly argue for displaying ALL macros of a module in the list box.
If you agree, I will close this issue. 
Comment 5 erikanderson3 2004-04-27 02:33:03 UTC
As I just posted over on Issue 25885, I am still very much a fan of the idea of
somehow distinguishing in the Macros dialog between macros that can just plain
run, and those in need of something else.  The point about editing access is
well taken, leading me to suggest in the other thread a simple greying of macro
names for Private methods, in this thread for macros that require parameters or
return something.  Some simple visual marker would be very helpful, and
potentially time-saving.  
Comment 6 thomas.benisch 2004-04-27 09:19:27 UTC
An additional argument for listing all macros of a module is the Assign button.
If you assign a macro to an event, then a sub even may have a parameter, which is
used for passing event information.
Of course you can mark the macros listed in the list box with different colors
to their properties. But I think this is some kind of unnecessary feature, as a
developer should be experienced enought to know what he does. For a normal user
you would anyway bind the macro to an event, e.g. a button on a document.
Nevertheless I will consult user experience about their opinion.
Comment 7 thomas.benisch 2004-04-27 09:20:28 UTC
TBE->BH: What's you opinion?
Comment 8 christianjunker 2005-07-08 21:18:54 UTC
all functions should be listed in my opinion. Since you also can specify
optional parameters and thus running it from GUI would not cause any error if
you handle everything properly.
Comment 9 bettina.haberer 2010-05-21 14:52:45 UTC
To grep the issues easier via "requirements" I put the issues currently lying on
my owner to the owner "requirements".