Hi Sean. The method that you're talking about, both in VB6, and in VS.Net requires Jaws scripts. When you press Jaws commands, Jaws moves the controls on the form. In some cases, Jaws has to talk directly to the IDE to make those changes. You wouldn't need to talk to the IDE to move a control with the mouse, but knowing about overlap and other logical relationships requires a higher level of info then looking at the raw screen contents with a screen reader. I've looked at the Applescript support for Interface Builder, and Apple doesn't make it possible to manipulate the designer surface through Applescript. As VoiceOver doesn't have an off screen model, either, this really complicates things. I'm not saying that it couldn't be accomplished to some degree, just that it is very slow. When I used to program for Windows in C++, back in the Visual Studio 6 days, I'd type in the info for a control in a resource script. The resource script was processed in to the data structures that were used to instantiate the user interface at run-time. Working this way, you can type in exact coordinates for positions and sizes. With careful calculation, you can account for the size of controls, so that you can be sure that they don't overlap. In the past, I also used resource compilers when programming for the user interface of the old Mac OS 9 and the Apple IIgs. Actually, if Apple's XIB file format was more human readable than it is, I probably would have continued that trend when starting on OS X. I'm glad that I didn't, though. In that method, you spend lots of time carefully calculating positions and sizes. Then, when you finish, you must get someone sighted to verify your work, since a screen reader won't let you know if many visual things are wrong. That's hard enough. However, if you later decide that you need to add another button to a toolbar, or change the window in some other way, you must recalculate most all of those coordinates again. It is a huge effort, and very prone to errors. The RenaissanceX way is different. I might have a block of code that is a toolbar, for example. It might contain 5 buttons. The buttons will not only be automatically sized to contain the text of the labels on them, but all of the buttons will be the size of the largest button. That is to say, they all end up being the same size, which is the size that is required to accommodate the largest button's caption. They're also automatically spaced evenly along the toolbar. If I later decide to add another button, I simply add it in the toolbar block, and the button sizing and spacing automatically adjusts so that it fits. I don't need to recalculate anything, or have a sighted person check up on me when I make a UI change. The computer is doing the calculating, which means there is a much lower chance of a problem. Anyway, I don't think that I'd prefer to use Interface Builder now, even if Apple fixed it. It might be nice for tweaking interfaces that others have built, but, if I'm working by myself, the RenaissanceX method is a better way for me, as a blind dev, to create Mac user interfaces. Bryan -----Original Message----- From: macvoiceover-bounce@xxxxxxxxxxxxx [mailto:macvoiceover-bounce@xxxxxxxxxxxxx] On Behalf Of Sean Murphy Sent: Wednesday, December 01, 2010 5:24 AM To: macvoiceover@xxxxxxxxxxxxx Subject: [macvoiceover] Re: Programming with VO HI Brian and all. Brian, Thanks for the detailed explaination. I assume Mac uses x and y pixcel coordinates positioning for objects on the screen. I am going to explain a possible way to make any GUI IDe to work and give you the necessary feedback to identify where objects are located on the form or what ever you want to call it. To explain the concept I am referring too: Main app window starts at the app top left hand corner starts at 0/0. the Bottom right hand corner ends at 600/800. I have used the standard 600 by 800 pixcel screen. If I have mix the maximum size around for give me. But you get the idea. The OS knows the application window size now. Any object contained within the App window only knows the dementions of the app window. So if an object top left hand corner is placed at 10/10. the bottom right hand corner is placed at 100/100. So your object is 10 pixcels away from the app border. Likewise applies to the bottom right hand corner. Also you can quickly work out the size of the object. Any objects that are placed on top or over the object can also be worked out with not to much trouble. As you move around the form, VO could inform you of the relative pixcel x/y position. If the object you are placing on to the form covers another object. It would not be that difficult to identify if it is at the top left, bottom left, top right or bottom right corner. Over the top of the object completely. On the top, bottom, left or right borders. I have performed exactly what I have described under the windows environment using Jaws for Windows and VB6. Yes, I am steeling ideas from windows. but this works. There are floors of course. But you can get a basic window design completed. Then someone with sight can polish the layout if required. I have heard of totally blind people laying out forms without requiring anyone to modify it. Sean > > Click on the link below to go to our homepage. > http://www.icanworkthisthing.com > > Manage your subscription by using the web interface on the link below. > //www.freelists.org/list/macvoiceover > > Users can subscribe to this list by sending email to > macvoiceover-request@xxxxxxxxxxxxx > with 'subscribe' in the Subject field OR by logging into the Web > interface at //www.freelists.org/list/macvoiceover > > > Click on the link below to go to our homepage. > http://www.icanworkthisthing.com > > Manage your subscription by using the web interface on the link below. > //www.freelists.org/list/macvoiceover > > Users can subscribe to this list by sending email to > macvoiceover-request@xxxxxxxxxxxxx > with 'subscribe' in the Subject field OR by logging into the Web > interface at //www.freelists.org/list/macvoiceover >