Custom Query

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (40 - 42 of 3866)

Ticket Resolution Summary Owner Reporter
#64 Rejected Enhance special description for recognizing controls junkew@…
Description

Actually 2 request(s) to combine and not yet sure whats most logical place to do (part can be done in a UDF)

"[CLASS:Edit; INSTANCE:1]" is a real powerfull way of recognizing controls. I would like to see this enhanced with more possibilities like

  • using any property that is available in Window Info tool
  • using more advanced logic like "[CLASS:*Edit*; INSTANCE:1]" regular expression syntax "[VIRTUALAREA: (Square|Circle) x1,x2,y1,y2 (RelativeWindow|RelativeClient|Desktop)]" If its not a control but a certain area which is hard to recognize (would be nice if you can select the area of interest with window info tool which you then in your script can use just as if its a control but actually is not) "[CLASS:Edit; INSTANCE:1; TABS: n]" where TABS means send n TABS to activate next control (also for lauzy unrecognizable controls due to not beeing native windows controls) n can be negative. "[BITMAP: name" search the window with bitblt or similar function till matching area is found and then use this area to act on just like its a control, name is filename/location of bitmap to use (which was previously saved with capturing tool)).
  • Have a translation table for logical and technical naming Logical name: Notepad text area Technical name: "[CLASS:Edit; INSTANCE:1]"

Then use in ControlSend("Untitled - Notepad", "", "Notepad text area", "This is some text") Where then logical name is translated to technical name

  • Translation table should have ability of grouping/hierarchy of logical names. For example

Logical Technical 01.Calculator screen "[CLASS:SciCalc; INSTANCE:1]" +---> 01.result "[CLASS:Edit; INSTANCE:1]" +---> 02.btnOne "[CLASS:Button; ID:125]" 02.Paint "[CLASS:MSPaintApp; INSTANCE:1]" +---> 01.Paintarea "[CLASS:Afx:1000000:8; INSTANCE:1]" +---> 02.Paintarea duplicate "[CLASS:Afx:1000000:8; INSTANCE:1]" 03.Calculator screen 2 "[CLASS:SciCalc; INSTANCE:1]" +---> 01.result "[CLASS:Edit; INSTANCE:1]"

Duplicates on technical level should be allowed as the main purpose is to have logical names that can be used in the scripting itself. Actually I put something like above now in an array at start of my script and have a lookup UDF but this is a tedious job (but is better maintainable instead of having all the technical names scattered in my script)

  • Integrate this in Window Info tool
  • Have in window info tool a way to predefine for each Class which properties should be combined to create special description.

So if I select notepad text window which is of Class Edit that I immediately can copy "[CLASS:Edit; INSTANCE:1]" instead of typing it in myself in my script.

I think above will be a major enhancement and gives even more possibilities for AutoIt to be used in testautomation situations and will reduce maintenance on scripting

#68 Fixed GUIWrapper not saving option Emiel Wieldraaijer
Description

When selecting a RequestExecutionLevel Scite output windows says

+>12:08:22 Starting AutoIt3Wrapper GUI v.1.9.5 -> 1 Change(s) made.

but it's not changed/saved in the script..

#71 Rejected Au3Info supporting Internet Explorer ComponentFromPoint junkew@…
Description

Would be very nice if AutoIt can do more with Internet Explorer. For a starter it will help that AU3Info easily recognizes the items from internet explorer by using componentfrompoint

see http://msdn2.microsoft.com/en-us/library/ms536375(VS.85).aspx

If I could spy on IE controls this way it will save me a lot of time to identify the properties on the control I want to interact with.

Note: See TracQuery for help on using queries.