Spinning a JavaSpin field with QTP

Image by Tonyç via FlickrSometimes its good to be reminded that there are things out there that simply just don't want to work. These always present a challenge. The most recent example is a simple case of a Java application with a spin button for selecting the time with the obvious requirement of being able to set a value. Hmmm...

Spin fields are created as a combination of a couple of buttons inside of an edit field. Rules are then applied to the buttons in terms of their effect on the value. Rules also apply to the value itself. Simply though, there are 4 objects within this one field. The container which is the spin control. An edit field for the value. A button for increasing the value and another button for decreasing the value.

QTP was not happy. There is a Set function that works on the spin object and should set the value of the control. Now while GetROProperty("value") works, the Set function does not. It actually would have been nice for it to have failed with an error rather than doing nothing.

Another simple option also exists... set the edit field to the value. This would have been great except that the Set function for the edit was reported as being invalid - the joys of a composite Java field.

Since every specific object in QTP is simply an extension of the object type, it would seem reasonable to try switching to that level. Another failure. The object can be found but setting the value results in an invalid method failure.

Well ultimately setting a value simply requires that the object be activated and then a Type should work. Now QTP does not provide activate functions for all the Java objects. Not a big deal as an activate is the same as a click on the object.

Ha! Not this time. The click function, which is nothing more than a simulation of a mouse click would not activate the spin field. This was a weird one. Seriously surreal.

OK. Going back to the spin control. QTP provides functions for Next and Prev values. I know already that running these functions does not change the spin field - probably just as well as I would probably have been able to set the hour but would have been unlikely to have accessed the minute field. This exploration did however show a flicker in the field.

Regardless of testing you work in, noting any effect/flicker/change in the application is essential. This flicker lead to the solution... as weird as it turned otu to be.

The solution involved the following:

1. Run the spin object's next function
2. Send a home keypress to the window by typing micHome to the Java window object
3. Type the value to be captured to the Java window

This worked great... on one field. Testing against the second spin field on the same page resulted in more weirdness. The value "2121" was being typed as "121n" (where n was the original value at that position). Running the test code twice though, captured the value correctly. I checked this bizareness three times and in each case, the first field was perfect the second was not.

The implication was to obviously run the type portions twice against the spin field. So the final solution turned out to be:

1. Run the spin object's next function
2. Send a home keypress to the window by typing micHome to the Java window object
3. Type the value to be captured to the Java window
4. Send a home keypress to the window by typing micHome to the Java window object
5. Type the value to be captured to the Java window

Its interesting that most solutions to seemingly intractible problems are actually extremely simple. Pity that they're not obvious.

Notes Abound

Image via WikipediaMoving from a client site can be a tad frustrating. You organized the email, notes, documents, code, and various other things to made the project work easier. Then off you go to somewhere else potentially leaving a whole slew of necessary items behind. This particular move has been somewhat interesting.

I've essentially moved between departments but I started with the other department with about 6 weeks to go till the end of my tenure within the original area. The company is very compartmentalized. Computers do not flow between areas. So the loss of potentially critical data was of some real concern. Email was a probable problem - inbox size limits seem to be met if the excessive measure of a weekly archiving is not brought into effect.

Retroactively working through 14 months of data can be down right daunting. Hopefully the system adopted will remove this problem. The idea is to print any important and relevant emails to PDF and to save them with the project data to a project folder. This should make all data for a specific project available in a central store.

Meetings are always a problem. For now I've synchronized the work calendar to my Google calendar. While I'm not sure about this it has proven to have been a prudent move as access, email, etc have not yet been sorted out for the new department.