Hi Ken, I haven't found much of anything to study on reclassing, please let me know if you do! What I was trying to say is that here's my understanding of what's going on: If you come across a control which WE describes as a custom control, this means it's likely to not know how to read it or what to do with it. I believe it gets it's info on the type of the control from the window.type property of the control (each control usually has it's own window object, which is not at all the same as the main application window (usually)). So, if you find out this custom control is really an editbox say, you can interactively indicate this to WE, and it will make note of this in a special file with a .we extension; every time it finds this control, it will treat it as an editbox from then on because of this entry in the .we file. You can do the same thing in your app by finding the correct window object for the control, and setting the type property to be the constant for the editbox type. Since you haven't created any .we file for window-eyes to use, and since GW hasn't told us how to create such .we files (officially), it's best if you make this assignment to the control's window object's type property, in your app, each time your app runs, rather than trying to create a .we file for the control which shows it being reclassed. when you do this, you are causing WE to then treat this control as an editbox; if you find out later this isn't the best thing to do, you don't have to undo any .we file you may have created on your pc (or the pc of others), you can simply stop making this assignment. As far as I know, this is the best way to handle reclassing controls in an app. We'll see if it draws a correction from anyone. hth, Chip
_____ From: Scott, Ken [mailto:[email protected]] Sent: Friday, October 07, 2011 3:29 PM To: '[email protected]' Subject: RE: Three Issues/Questions for Scripting Window-Eyes with Microsoft Access 2010 Database Program Chip, Thanks for the feedback. I think I am missing something about reclasses so I will go back and study some more. Ken From: Chip Orange [mailto:[email protected]] Sent: Thursday, October 06, 2011 7:07 PM To: [email protected] Subject: RE: Three Issues/Questions for Scripting Window-Eyes with Microsoft Access 2010 Database Program Hi Scott, reclassing a control when you do it manually using Window-Eyes keyboard commands allows it to be permanently reclassed. When you do this in a script, it's not permanent, so your script has to do this each time it runs. All you have to do is to set the window type of the control's window object (each control has it's own window) to be whatever type you think it really is. there's a list of predefined constants for each of the window types (one for each control type). so, you'd just find the correct window of the control, and then you'd have a command like: myWindow.type = wtEditbox Which sets it to be an edit box. 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
