johndavidson
06-30-2016, 01:25 AM
This is a strange one (which, see below, I have just solved!). Will keep the post in case something similar happens to others.
I have a laptop running with two monitors and a number of macros that place the current active window in various places on the three screens (using hotkeys). They have worked fine for 2 or 3 years. Now, the WindowMax routine fails to work on the laptop. It works on the monitors, but not the laptop. However, if I put a Sleep function in before doing the maximize it works. So why is a delay required before wdWindowStateMaximize will work on the laptop? Has anyone any idea why this should suddenly start happening? This is my new routine to workaround the problem:
Sub WindowMax()
' For reasons unknown, this routine has started failing to set the WindowState to max (on the laptop only, not my two monitors)
' Any delay > 1000 ms seems to let ActiveDocument.ActiveWindow.WindowState = wdWindowStateMaximize function correctly
' Sometimes 300 ms is sufficient, but not always
' WindowState is being correctly identified as wdWindowStateNormal
If ActiveDocument.ActiveWindow.WindowState = wdWindowStateNormal Then
If ActiveDocument.ActiveWindow.Top > -6 Then Sleep 1000 ' Only add delay if on the laptop (also catches top of the window part-way down a monitor)
ActiveDocument.ActiveWindow.WindowState = wdWindowStateMaximize
End If
End Sub
Things I've tried that make no difference:
Re-creating Normal.dot
Being in Print or Normal view
Checking Tools > Options > View
Checking that ActiveDocument.ActiveWindow.WindowState is correctly identified as Normal view
Stepping through makes it work because the delay before executing the maximize code is longer than 1 sec.
Hoping it would just go away (I've been living with it for a month)!
JUST HAD ANOTHER IDEA! I've been using a super piece of software (DisplayFusion, v.7.3.4, installed May 22 2016) that permits moving windows around the 3 screens and a whole lot more. I stopped it running - and full function has been restored!! I rolled back to an earlier version v.7.3.Beta4, and the problem was not there. So it's a conflict with DisplayFusion v.7.3.4. I've just installed the latest version, v.8.0.Beta9, and the problem has also gone away. SOLVED!!
I have a laptop running with two monitors and a number of macros that place the current active window in various places on the three screens (using hotkeys). They have worked fine for 2 or 3 years. Now, the WindowMax routine fails to work on the laptop. It works on the monitors, but not the laptop. However, if I put a Sleep function in before doing the maximize it works. So why is a delay required before wdWindowStateMaximize will work on the laptop? Has anyone any idea why this should suddenly start happening? This is my new routine to workaround the problem:
Sub WindowMax()
' For reasons unknown, this routine has started failing to set the WindowState to max (on the laptop only, not my two monitors)
' Any delay > 1000 ms seems to let ActiveDocument.ActiveWindow.WindowState = wdWindowStateMaximize function correctly
' Sometimes 300 ms is sufficient, but not always
' WindowState is being correctly identified as wdWindowStateNormal
If ActiveDocument.ActiveWindow.WindowState = wdWindowStateNormal Then
If ActiveDocument.ActiveWindow.Top > -6 Then Sleep 1000 ' Only add delay if on the laptop (also catches top of the window part-way down a monitor)
ActiveDocument.ActiveWindow.WindowState = wdWindowStateMaximize
End If
End Sub
Things I've tried that make no difference:
Re-creating Normal.dot
Being in Print or Normal view
Checking Tools > Options > View
Checking that ActiveDocument.ActiveWindow.WindowState is correctly identified as Normal view
Stepping through makes it work because the delay before executing the maximize code is longer than 1 sec.
Hoping it would just go away (I've been living with it for a month)!
JUST HAD ANOTHER IDEA! I've been using a super piece of software (DisplayFusion, v.7.3.4, installed May 22 2016) that permits moving windows around the 3 screens and a whole lot more. I stopped it running - and full function has been restored!! I rolled back to an earlier version v.7.3.Beta4, and the problem was not there. So it's a conflict with DisplayFusion v.7.3.4. I've just installed the latest version, v.8.0.Beta9, and the problem has also gone away. SOLVED!!