Apparent inconsistancy with FireFly SetLoc/GetLoc Commands

[gian young]

Hi,

During the course of program development I decided to make use of the inbuilt FF_Control_GetLoc & FF_Control_SetLoc commands.

I have discovered that the X & Y values cannot be mutually used between both commands. ie the x & y values obtained with the (GetLoc) will not place the control back to the same location with the (SetLoc). The Control appears to relocate -x (3) pixels and -y (49) pixels.

This isn't a major hassle but is worth knowing about.

I used the simple test code as shown below to obtain and compare the values.

Local g_toolsmenups As POINTAPI

FF_Control_GetLoc HWND_FORMTOOLS, g_toolsmenups.x, toolsmenups.y
         
MsgBox "Form Left =  " + Format$(g_toolsmenups.x) + "   Form Top =  " + Format$(g_toolsmenups.y), %MB_ICONERROR Or %MB_OK, "Debug Message"
      
FF_Control_SetLoc HWND_FORMTOOLS, g_toolsmenups.x, _toolsmenups.y

FF_Control_GetLoc HWND_FORMTOOLS, g_toolsmenups.x, toolsmenups.y
         
MsgBox "Form Left =  " + Format$(g_toolsmenups.x) + "   Form Top =  " + Format$(g_toolsmenups.y), %MB_ICONERROR Or %MB_OK, "Debug Message"

:wink:

Gian Young

Dataman Barcode Systems Australia

[TechSupport]

?? The sample code returns the same values for me. (albeit, I had to correct some of the sample code because some of the "g_" parts of your variables were missing so the sample wouldn't compile).

What type of Form is it, a regular Form or a Form used as a child of a TabControl?

[gian young]

Hi Paul,

Thank you for your reply.

Sorry about the missing sample code, (must have dropped of in the pasting exercise).

NO!,  the form is a regular form and is not a child of the tabcontrol. It is in fact a simple non modal form I use as a floating ToolBox over the regular screen.

I got these results when I incorporated a menu command on the main form to give the user the opportunity to HIDE and SHOW the ToolBox. I naturally want the ToolBox to appear at the same spot it occupied before it was hidden.

The ToolBox itself can be dragged all over the screen if required but when hidden and then re shown using FF_SetLoc with the same X & Y coordinates obtained by the FF_GetLoc the ToolBox form appears in a different place.

I have in fact achieved the result I wanted by making use of the API GetWindowRect function instead of the FF_GetLoc. The values returned by the API GetWindowRect function match the values required by FF_SetLoc to allow the form to be shown at the same location it previously occupied.

Best Regards


Gian

[Roger Garstang]

It appears Paul originally intended for this to be used for controls only, then partially modified it.  He uses MapWindowPoints to convert the coords to those of the parent as compaired to the Desktop/Screen.  I never had much luck with MapWindowPoints myself.  I imagine either it is a rounding error in the API which I'd guess would have been found by now, or it is comparing to the client coords of the window which wouldn't include the border of the window, etc.

I think this is a case where 2 functions need to become 4 and it would add even more capabilities to FF.  Maybe a Get_Screen_Loc and a Get_Client_Loc and Set functions for each.  Where the Screen version just uses GetWindowRect and SetWindowPos as they are with no mapping.  The Client version would use the same thing but with mapping, and using ScreenToClient/ClientToScreen instead of mapping them with MapWindowPoints.  So the Get function for client would get the Screen Coords as usual then convert it to client like:

ScreenToClient(GetParent(hWndControl), rc)

And, the Set function for the Client would take the given Client coords and convert them to screen like:

ClientToScreen(GetParent(hWndControl), rc)

Then SetWindowPos and all is well.

[gian young]

Thank you Roger,

I believe you are spot on, the explanation is greatly appreciated and hopefully of value to other observers.

Best Regards


Gian Young