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, -- David _______________________________________________ Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Ai Squared. For membership options, visit http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/corange%40psc.state.fl.us. For subscription options, visit http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com List archives can be found at http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com _______________________________________________ Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Ai Squared. For membership options, visit http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/archive%40mail-archive.com. For subscription options, visit http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com List archives can be found at http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
