Calc: Is there some known issues using button to execute a macro - II?

hi,

it’s like minefield potshooting, whereever i look i stumble in new strange things,

i’ll try to attach a file, it contains a macro with strange behaviour,

comment_slowdowns.ods

( !!! the macro is neither well written nor ‘good’ or finished, it’s patchworked from parts i found in the web, but: sometimes it works, and sometimes it doesn’t … !!! )

(to use the file you’ll likely have to disable form-control ‘design-mode’ by clicking - view - toolbars - form-controls - and there uncheck ‘design mode’, it’s neccessary when you see the push-button with ‘drag-points’ on it, i don’t know why that point sometimes enables itself)

tested with LO calc 6.2.8.2 and 7.0.0.0.a0+:

issue 1: the macro in the file works fine when opening macro editor and stepping through it with F8,
while it fails - doesn’t paste in A12, B12 or A11:CV110 - when it’s started by the push button in cell A3,

issue 2: executing the macro by tools - macros - run macro depends on the previous action,
after macro editor stepthrough: run macro works,
after push button: run macro fails,
a sort of a ‘state machine’, not my idea of a reliable algorithm,

i’m interested in two things:

I. rework the macro or button to work from push button

II. why? did above issue occur? an algorithm that could work shouldn’t be dependent on previous actions,

add. info: when i copy the macro code into ‘my macros’ i get the additional possibility to start it with an assigned keyboard shortcut, that worked better. but i’d like to have the macro ‘in’ the file to be able to give it to other people to meter their system in a cheap and fast way.

i’ve learned that similar issues struck other users, macro works but not from push button, e.g.:

thus i think there might be an issue, and not my system being ‘bad’.

this question is to ‘check the field’ before filing a bug.

regards,

b.

Hello @newbie-02

Bug 70883 - “uno: copy” via the dispatcher does not work when a button has focus You are pasting empty cells when macro is run via button.

hello @ SM_Riga,

thanks a lot, that’s the point, the trick to circumvent from: https://bugs.documentfoundation.org/show_bug.cgi?id=70883#c7 works.

there remains one reason to be sad, the systematics of the community and the bugtracker bury too many bugs as ‘old’, and new appearances are withdrawn from attention as ‘duplicate’.

the systematics of the community and the bugtracker bury too many bugs as ‘old’, and new appearances are withdrawn from attention as ‘duplicate’

Nonsense. Duplicates and CC count gradually increase importance of bugs, thus marking a bug as a duplicate of another bug makes one important bug instead of two invisible ones. See e.g. c#88 to bug 62196. If a bug is not handled, it’s not because of how bug tracker works, but because there’s no interested developer. And I also saw this comment, which indicates that it’s unwise to post annoyed comments like yours.

hello @Mike2,

pls. … not again a long OT discussion,

nonsense? - no, just bug #62196 you mentioned is a good example for the evil influence of ‘long time not resolved bugs’. rising priority after 6 years and 9 months is … ‘suboptimal’?

annoyed? - no, frustrated would be the right expression, i know that cheering up would be better, i also try to do it better, but i am human, humans are not perfect, and it frustrates me how an actually good project suffers from protracted bugs.

to cut a long story short, I’ll be e-mailing you privately.

to keep the relevant info visible:

bug description there: https://bugs.documentfoundation.org/show_bug.cgi?id=70883

trick to circumvent problem in comment #7: https://bugs.documentfoundation.org/show_bug.cgi?id=70883#c7

To be honest, I would not even name such a behaviour as a bug. User clicks a form control, focus goes to this control. Makes sense to me. The problem is in the code, which uses some tools/functionality, but does not take into account how these tools work. Comment by Frank Schönheit explains it well. The code is messy, mixes different coding approaches and thus is not reliable and causes undesirable results. But the OP knows it. By the way, you can also control taking focus of the Push Button form contol using Take focus on Click propery.

thanks to @SM_Riga, very good hint, concise explanation there,

am i right:

there is another workaround?: ‘for the records: workaround: Set the “Take focus in click” property of the
button to “No”’

it’s fixed in AAO since 2005?: ‘Fixed this by not routing cut/copy/paste (and a lot of other functionalities) to the active control, if this active control cannot serve the functionality, anyway.’

proposal: pull this method / fix into LO … ? if you agree it being possible i’ll file an enhancement request for it.

Blockquote (from newbie-02)
there is another workaround?: ‘for the records: workaround: Set the “Take focus in click” property of the
button to “No”
Blockquote

Thank you guys very much - I have been trying to find the bug/workaround to this problem for many weeks (without much success searching the net). Your solution worked for me and I am so grateful that you pursued the problem.

Three possible solutions:

  1. The button has a property “Take focus on click” which can be set to No/False. Now .uno:Copy will copy the selected cell(s) unless the selection consists of multiple ranges or shapes.

  2. A single dispatch command can be triggered by a button without calling any macro:
    Action property = “Open document or URL”
    URL = .uno:Copy

  3. True macros do not depend on dispatches.

as you step through the macro you can use the windows key + v on your keyboard to verify if the info was copied to the clipboard This is a very frustrating problem and I gave up and found a way around by getting contents of a cell and placing it in it’s intended location