Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||BASIC procedures requiring parameters or returning values should not show in Macros GUI dialog|
|Product:||App Dev||Reporter:||erikanderson3 <erikanderson3>|
|Component:||api||Assignee:||AOO issues mailing list <issues>|
|Status:||UNCONFIRMED ---||QA Contact:|
|Version:||3.3.0 or older (OOo)||Keywords:||oooqa|
|Issue Type:||ENHANCEMENT||Latest Confirmation in:||---|
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 with. 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 displayed, 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 according to their properties. But I think this is some kind of unnecessary feature, as a macro 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".