Hi people
When I use key combination Ctrl-End calc puts cursor at end of last row. When I do that in Record macro, nothing happens. Same with Select Row (Shift-Space) and Go to first cell in row (Home)
None of these appear to contradict the "Limitations . . . "
Where am I going wrong ?
Cheers,
Aunty
First, just have to ask what your macro security set at? Tools>Options>Security>Macro security…
Then,
Sub ProofOfLife()
MsgBox("Hello, World!")
End Sub
The actions mentioned all seem to record and playback for me with LO 7.2.5 on Ubuntu 20.04, medium macro security.
Hi Joshua4
I have LO 6.4.7.2 on Ubuntu 20.04.4 LTS
I have previously used Macro record and have other hand rolled macros working as well.
The issue isn’t that it isn’t generating any code, but that once I start Record macro LO ceases to respond to my keyboard.
Once I click Stop recording my keyboard comes back.
If I record a simple macro only using the mouse it works.
It’s as if the program has mysteriously developed a fault!
Any ideas welcome . . .
I agree with @KamilLanda that it may be just as well. I use XRay or MRI all the time, but I almost never record a macro; however, if you do a lot of cursor movement macros I’m sure it would be nice to have. At this point I’d probably recommend backing up your user profile and let LO create a default profile if you haven’t already. (Read this link if this isn’t familiar to you).
Also I have noticed some keyboard weirdness with Ubuntu 20.04. I have everything set completely to US English…language, locale, keyboard, etc., and I can use either left-side or right-side ctrl+shift+arrow to move to the end of the cell region, even cross the right ctrl with left shift, etc., but not if (and only not if) I hit the left shift before I hit the left control. The same physical keyboard worked completely as one would expect with Mint 20.
Had no issue with Ubuntu 20.04.4 Mate. All combinations of Shift + Ctrl + arrow appear to work with:
Version: 7.3.0.3 / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Please note that this is not the case if you used the mouse in advance. As soon as the main window got the keyboard focus back in any way, also keystrokes will be “seen” by the recorder.
If you want to first of all record a keyboard-triggered action, don’t give the focus to the main window by clicking on a (sensitive) area directly starting an action or selecting a cell. Best click onj the title bar of the main window.
You can use uno commands directly without the macro recorder
https://wiki.documentfoundation.org/Development/DispatchCommands
For usage you wrote, there are uno commands like .uno:Go…, .uno:Go…Sel or .uno:Select…. I think for all these commands last parameter in .executeDispatch is empty Array().
Sub unoCommand 'list of uno command https://wiki.documentfoundation.org/Development/DispatchCommands
dim document as object, dispatcher as object
document=ThisComponent.CurrentController.Frame
dispatcher=createUnoService("com.sun.star.frame.DispatchHelper")
dispatcher.executeDispatch(document, ".uno:SelectRow", "", 0, Array()) 'select current row
End Sub
That’s simply a fact. The recorder records .uno: commands exactly as they are seen at record-time. This includes the state (values) of all the parameters (arguments) the commands may need to work. When the macro is called later it will never stop to wait for your keystrokes or mouse-actions probably intended to modify any arguments. What may look sometimes like exceptions are recoreded macros using a .uno: command which opens a dialog. But the stop-and-wait-for-input isn’t done by the macro itself, but by the dialog then.
Dialogs aside, the only way to modify the working of a recorded macro is the selection (of a Cell, a CellRange, of multiple CellRanges, of a Shape or of Shapes…) in advance of calling the macro.
If you want to get an interaction-sensitive macro you need to modify the recorded script. This way you can replace recorded arguments as you choose by input (using the Basic Function INPUT() mostly llike a “micro-dialog”). A very small amount of programming skills is indispensable when going this way, however.
I think the assumed {ed} is, in fact, not what the OP meant. I think the question is “Record Macro”…can’t see my keystrokes. Once recording starts certain keyboard functions stop. This is not normal, and I cannot replicate it in LO 7.2.5 on Ubuntu 20.04.
A reply by @Auntyjack might be useful.
“The macro recorder dosn’t see my keystrokes. How to change that?”
Assuming this was the intended question, I will post a second answer now.
Hi guys thanks so much for your input. The last couple of posts did the trick . . it’s all about where the keyboard focus has gone. It never occurred to me to click in the title bar of the main window again before using the keyboard to record the macro! Silly me 
I have only been playing around with LO basic macro programming sporadically for the past few weeks and thought I would try “Record Macro” then spend some time analysing what it comes up with - and ALSO because I want to use the capabilities of “Paste Special” which I haven’t been able to find in any of the documentation - mind you, there is a lot to read through and I have only scratched the surface so far.
So, back to my (baby) project, and THANKS :))
You couldn’t find this issue. Juding from the behavior of older versions, this seems to be a bug introduced with (about) Version 6.4.
See tdf#147782 (also linked now in my answer.)
Assuming the intended question was
“The macro recorder dosn’t see my keystrokes. How to change that?”
I try a different answer:
Having activated the macro recorder you get shown a windowlet for it with a single button (or sensitive area) labeled “Stop Recording”. This windowlet has the keyboard focus in the technical sense, but no element ready to accept a keystroke. This is a deadlock for the recording as long as you don’t use the mouse to either trigger a recordable action, or to give the focus back to the main window.
I can’t clearly see a reason to consider this behavior desirable. You may file a bug report suggesting to change it at bugs.documentfoundation.org .
See tdf#147782
Before commenting at bugzilla, I wanted to check back here since I cannot replicate this problem.
Here is what I can do: I can use my mouse to select Tools>Macros>Record Macro then immediately press, say, ctrl+shift+left arrow. I see the selection highlighting expand to the left. Then I press up arrow and see the highlighting collapse and the cursor frame move up. Then I type 45 enter and 45 is entered. I use my mouse to click on Stop Recording and after giving a macro name, etc., every move is recorded.
I also tried assigning Record Macro and Stop Recording to keystrokes. Everything still works without touching the mouse at all.
Everything seems to be correct and as I would expect.
Version: 7.2.5.2 / LibreOffice Community
Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5
CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Ubuntu 20.04 LTS with kernel upgrade from 5.13 to 5.16
I just verified that I still have the same issue:
Use mouse to open Tools > Macros > Record Macro,
then immediately keyboard is going nowhere.
Use mouse to click Stop Recording.
2nd try, same, but click back to main document and all keystrokes etc. are recorded.
I am using:
Version: 6.4.7.2
Build ID: 1:6.4.7-0ubuntu0.20.04.2
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5;
Locale: en-AU (en_AU.UTF-8); UI-Language: en-US
Calc: threaded
on a Thinkpad E520
Running Kubuntu with all current updates
Now that I know to manually give focus back to the doc it’s not a problem for me.
Joshua,
I tested with V 7.2.3.2 x64 as “high end” under Win 10, and got exactly what I
told, independent of whether I had started the recorder via the menu by mouse
clicks or via Alt+T, M, R (which are the stanmdard shor6tcuts for my menu tree). I
also just established Shift+F12 as direct shortcut without a change.
↑
I did not yet test with any higher version, but will soon do so.
A different OS (like your Linux) I haven’t at hand, but there may be a difference
in the mechanisms concerning how the keyboard focus is set. Afaik @Auntyjack
didn’t mention his (f/m) OS.
Wolfgang (Lupp)
Josuah,
I found the time to install LibO V 7.3.1.3 (x64) under Win 10
(a69ca51ded25f3eefd52d7bf9a5fad8c90b87951)
Concerning tdf#147782 Behavior unchanged as compared to V 7.2.3.
Wolfgang
Before commenting at bugzilla, I wanted to check back here since I cannot replicate this problem.
Here is what I can do: I can use my mouse to select …
…
Thanks. And I got a chance to try 7.2.5.2 on Windows 10, and the problem was easy to replicate. I set the bug report for Windows and commented.
Thanks for confirming the OS dependence