Matt
Your re-raising of this problem has got me thinking about it again, and doing a bit of experimentation.[ ] The "solution" I offered last time (October last year) is only a partial one, in that it merely gives users a way to fix the intermittent problem AFTER they have noticed that it has occurred.[ ] My current thought is that, if we cannot stop the problem from arising, it might be possible to fix things BEFORE it shows itself to the user.[ ] This could work only if the problem is triggered either by the initiating of the button-driven actions or during them.[ ] If it is triggered after the actions have been completed then we are still up that creek without that paddle.
Exploring this thought required me to be able to produce the problem in the first place. Muphry's Law got in the way here, because for several days I couldn't get any of my intermittently-moving command buttons to move.[ ] I work on a laptop computer, and most of my work is done at my desk, where I use a larger "second screen".[ ] Eventually, acting on a weird hunch, I switched mid-testing to the smaller native screen.[ ] Bingo.[ ] I could get the problem to occur once or twice (still intermittently).[ ] Not consistently, but sufficiently often for me to explore my idea to the point where I had proven to myself that when the problem arises it has arisen before the button-driven actions have fully completed.**
So I added some extra code to the end of the VBA routine that is activated when the command button is clicked upon.[ ] See below.
Code:
Private Sub GenerateScenarios_Click()
'
' Perform the requested simulations when the "GenerateScenarios" button is pushed.
'
' All the hard work is done in a standard subroutine.
' (But it could just as easily be done here.)
'
Call Run_Simulations
'
' Experimental stuff to explore the "button moving" problem.
'
Dim TempH As Double, TempL As Double, TempT As Double, TempW As Double
With Sheets("Parking_Analysis").Shapes("GenerateScenarios")
TempH = .Height
TempL = .Left
TempT = .Top
TempW = .Width
If TempH <> 60.75 Or TempL <> 375 Or TempT <> 658.5 Or TempW <> 114.75 Then
.Height = 60.75
.Left = 375
.Top = 658.5
.Width = 114.75
MsgBox "MOVED from:" & Chr(13) & _
" Height = " & TempH & Chr(13) & _
" Left = " & TempL & Chr(13) & _
" Top = " & TempT & Chr(13) & _
" Width = " & TempW & Chr(13) & _
"TO:" & Chr(13) & _
" Height = " & .Height & Chr(13) & _
" Left = " & .Left & Chr(13) & _
" Top = " & .Top & Chr(13) & _
" Width = " & .Width
End If
End With
'
End Sub
This includes a lot of actions that are there only for diagnostic purposes, actions I intended to prune out once I had categorically confirmed to myself that everything was working as I hoped it would.[ ] At its minimalist all that is needed is:
Code:
Private Sub GenerateScenarios_Click()
'
' Perform the requested simulations when the "GenerateScenarios" button is pushed.
'
' All the hard work is done in a standard subroutine.
' (But it could just as easily be done here.)
'
Call Run_Simulations
'
' Put the damn button back in its correct place.
'
With Sheets("Parking_Analysis").Shapes("GenerateScenarios")
.Height = 60.75
.Left = 375
.Top = 658.5
.Width = 114.75
End With
'
End Sub
But Prof Muphry intervened again, and since I added this code in its first (full) form I have not been able to get the misbehaviour to recur.[ ] I am quietly confident that this approach will solve the problem, and will implement it in my afflicted worksheets and see how it goes.[ ] But until Muphry backs off a bit some miniscule doubt remains.
Perhaps you could try it as well, and see whether you can come up with definitive proof.
**[ ] A footnote.[ ] As described above, I was able to trigger the problem (occasionally and seemingly randomly) by changing between screens of different resolutions[ ] Maybe, in the hands of someone massively more knowledgeable than me, this fact could shed some light on WHY and HOW the problem arises in the first place.