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. |
|
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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. ================================================== ======= |
#7
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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 | |
|
|