1. Let's separate the long command into two stages.
oRoot.GetLeaf("...").Input("...") is actually two commands:
oRoot.GetLeaf("Web Example_Browser_Page_Knowledge Base"), which returns the clsTreeLevel object corresponding with Web Example_Browser_Page_Knowledge Base (or Nothing if it can't find a corresponding clsTreeLevel).
After the object was returned, we execute its .Input method. This method will return the True/False result of the input action.
So if, for instance, the script wouldn't find the corresponding excel level, we wouldn't get "FALSE", but rather a script error, as we would've tried to execute a .Input method on a Nothing object (which has no methods).
To make it more clear, you can see this one long command as a shortcut for this code:
GeSHi (qtp):
Set oRelevantTreeLevel = oRoot.
GetLeaf("Web Example_Browser_Page_Knowledge Base")bResult = oRelevantTreeLevel.
Input("Knowledge Base>Env. Techniques>Web>Dynamic Java Trees>Example>Sub Example")If bResult =
True Then MsgBox("Input successful")Else MsgBox("Input unsuccessful")End If Created by GeSHI 1.0.7.20
3. Yes, each excel level is translated into a clsTreeLevel object.
Your confusion begins with the job of the .Input command.
The command already assumes the clsTreeLevel object exists (it is activated from that object). It's job is to try and perform an input action on that level. If this level were a textbox, the action would've entered text into it.
The input command is very elaborate, and has many different stages. One of these stages, is to activate the mini-class connected to the clsTreeLevel object.
So when you execute oRoot.GetLeaf("...").Input("..."),
one of the things that will happen is the activation of the .Input method in the InputWebJavaTreeClass.
Another thing that happens as part of the input action is the activation of the .GetCurrentValue in the InputWebJavaTreeClass.
As for the object identification string - Whenever the clsTreeLevel tries to manipulate its connected QTP object, it checks to see if that object is already initialized. If it's not initialized, it calls the LoadQTPObject method to initialized it. The LoadQTPObject uses the object identification string to build a DP QTP object.
4. Type is meant to be a kind of business logic marker of the excel level's "job" in the application. It has no "real" meaning, but it can be used to control certain things in your script.
For example, in my projects, I only report the input actions on objects whose Type property = "field" (as one fields may contain many different objects, and I don't want a separate report for each and every one of them). I sometime designate the save button of a window as type="Save", and then I can generically automate the save operation (as I never use the specific button's name, but rather search for a button with the type property = "save").
5. In the root of the FrameworkManager's folders there should be a .CHM file, with a lot of help sections, as well as complete code documentation. I would also recommend going through every example (not just 7), and maybe even using the debug mode to see exactly what gets called and when.
No problem, I thank you for investing the time to understand the framework and try to use it.
You don't need to understand all the ins-and-outs of the framework (e.g. how exactly is the QTP Object built for each level), but I would strongly recommend you'll know the JOB of each public method and property in the clsTreeLevel class (you can use the code documentation for that), the purpose of every column in the excel file, and track a .Input command via the debug mode from start to finish at least once.
