Hi Ken, My apologies for a delayed response, and for hurrying through the first one and getting your name wrong! sorry! I absolutely agree; there's nothing wrong with you also maximizing any window; the person may not be running the other app just to begin with (just thought I'd mention it in case it made your life easier). Good luck with your app. Chip
_____ From: Scott, Ken [mailto:[email protected]] Sent: Friday, October 07, 2011 2:09 PM To: '[email protected]' Subject: RE: window class and object class; was Scott's question Chip, Thanks! Your reply on window class verses object class with the example and background gave me exactly what I needed so I do not expect this thread to continue. I apologize for asking multiple questions in my original Email message. I am so knew at scripting that I could not get my questions into separate Emails in an understandable form when I tried. I am aware of the GW Micro MSAccess app. It does kind of work in Access 2010, but is too limited or is not working correctly on my system. I sent GW Micro support an Email explaining my results with the MSAccess app several weeks ago. I got no feedback from them. I thought that I read or heard somewhere that scripting best practices suggestes avoiding depending on external apps where practical; thus, the idea of maximizing windows within my script. I certainly do not mind making my life easier so I will go ahead and use the Window Manager app. I had thought that if GW Micro did not improve or fix their MSAccess App that I might post my finished app to App-Central if I get it to work better than GW Micro's app. Again thanks Chip. Ken From: Chip Orange [mailto:[email protected]] Sent: Thursday, October 06, 2011 6:38 PM To: [email protected] Subject: window class and object class; was Scott's question Hi Scott, I'll take a shot at your questions, but I'll try and separate them into different threads, so not all of the answers will be in this one email (just in case we start a longer discussion, emails with lots of questions can easily become confusing). * First, just wanted to mention that GW does have an MS Access app which improves Access usability, but I'm not sure if it's for 2010 or not. Also, they have an app named window manager, which can be used to automatically maximize a window, given it's title (or it's class if the title changes). Still, I know you could be doing this just for your own practice and education. * I need to clarify a point: the class name of a window object, isn't related to a class of object which you might find in some program's object model, or which you might create with the createObject command. So, what strings you find in the window-eyes window object's className property, are whatever the programmer decided to call his window as he wrote his program. So, if you use the analysis tools and you find a window with a class name of "oTable"; then that is the name of the class for that window which you can work with inside of window-eyes. This usually has no relation to say, any object inside the Access object model, and it's only purpose would be to help you identify which window you are working with. While you could possibly maximize the window using the Access object model, it's much more likely you'll be able to do it using window-eyes scripting commands, and a whole lot easier. The usual way is to watch for the window you're interested in to be created, and work with it directly as soon as it is created. You'd use some commands like: gDeskTopOnChildCreateEventConnection = connectEvent ( desktopWindow , "onChildCreate", "DeskTopOnChildCreateEventHandler") sub DeskTopOnChildCreateEventHandler(ReturnedWindowObject) ' here you'd test to see if this was the right window and then maximize it end sub to watch for it being created. The only time you would get involved with the Access object model might be if you could not do something any other way. I had a quick look at the Access 2010 object model, and I didn't see any window object for the current active window; but even if they do have one, it would be a lot more trouble to make use of. hth, Chip _____ From: Scott, Ken [mailto:[email protected]] Sent: Wednesday, October 05, 2011 1:10 PM To: '[email protected]' Subject: Three Issues/Questions for Scripting Window-Eyes with Microsoft Access 2010 Database Program Hi gw-scripting list members, I am attempting to improve the usability of the Microsoft Access 2010 database program with Window-Eyes. I am not a programmer of any kind let alone an object oriented one. I have done some analysis of the Access 2010 and Window-Eyes combination. I also listened to all of the podcasts and read all of the documentation that I thought applied to what I am trying to do. I am left with three issues/questions. One thing that I am trying to do is to automatically maximized the Access 2010 windows. The problem is that I am getting two object.classnames for what appear to be the same object depending on what analytical tool or approach that I use. If I use, Gw Micro's Window Manager to check on classnames for objects, I get one result. If I use the Object Browser in Chip Orange's Microsoft Word based development environment, I get another Classname. For example, in Window Manager there is a OTable classname, whereas, in the Object Browser, there is a table classname. Can anyone suggest which version of the object classname that I should try first when scripting to maximize the windows? The second problem that I am having is determining the syntax to load set files based on off screen events. I plan to use the presence of Access window objects plus view button status to load set files. My first issue. What is the property/method to load a specified set file? I did write GW Micro Support asking about this situation. I was told about the window.loadset object. Unfortunately when I check the Window-Eyes developer reference, this object appears to tell if a set file is loaded and not to load a set file. Second, what is the syntax for using an accessible string as part of an operation. I can find a long string that gives the name of a view button and its pressed verses unpressed status in my analysis. I do not know how to write this into an operation. My tentative idea for a syntax is something like: If window.classname = OTable and Datasheet view status = pressed then loadset.TableDatasheetView. If anyone can suggest how precisely the above hypothetical operation should be written I will be forever in your debt. The third area of trouble is in reclassing a custom control. If I understood the Window-Eyes developer reference correctly, I need to use the type object to reclass the object. I will need to first use the retrieve property to place the custom control into my script. I then need to use the set property plus the type to reclass the custom control. If the custom control is okttbx and need to be reclassed to an editbox, what would these operations look like? If I have confused you, please send me any follow up questions that you have. Regards, Ken Scott
