If you are talking about dynamic button placement, I did something like this some years ago. Due to legal issues, I couldn't keep the code and even if I had it, there would be a risk of liability if I published it. But I can describe what I did.
I set aside an area on my form where my buttons would go. I took great pains to assure that my buttons were of fixed height and it happened that they were of fixed width as well. Then I had a set of variables in the declaration area of the form that recorded the .TOP, .LEFT, .HEIGHT, and .WIDTH of the set-aside "button display" area and the .TOP and .LEFT of the next button to be placed.
Every time the form .CURRENT event fired, I reset the "recent" TOP and LEFT to the set-aside TOP and LEFT. Then, because there were not that many buttons per form, I just linearly called a routine once for each button, with a parameter for the next button to place (by ref) and the state of the button for this situation (by val). This was a rare case where I intentionally allowed a side-effect, because the six variables were used "globally" from within the form's class declaration area. I did that for debugging purposes because I decided to NOT make it a separate class. (Didn't have the time for it.)
The subroutine would look at the button's state code. If the state was "button not used" I disabled the button, made it invisible, and moved it somewhere innocuous. Disabled, invisible buttons CAN overlap with no bad results, so all unused buttons usually ended up sitting under the HELP button.
If the state was "button in use" I enabled the button, made it visible, and moved it to the appropriate place indicated by the "recent" TOP and LEFT. Then I looked at the button's .WIDTH and .HEIGHT and updated the "recent" TOP and LEFT for the next button to use (or not).
I did learn one lesson about moving buttons around. You move and place buttons in units of TWIPS (1440/inch). NEVER make the RIGHT edge of one button exactly adjacent to the LEFT edge of another button, and ditto for TOP and BOTTOM edges. Add 1 twip between them because at unpredictable different screen sizes, you can get a video "flutter" anomaly if the actual screen size isn't an even multiplier of units of twips. With that 1 extra twip between them, the anomaly goes away.
If the user did something to change the situation (which could happen without doing a SAVE), I would recall the button-control routine with updated "in use" flags. The buttons I was using would never ALL be enabled at once. Things like SAVE, NEW, UNDO, REMOVE, EXIT (form), HELP, FILE REPORT... In this application, if the form wasn't dirty, SAVE and UNDO were not in use. If it WAS dirty, NEW, REMOVE, and EXIT could not be used. HELP and FILE REPORT were always valid. A very few special-case buttons also were in the mix for some forms. The decisions to change the buttons in my app were made after each control's .LOSTFOCUS routine, which also changed highlighting of the control that just lost focus. It saved the OTHER part of highlighting for the control that was going to run .GOTFOCUS as soon as .LOSTFOCUS did an EXIT SUB.
It was a bit tedious at first, but once I got it right, it was pretty smooth and quick too. The only trick is if I had so many special buttons that I had to overflow them into the next row on the form. But if the buttons were uniform in height as well as width, they fit nicely. And yes, in this case, I had the .BEFOREUPDATE event trapped so that you could only save a record with the SAVE button. You could not navigate because I turned those buttons off if the form was dirty. Couldn't exit with a dirty form either.