Thanks again Joe.
explained something about the MoveWindow vs SetWindowPos.
"Joseph M. Newcomer" wrote:
See below...
On Wed, 3 Mar 2010 05:53:02 -0800, Cameron_C <CameronC@discussions.microsoft.com> wrote:
Hello again folks,
I am having a little issue with this and would appreciate any thoughts.
I have an application where I have a number of button controls that the User
can drag and drop around the screen.
This works fine.
The dropped positions are saved in the registry and when the User opens the
application again later, the controls are where ever they moved them to. And
this al;so appears to work fine.
However, I noticed that when I run on a smaller physical screen, and the
display scrolls I have an issue.
This is difficult for me to explain, but, say the actual display is twice
the size of the physical view. The User can scroll down, and drag a control
up to move it. Let's say they move it to two inches from the top of the
physical view, which is somewhere in the middle of the dialog window.
On the display it now all looks great.
However, later when the User restarts, the moved control now appears about
two inches from the top of the physical display, rather than in the middle of
the dialog.
****
Sounds like you have window-coordinate-vs-screen-coordinate problem.
****
This is the snippet I use to read the values from the registry
/*
Fetch the Button's Position from the Registry
Note that the position was written in the Formview, so the position
is relative to the Formview (X and Y values).
*/
void CDragDropButton::GetButtonPropertiesFromRegistry(int iCtrlID)
{
CWinApp* pApp = AfxGetApp();
CString strSection, strKey, strResource;
strResource.LoadStringA(IDS_BUTTONINFORMATION);
strSection.Format(_T("%s-%d"), strResource, iCtrlID);
CRect rcNewPosition;
GetClientRect(&rcNewPosition);
strKey.LoadStringA(IDS_BUTTONPOSITION);
rcNewPosition.top = pApp->GetProfileInt(strSection, strKey + _T("_X"), -1);
rcNewPosition.left = pApp->GetProfileInt(strSection, strKey + _T("_Y"), -1);
rcNewPosition.bottom = pApp->GetProfileInt(strSection, strKey +
_T("_HEIGHT"), -1);
rcNewPosition.right = pApp->GetProfileInt(strSection, strKey +
_T("_WIDTH"), -1);
if ((rcNewPosition.top != -1) && (rcNewPosition.bottom != -1) &&
(rcNewPosition.left != -1) && (rcNewPosition.right != -1))
{
MoveWindow(rcNewPosition.top, rcNewPosition.left, rcNewPosition.right,
rcNewPosition.bottom);
}
****
Is CDragDropButton the button class? Or the dialog class?
See my comments below, as well. Storing the size is nonsensical, particularly if you are
going to change resolution. The size will be wrong for the new screen size/resolution,
and must NOT be set. Similarly, the position must be client-coordinate relative for the
dialog that holds the control, and must be resolution/size independent, and you do neither
of these here. For example, the MoveWindow is going to reposition relative to the parent
window. But if the parent window is now smaller than the size it was when you saved these,
the value is nonsense.
DId you use the debugger to see what the values are? Do they make sense? Did you look in
the Registry to see what you stored?
}
****
I believe that if you are going to store things in the Registry, you should do so by using
proper Registry APIs and not fake it with clumsy ProfileInt circumlocutions. The need to
synthesize the strings to simulate hierarchical storage is remarkably clumsy. So clumsy
that I wouldn't actually consider it viable.
Take a look at my Registry library (free download, non-GPL licensing) and store things in
a structure fashion. I have a RegistryWindowPlacement class that stores window positions
and allows using GetWindowPlacement and SetWindowPlacement to manage them. [They only work
well with fixed names, but you can call the low-level methods as I show below]
****
and this is a snippet of what I use to save the values in the registry
/*
The Left Mouse Button Up has been deteected.
If we were dragging something, drop it wherever we are,
and move the object to the new location.
Write the new position information into the registry.
Fire the event off to the Formview.
*/
void CChiroPracticeOfficeView::OnLButtonUp(UINT nFlags, CPoint point)
{
TRACE(_T("ChiroPracticeOfficeView OnLButtonUp.\n"));
if (m_bButtonDragging)
{
TRACE(_T("ChiroPracticeOfficeView OnLButtonUp. Caught a Dragging situation
and released capture.\n"));
ReleaseCapture();
m_imgl.DragLeave(this);
m_imgl.EndDrag();
CPoint pt (point); //Get current mouse coordinates
ClientToScreen (&pt); //Convert to screen coordinates
// Get the CWnd pointer of the window that is under the mouse cursor
CWnd* pDropWnd = WindowFromPoint (pt);
ASSERT (pDropWnd); //make sure we have a window pointer
/*
We need to determine if we are "permitted" to Drop
onto the window underneath
*/
if ((CWnd*) this == pDropWnd) //We Can only Drop onto the View
****
There is no need to cast 'this' to a CWnd* because it is ALREADY a CWnd*!!!
****
{
CRect rc;
m_pddbDragging->GetClientRect(&rc);
m_pddbDragging->MoveWindow(point.x, point.y, rc.Width(), rc.Height());
****
If you are going to move a window, you must NOT use GetClientRect as its dimensions. You
MUST use GetWindowRect for the size. But since the point of the size is to simply provide
info to MoveWindow, you don't need it at all!
Rather than the clumsy MoveWindow, why not use SetWindowPos, which is vastly easier; for
example, you don't care about the width or height if you are not changing them.
m_pddbDragging->SetWindowPos(NULL, point.x, point.y, 0, 0,
SWP_NOSIZE | SWP_NOZORDER);
Note also that Z-order might matter, and physical layout on the screen does not change tab
order! So you will have to save Z-order information and restore it if you want the tab
key to work consistently based on layout.
****
CWinApp* pApp = AfxGetApp();
CString strSection, strKey, strResource;
strResource.LoadStringA(IDS_BUTTONINFORMATION);
strSection.Format(_T("%s-%d"), strResource,
m_pddbDragging->GetDlgCtrlID());
strKey.LoadStringA(IDS_BUTTONPOSITION);
pApp->WriteProfileInt(strSection, strKey + _T("_X"), point.x);
pApp->WriteProfileInt(strSection, strKey + _T("_Y"), point.y);
pApp->WriteProfileInt(strSection, strKey + _T("_Width"), rc.Width());
pApp->WriteProfileInt(strSection, strKey + _T("_Height"), rc.Height());
****
You are writing the wrong width and height; you need the width and height of the WINDOW
rect, not the CLIENT rect! So the window will shrink a little each time!
I;d write this as
WINDOWPLACEMENT wp;
m_pddbDragging->GetWindowPlacement(&wp);
CString name = ToString(_T("%s-%d"), strResource,
m_pddbDragging.GetDlgCtrlID());
SetRegistryWindowPlacement(HKEY_CURRENT_USER, name, &wp);
Note that these sizes make sense only if you are at the same resolution each time. So
your information is screen-size dependent. If you create a dialog on a different-sized
screen, these numbers are all, by definition, nonsense. First, you should not even
CONSIDER storing the size; the error here is in thinking you needed it. And the position
has to be stored but you must always store the size of the dialog, and when values come
in, you would have to adjust them to be relative to the size of the dialog. For example,
if the button is 50% of the way across, you want it to be 50% of the way across in a
different-sized screen, not a fixed number of pixels away. And the size should be left
untouched. So you could store either the original dialog size and the control position
(no control size, ever!), and adjust it when you came back in by computing the ratio of
the new size to the old size and adjusting the values accordingly, or instead, store a
value between 0 and 1000 (0 = left, 1000 = right, 100.0%, that is, store the position in
tenths of a percent) and compute the adjustment when you start back up.
Make sure you always have the right coordinates saved. But if you have to deal with
multiple screen sizes (and/or resolutions) you have to store these values in a
screen-size/resolution independent fashion, or readjust them on input.
joe
****
}
}
m_bButtonDragging = FALSE;
CFormView::OnLButtonUp(nFlags, point);
}
Thanks for any ideas.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.