The first attempt had controls with their text cut off and all presented in 2 columns with a third effectively empty. What I created was two Groups, their Frame set to None, and manually fill each one with controls or more sub-groups so that they balance out in total height of control content. A little 'meh' but it will do. Next I manually set their Width properties to 0 (changing the WidthMode, see here). We will be hitting the X++ to next set their width values. I also set the General tab's ColumnSpace value to 10, and it's LeftMargin + RightMargin to a value of 5. The Columns value is set to 2 of course. Everything has it's AutoDeclaration set to Yes of course.
What I ended up doing was going to the land of WinAPI and attempt to get a handle on the General tab's rectangle dimensions - see the getWindowRect API and the RECT object it returns. From there it was a case of some simple math, thus:
public void run()
{
int iWidth, x, y, k, l;
;
SysListPageHelper::handleRunPreSuper(element, ctrlTabForm, 3, 2);
super();
[x, y, k, l] = WinApi::getWindowRect(General.hWnd());
iWidth = (k - x
- 20 // General.ColumnSpace + General.LeftMargin + General.RightMargin
- 20 // Magic fudge factor
) / 2;
GeneralGrpCol1.width(iWidth);
GeneralGrpCol2.width(iWidth);
SysListPageHelper::handleRunPostSuper(element, ctrlTabForm);
}
It's not perfect, and I shall have to test it some more but it's far better than before! As you can see from the above code there is a fudge factor which means that I'm missing something in the total width calculation - any suggestions?Another example of the WinAPI::getWindowRect can be seen in a blog post capturing Ax form screenshots. Finally, as we're in WinAPI land, I refer you to a useful post as to how to obtain screen sizes and the like.
All of this work simply because I was a web developer where everything on the page can be designed to 'float' around each other... In conclusion then I DON'T recommend this approach!
No hay comentarios:
Publicar un comentario