Hi,
somehow I cannot make it work to use a variable in the "Then Offset Position By" option when opening a Floating Menu. (see screenshot below)
Is this UseCase supported?
Thanks for your feedback and have a great day.
Kind regards,
Volker
Hi Andreas,
so ease the positioning of the hierarchical circular Menu, I would love to have the option to position a Floating Menu at a "Saved Mouse Position".
First I thought this could be done by one of the "Position Retrieved From Dynamic Variable or Named Trigger..." options - but I couldn't make it work.
Currently I workaround this problem with multiple "Save Current Mouse Position" and "Restore Saved Mouse Position" actions - but having the possibility to directly open a Floating Menu at a "Saved Mouse Position" would ease this to just one action.
Thanks for considering and have a great day.
Kind regards,
Volker
1 Like
The problem why the variable approach didn't work was that the "save current mouse position" action didn't use BTT's newer variable infrastructure yet. This should be resolved in 6.199 and you should now be able to enter the specified variable name as dynamic variable.
If you need more control you would need to use javascript to update the floating menu properties on demand (the java script can retrieve variables, do calculations with them, then e.g. change the menu position). If you need that approach I can post an example later.
1 Like
Nice thank you - I will give it a try and come back to you in case I need a example.
Hmmm, still not working as expected. Any further ideas?
I've set it up as followed:
-
With a circular Menu:
-
With a non circular Menu:
The behavior when triggering is random:
-
With a circular Menu:
-
With a non circular Menu:
Do you have the "Position retrieved from dyanmic variable (fixed on screen)" or "Position retrieved from dynamic variable (In Focused Window)" selected? (It needs to be fixed on screen)
change it to fixed on screen 
The focused window option is if you need to keep a distance fixed to the focused window
Sorry this was a copy & paste mistakee by me - as you can see in the screenshots I had it on "fixed on screen".
I'll share my presets later - not on my Mac currently.
1 Like
That would be great then I can test it here. I'll also add some example on how to use the java script approach later, that is maybe better in your situation anyways
Here are my exports:
Test-Ring.bttpreset (61.9 KB)
exported_triggers_for_test_menu.bttpreset (5.1 KB)
Test-Menu.bttpreset (30.8 KB)
I guess I can start to dig into Java Script a little bit - currently no expert in that field. With the help of AI 
Thank you and have a great day.
It seems like checking this option fixes the issue, there seems to be some other internal/implicit repositioning call that interferes - I'll check where that is coming from.
With this option the position of the menu will only be reevaluated with the "Show Floating Menu" action (when "Always Move & Resize To Defined Position When Showing" is enabled) or with the reevaluate menu position action.
1 Like
It's still behaving weird for me - event with this option activated.
It even seems that it behaves different when I record the screen vs when I don't record the screen.
If I don't record the second click brought up the menu at the expected position.
If I record the screen it not reproduce-able what happens:
I did simplify / refactor the positioning logic a bit, could you check whether 6.201 alpha helps with this?
Hi Andreas,
it helps only a little:
- If the option "Only update position when requested" is unchecked
- The menu opens at the former position and then directly is moved to the new position
- If the option "Only update position when requested" is checked
- The menu opens at a wrong position with the first trigger and moves to the right position with the second trigger
I am still wondering, that I cannot record this behavior - because when I start screen recording it behaves different.
weird it seems to work fine here with your action sequence, I wonder whether there is something that interferes
Just to be clear, your action sequence saves the mouse position, then waits for ~1s and then shows the menu at the saved mouse position (even if the mouse has moved somewhere else in between). This is the intended behavior?
Hi Andreas,
I now manged to record the misbehavior with a different screen-recording-app:
The ~1s delay time is optional and came in while debugging, in my latest setup I got rid of this delays since it does not change anything.
That's how my trigger currently looks like:
Export of Trigger and Floating Menus:
Lasso_Trigger.bttpreset (1.8 KB)
Lasso_Menus.bttpreset.zip (19.8 MB)
My UseCase:
- I have set up a hierarchical menu
- the Main Menu should open right at the mouse position
- from this Main Menu I can open Sub-Menus
- the Main-Manu hides when a Sub-Menu opens
- inside the Sub-Menus I have a "Back" button that opens the Main-Menu at it's previous position
Since the option were a floating menu opens is part of the floating menu properties and cannot be changed b within the "Show Floating Menu", I came up with the idea to save the mouse position and use that coordinates to open the Main Menu. These coordinates are only updated when the Main Menu is opened through it's normal trigger (and not within the "Back" buttons of the Sub-Menu).