forums.silverfrost.com

[wahorger]

I have a test program at the link below that operates differently in a normal %ww window versus a %ch child window.

This little program is designed to test the capabilities of creating a %gr drawing then manipulate it in its enclosing window. The "X" position is to remain fixed, while the "Y" position can be changed.

For testing purposes, and mouse motion on the graphic with a left button down should cause the graphic to move up or down by one pixel, regardless of the actual range of motion.

The %gr item inside the child window responds appropriately, while the %gr inside the main window does not. In the latter case, it will move in both X and Y.

It would appear that the position of the graphic in the main window is returned relative to the full window, yet setting the location of the %gr is made relative to the client portion of the window. Thus, selecting the main window %gr with the mouse and moving it up or down by 1 pixel will cause the object to move down and to the right.

NOTE: On my system, as I move the main window graphic, there appears above the graphic a white space. It can be seen when the graphic moves across the child window (grey) area. I do not see a similar effect when the child %gr is moved.

Link to DropBox: https://www.dropbox.com/s/cmpf7gzi8e9vg6j/BoreHoleWindow.zip?dl=0

[PaulLaidler]

Bill

For a child window GET_WINDOW_LOCATION@ gets the location relative to the parent using two calls to the Windows API GetWindowRect.

MOVE_WINDOW@ simply calls SetWindowPos using the given hWnd and (x,y).

So when using GET_WINDOW_LOCATION@ with MOVE_WINDOW@ in your program it is necessary to allow for this.

[wahorger]

Thanks, Paul.

[wahorger]

Looks like %gr won't work for my particular application (dimension limitations) anyway.

%gr has a lot of nice features to simplify the interfaces/callbacks, though. I'll remember it for later use.

Thankfully, on to the next option!!
Bill