Form_Resize is Not Triggered When Form is Moved

[Stewart Berman]

I need to know that a from was resized or moved. The Form_Resize event on fires when the width or
the height is changed. It does not fire when the form is moved.

Is there any way to trap a move event?

 

[Arvin Meyer [MVP]]

One possible way: Read the Top and Left properties of the form when opened.
Store them in a form level variable. Use the Timer event to periodically
check the form's position.

 

[Stewart Berman]

I was hoping to avoid a timer and definitely avoid having to subclass the window to trap the WM_MOVE
message.

I assume the Load_Resize event traps the WM_SIZE message. Is there any hack to get it to also trap
the WM_MOVE message?

BTW, a form doesn't have a Top and Left property -- at least in Access 2000. You need to use
GetWindowRect to get the screen coordinates and then ScreenToClient to convert to coordinates
relative to the Access client window. Then convert from Pixels to Twiips.

 

[Arvin Meyer [MVP]]

I don't think there's anything within Access VBA. You can possibly use an
api to trap the message. You might also use the mouse move event, but that
would be grabbing for straws.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

 

[Charles Wang [MSFT]]

Hi Stewart,
Access does not expose the On Move event for you to trap the WM_MOVE
message. In addition to subclassing the Window, I recommend that you try
using the events "On Mouse Down" and "On Mouse Up" to judge if your window
was moved. As you have mentioned, you can use the Windows APIs
GetWindowRect and the ScreenToClient to get the window's Top and Left
properties. Compare the values in the mouse up event with those in the
mouse down event. If they are different, it means that your window is
moved, and then you can call your custom function.

Hope this helps. If you have any other questions or concerns, please let us
know.


Best regards,
Charles Wang
Microsoft Online Community Support
=========================================================
Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: (e-mail address removed).
=========================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
=========================================================

 

[Stewart Berman]

The intent is to capture the form's position and state everytime it is changed and save it so the
form can be positioned the same way the next time it is opened. (There are issues in capturing the
information in Form_Unload or I'd just do it there.)

If I have to retrieve the form's position "On Mouse Up" I might as well save it as the overhead is
less than getting the form's position "On Mouse Down" and doing the comparison.

 

[Arvin Meyer [MVP]]

If that's the case, simply maximize Access when it's opened and set the
form's Top and Left properties in the Load or Open event. Then as the
developer, you have full control of exactly where the form is. If you want
to allow the user control, save the Top and Left properties in a table in
the Close event of the form. Then when it's opened, retrieve those
properties.

Usually, but not 100% always, a form opens at the same position it was last
saved.

 

[Charles Wang [MSFT]]

Hi Stewart,
If your intention is just to capture the form's position and ensure that it
can be positioned the same way the next time it is opened, I think that
Form_Unload is the proper place for you to capture the form's position.
Could you please let me know what were the issues you meant here?

Best regards,
Charles Wang
Microsoft Online Community Support
=========================================================
Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: (e-mail address removed).
=========================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
=========================================================

 

[Stewart Berman]

The Form_MouseUp event does not get triggered when the form is moved by clicking on the title bar,
dragging the form and releasing it. It is only triggered when a bare spot on the form is clicked.

It would appear that subclassing the form's window is the only way to capture a move event. A very
ugly way to do it.

 

[Stewart Berman]

One can capture the form coordinates during the unload event IF the form is not maximized or
minimized. The intent is to capture the entire state of the form -- including the coordinates it
would assume when being restored from a minimized or maximized state. Thus it is necessary to
capture the coordinates the last time they were changed while the form was not minimized or
maximized. So if the user minimizes the form and then closes it (or Access) when the form is opened
it will be minimized and when it is restored it will be at the position it was before it was
minimized.

 

[Charles Wang [MSFT]]

Hi Stewart,
Actually for your requirements, it is quite common and simple to use a
timer to periodically check the form's position as Arvin had mentioned.
However I noticed that you said that you tried to avoid using a timer.
Could you please let us know what your concerns are for this method?

Thank you!

Best regards,
Charles Wang
Microsoft Online Community Support
=========================================================
Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: (e-mail address removed).
=========================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
=========================================================

 

[Stewart Berman]

There are a few reasons to avoid the use of a timer:
1. It is additional overheard.
2. It would require the use of API calls to create a timer since I cannot use the form's built-in
timer.
3. There is a risk of memory leakage if the class's termination code is not executed for some reason
and the timer is not properly cleaned up.

 

[Charles Wang [MSFT]]

Hi Stewart,
Thank you for your response.

I understand your concerns. If you encounter any further problems of using
Windows API, I recommend that you have a new post at windows SDK community
microsoft.public.win32.programmer.ui for dedicated support since we have
Microsoft professionals actively monitor that queue.

If you have any other questions or concerns, please do not hesitate to let
us know.

Best regards,
Charles Wang
Microsoft Online Community Support
=========================================================
Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: (e-mail address removed).
=========================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
=========================================================