A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Using Forms
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Form_Resize is Not Triggered When Form is Moved



 
 
Thread Tools Display Modes
  #1  
Old January 18th, 2009, 09:11 AM posted to microsoft.public.access.forms
Stewart Berman
external usenet poster
 
Posts: 68
Default Form_Resize is Not Triggered When Form is Moved

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?
  #2  
Old January 18th, 2009, 03:51 PM posted to microsoft.public.access.forms
Arvin Meyer [MVP][_2_]
external usenet poster
 
Posts: 2,310
Default Form_Resize is Not Triggered When Form is Moved

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.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com


"Stewart Berman" wrote in message
...
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?



  #3  
Old January 18th, 2009, 11:22 PM posted to microsoft.public.access.forms
Stewart Berman
external usenet poster
 
Posts: 68
Default Form_Resize is Not Triggered When Form is Moved

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]" wrote:

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.


  #4  
Old January 19th, 2009, 03:01 AM posted to microsoft.public.access.forms
Arvin Meyer [MVP][_2_]
external usenet poster
 
Posts: 2,310
Default Form_Resize is Not Triggered When Form is Moved

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

"Stewart Berman" wrote in message
...
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]" wrote:

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.




  #5  
Old January 19th, 2009, 08:16 AM posted to microsoft.public.access.forms
Charles Wang [MSFT]
external usenet poster
 
Posts: 68
Default Form_Resize is Not Triggered When Form is Moved

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: .
================================================== =======
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================== =======

  #6  
Old January 22nd, 2009, 09:43 PM posted to microsoft.public.access.forms
Stewart Berman
external usenet poster
 
Posts: 68
Default Form_Resize is Not Triggered When Form is Moved

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.

("Charles Wang [MSFT]") wrote:

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:
.
================================================= ========
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================= ========


  #7  
Old January 23rd, 2009, 02:28 PM posted to microsoft.public.access.forms
Arvin Meyer [MVP][_2_]
external usenet poster
 
Posts: 2,310
Default Form_Resize is Not Triggered When Form is Moved

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.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com


"Stewart Berman" wrote in message
...
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.

("Charles Wang [MSFT]") wrote:

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:
.
================================================ =========
This posting is provided "AS IS" with no warranties, and confers no
rights.
================================================ =========




  #8  
Old January 26th, 2009, 10:12 AM posted to microsoft.public.access.forms
Charles Wang [MSFT]
external usenet poster
 
Posts: 68
Default Form_Resize is Not Triggered When Form is Moved

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: .
================================================== =======
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================== =======


  #9  
Old January 27th, 2009, 07:19 AM posted to microsoft.public.access.forms
Stewart Berman
external usenet poster
 
Posts: 68
Default Form_Resize is Not Triggered When Form is Moved

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.

("Charles Wang [MSFT]") wrote:

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:
.
================================================= ========
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================= ========


  #10  
Old January 27th, 2009, 07:45 AM posted to microsoft.public.access.forms
Stewart Berman
external usenet poster
 
Posts: 68
Default Form_Resize is Not Triggered When Form is Moved

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]") wrote:

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:
.
================================================= ========
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================= ========


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 12:37 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.