forums.silverfrost.com

[Catherine Rees Lay]

Okay, so what I'm trying to do is respond to a window resize message by moving some of the buttons so they stay close to the right hand edge. They're initially located using the %ap method. Here's my trial callback just moving one button, attached to a %`mv code:

INTEGER*4 FUNCTION RESIZE_WINDOW()

INCLUDE 'FADCOM_F.INC'
INCLUDE 'FFNAMES.INC'
INCLUDE <WINDOWS.INS>

INTEGER I,TCC_DRAW_FUNC,IX,IY,IW,IH,JX,JY,JW,JH
EXTERNAL TCC_DRAW_FUNC

CALL SIZE_GRAPH_GRIDS
call get_window_location@(tcc_window,ix,iy,iw,ih)
call get_window_location@(CSHWND,Jx,Jy,Jw,Jh)
CALL MOVE_WINDOW@(CSHWND,IW-200,JY)
I = tcc_draw_func()
RESIZE_WINDOW = 2

END FUNCTION RESIZE_WINDOW

CSHWND is the handle of the button in question and tcc_window is the window it's in.

It almost works - except that JY comes back 50 larger each time it is called, with the result that my button walks rapidly off down the screen as I resize the window!

What did I miss? Do I have to take the height of the titlebar into consideration somehow? Is one of the Y values the top of the button and the other the bottom? I don't want to "fix" it only to have it fail on different screen resolutions.

(I appreciate this is an "if I were you I wouldn't start from here" situation but I've inherited an old, complex program and all the controls are positioned using %ap. Losing that isn't really an option.)

Thanks in advance for any suggestions,

Cath.

[IanLambley]

Catherine,

I've just replied to another post with the solution to this problem. Unfortunately all the code did not appear, so here it is again.

.
.

I have recently had a battle with the positioning of window controls and so I've modified Paul's code a little to show positioning of %ib controls using
GET_WINDOW_LOCATION@ & MOVE_WINDOW@.

A couple of problems to overcome first. The get_window_location@ actually returns the position of a control relative to the top left corner of the window, but the move_window@ is relative to the first pixel under the caption bar and to the right of the LH border. Of course, these positions vary with text size and windows style (standard or XP for example). If there is a %mn then it is the first pixel below the menu.

What I did, and there is probably a better way, was to construct a dummy window on startup, which places a caption and a menu, followed by an %rd control. Using a %sc callback, which returns 0, closing the dummy window, I position the %rd to 0,0 and get its position. Add 1 to the x & y positions and use this as the offset from the top of the overall window. Subsequently the get_real_control_location routine simply subtracts these from the get_window_location@ positions to get a location relative to the first usable space. This can then be used to set the %ib or any other control to a new location. After a window resize, the overall window size could be adjusted to account for any dramatic repositioning of controls that you have carried out.

I know it is a bit long winded, but it might help.

Paul,
Is there any way to get the locations relative to the same point that move_window@ uses?

Regards

Ian

PS the code is in the next post.

[IanLambley]

You will need some bitmaps to try this directly, but only for %ib contols

[Catherine Rees Lay]

Thanks Ian! I suspected it was something like that going on, but didn't know which variant it was.

(Silverfrost folks - this is SILLY! Please can we have a function returning control position with the same offset as move_window@ so that we don't have to do all this messing about? Or an option as to which the current function returns?)

[LitusSaxonicum]

I'm impressed that Ian was able to work out, from the FTN95.chm, that GET_WINDOW_LOCATION@ works on individual controls (no matter how convoluted it may be) as well as ordinary and child windows. I suppose the clue is that the help file talks about "moving individual controls", and MOVE_WINDOW@ and RESIZE_WINDOW@ mention not simply %hw, but also getting the handle of the %lc "last control".

I Agree with Catherine.

Eddie

[IanLambley]

Elementary my dear Eddie,

You are absolutely right, it was the %lc that gave it away! Hopefully Sherlock would be proud of everybody who figures out the obscure behaviour of ClearWin+.

I started fighting when I was trying to create an "Explorer" type view with a %bv & %lv pair of controls, combined with a %pv to try to resize them both. That was months ago and I gave up and stuck with fixed size windows. Perhaps now that I have had a bit of success after many nightmares on the subject, I should try again, unless anybody else has it sorted out and can give me a few pointers.
For example, problems would include widening the left hand %bv window and narrowing the right hand %lv window by picking up the boundary between them - I haven't got a clue about that one, and could only get the overall resize to nearly work, apart from the jumping about of controls of course.

Help!!!!!!!!!

Regards

Ian