Hi David,
Yes, I absolutely agree, this feature of WE (which is an absolutely great feature (the XML
dialogs)) does need a little more attention for exactly the reasons you mention. To get around
this, I use a lot of nested groups, specify only the width of the outter most group using actual
dialog units, and use width and heights of either "group" or "fill". I have
found this gives the automatic dialog positioning algorithms the best chance of generating postions
and widths and heights that I'm the happiest with.
I've found it's not actually the positions that are sometimes the most
problematic, but the widths and heights which the positions are then generated
from.
So, to give you a rough idea of what I mean,I may want a column of buttons down
the left, next to an editbox, which I would like to fill all the space
remaining in my dialog.
I also add the window sizing option to the dialog, so that a user with a bigger screen
can "maximize" my dialog and see even more if he's sighted.
I would then start out specifying the main dialog's width and height in units;
I don't like doing this, but without doing it, the automatic positioning of WE
is just far too often not usable. So, I may specify 800 wide and 400 high. I
would then check the position and the size of my window using one of the
developer tools which give you this information (TreeView from AI, or Vic
Beckley has written an app named Focused Window Detective, which tells you
about your currently focused window (such as the editbox) and the parent
window, in an easy to use way). I use these numbers and my resolution of the
moment (which I don't set too high so I can hope what I generate will be
something all users can run), to be sure the dialog I'm generating is not too
large. Later on as Tom said, I'll use the mouse to try and verify that info is
showing up for all controls. I'll adjust these number as needed, somes as the
last thing I do for the dialog.
I'd make my main group horizontal, and I'd define two groups within it, both vertical.
I'd set the ChildAlign property of the main group to "top", so my controls and
any borders of my two vertical groups aligned at the top (don't know if this is the most
attractive, just what I prefer).
I'll put my column of buttons in the left vertical group, and my editbox in the right one. I won't
define the width of the left vertical, because it's just buttons, and I've found WE will generate a
group just wide enough to hold these buttons, which is just what I want. I'll probably set it's
height to be "group", so it will be the same height visually as the right vertical group
holding the editbox which is also going to have a height of "group" (again, just a
preference, but I do this when the buttons have some relation to what's in the editbox).
I usually give these groups a black frame (border), but again am not sure if this is the
most attractive or not. I use a lot of nested groups, and so when you get down to a low
enough level, I do stop giving them frames, and instead set it to "none". I do
always give a group of radio buttons a visible frame.
For the vertical group on the right (here's the important part), I'll set the width to "fill", and the height to
"group". Since I made this right vertical group's parent be horizontal, then you can only use "fill" for the width of
its children. The height being "group" will have the same effect that I want as "fill"; that is, if the user exercises
the "maximize" choice, the outer group will enlarge in both dimensions, and so the width of the right vertical group will expand
to fill any extra space in the outer group, and the height of both vertical groups will expand to match the height of the outer group.
I don't set the height or width of the buttons in the left group, but for the editbox which I put in the right vertical
group, I will set the height and width to be "group" when it's the only control in its group (as it is in
this example), or I will set it's height to "fill" so it will take up as much of the right vertical group as
it can after room as been calculated for the other controls in the group. Note again that since the editbox parent is
a vertical group, you can only use "fill" in the height of the editbox. The rule is that you can only
"fill" in the direction of the control placement axis of the parent group.
Later, I made decide that these buttons and their editbox are just one part of a more complex
dialog, so I'll just insert them as a unit into a dialog which has other groups for the other
controls I want to show. I do end up with a lot of nested groups (take a look at the xml of the
Remind Me Where app, especially the dlg_GetDirections1 dialog), but this works for me when I take a
sort of modular approach in designing the dialog. You do have to keep track of when you're using
"fill" and "group" as widths or height, but it ends up giving me the most
possible room for editboxes and listboxes which otherwise, can sometimes end up with a width or
neight of 0 when WE calculates it.
Hth,
Chip
Chip Orange
Florida Public Service Commission
Computer Systems Analyst
850-413-6314
-----Original Message-----
From: Scripting
[mailto:scripting-bounces+corange=psc.state.fl...@lists.window-eyes.com] On
Behalf Of David via Scripting
Sent: Thursday, March 31, 2016 9:35 AM
To: GWScripting
Subject: Small wish for the XML dialogs
I have an idea, for an enhancement when constructing XML dialogs. That
is, if it is possible... :)
When defining an element, you can set the hight, width and the X and Y
positions. Yet, for a blind person, with no sighted assistance, this is
really quite a hit-and-miss job. OK, we got the AUTO feature for Hight
and Width, and to play safe as can be, that might be the one way to go.
But then we have the actual positioning of the element. Had all screens
looked the same, and all fonts been the same size, we could have gone by
screenpoints. But even that is a hit and miss. So, AISquared has
provided the chance to position our stuff on TOP, at BOTTOM, or align it
in the CENTER or near the LEFT and RIGHT edge.
I just wondered, if it would have been possible to implement a chance
for me, to define the size of the element percent-wise, in both the X
and Y direction. I could then have decided that my button should sit in
the upper left corner, and take up say 10 X-percent, and 5 Y-Percent. My
Next element, an edit box, I could have defined to sit 15 percent down
the X-line, and cover the next 3 X-percent. that is, it would start at
X15, and end at X17 percent. And it would stretch from Y20 to Y49 percent.
Hope the above gave a bit of meaning. The Dialog could then - all in the
background - do all the percent calculation, based on the actual size of
the dialog on the current computer, screen and under the currently
conditions that affects the dialog's physical size. It would have been a
bit easier, for me as a blind person to have things correctly positioned
and sized, did I have some tangible and reliable numbers to operate with.
In other words, could we have a feature to set the actual upper-left and
lower-right corners of an element, and also the starting position for
it, all based on percents of the total dialog size?
Anyone have some input on this?
Thanks,
