There is currently only extremely limited support for our WPF controls at the moment via QTP alone. We are in the process of developing TestAdvantage for WPF to support our NetAdvantage WPF controls version 10.3 and higher, due out by the end of the year, with a by request CTP available via sales@infragistics.com.

I have a feeling the install of TestAdvantage may have been slightly flawed. Try putting quotes around the tbmgrRibbonTab and tbmgrClick. The reason being, a number of releases ago, we started using QTP version of enumerations called ListOfValues. In the install it builds those ListOfValues for you and when QTP sees them they translate the values into Int16 values that we our methods understand. If that part of the install fails, then QTP sees the values like tbmgrRibbonTab and tbmgrClick as variables names that are not set, and when it attempts to send it to our actions it dies before it gets to us to throw a clean error message.

Putting quotes around them is a simple test to see if that is the issue. The file not installed properly or not referenced properly is the TypeInformationFile called TestAdvantage.QTPServer.TypeInformation.xml. It needs to be either in a place where QTP knows where to look for the file or a registry entry that tells QTP to look in its current location.

   This behavior typically comes up on one of two occasions, a partial manual install where the step to add the registry entry was not done, or during a install scenario where QTP and TestAdvantage were installed back to back without running QTP at least once, before installing TestAdvantage. The help lists the steps to correct it in :

Manually Setting Up TestAdvantage for Windows Forms (for HP QuickTest
Professional software) step 4.

Hi Brian,

Unfortunately no, you need to use the version of TestAdvantage with an identical Major and Minor assembly version number, and CLR. So in your case you would need to use TestAdvantage 7.3 since you are using NetAdvantage 7.3.

GetNAProperties is only really an exploratory method to help learn more about the property names and their data types. It’s useful for testers who may have limited access to their developers and want more information on the fly. If you do have access to your developer it should be easier to ask them what that datatype is and what properties it has.

If for some reason that is not a viable option for you, there are other methods. Albeit they will require a greater amount of understanding of code. You could use .NET Reflector, have it open your application, then find the data type that you are looking for.

According to your previous entry in the forums, you would need to expand the references of your application, right click on the reference to Framework, and select Go To Assembly. Find that assembly, which hopefully should be either in the directory of your application or it’s bin directory. If you find that assembly, then you can search for it via F3 or View-> Search to search for “Summit.Framework.View.DDItem”, double click it in the search window to highlight it in the main window. Finally right click it and select dissemble. It should open a Disassembler window.

Use the information that you garner from that to access the data via GetNAProperty. Note that GetNAProperty returns allows you to dig down through public properties. It will only return values of properties for simple datatypes such as string, int, double, datetime, etc.

As I stated this is a much more advanced method of trying to learn about a particular object, and is why we created GetNAProperties, but as this is not a window open to you, due to versioning restrictions, and if the developer is not available to you, it is at least an additional option.

 

  A ticket has been opened, and it could be useful if you contacted our developer support directly on this matter. The issue from what I can tell is that you are getting an exception:

'Error Object doesn't support this property or method: 'objectTBarSubMenu.Tools'  Line (183): "countToolBarSubSubMenus = objectTBarSubMenu.Tools.Count".

It is basically saying that the subMenu object that you retrieved does not have a Tools property. Since I imagine you were expecting some form of PopUpMenu, which would have a Tools property, then likely the Tool you grabbed is not a PopUpMenu tool.

Why it isn't I cannot say, I can say possibilities, one of which is the Tool you grabbed, is an MdiPlaceHolderTool, which is used when the actually tool you want is housed on a parent form and not on the child form that you are interacting with. To access the tool you want, you need to see if the UnderlyingTool property has a value or not, and if so get the Tools property of that.This of course is typically really only a possibility if you have a form within another form, in which the parent form has the same tool in it even if you closed the child form.

It could also be some flaw in how you are getting the subMenu, it's honestly hard for me to tell without walking through it, but again I would suggest checking to see if the CaptionResolved is what you believe it to be. If it is, and it using UnderlyingTool does not resolve it, then I would recommend contacting our DeveloperSupport to have them walk through it with you.

You will likely have to ask your developer about Type 'Summit.Framework.View.DDItem', as this is likely a value type specific to them. The exception "is not marked as serializable" basically means it's a custom data type, that was not made in a way to be passed out of the .NET framework cleanly. GetNAProperty can dig into it further as it is doing so while still in the .NET framework and return a serializable property value from it. Likely in your case you are looking for a string value. Your developer should know the property names of that object and which one is the one you should use.

If you are using TestAdvantage 10.3 or later, you can use the GetNAProperties method, which is used similarly to GetNAProperty, but instead of attempting to return the value of the property of the name you supplied, it instead returns all of that available property names and their datatype names, off of the property value of the name you supplied.

Hi Brian,

I am not sure of how you mean with your distinction between short description and long description as those are not properties of a ValueListItem, and your developer may be getting them from any number of places.

I would try both DisplayText and DataValue as these are most likely.

So in code either :

sListValues = sListValues + objectTable.GetNAProperty(sValListItems & “[“& cstr(x) & “].DataValue”) & vbCRLF

or

sListValues = sListValues + objectTable.GetNAProperty(sValListItems & “[“& cstr(x) & “].DisplayText”) & vbCRLF

It's hard to say specifically what's wrong with it by looking at the code. But what I can say is, likely the Tool it's interacting with at that moment is not what you believe it is, either it's null, a tool that doesn't have subtools, or is merged from a parent mdi toolbar, and therefore is just a placeholder tool, that you need to look at the UnderlyingTool property to interact with it.  Start with eliminating the excess. When it hits the error at that line, look at the values of all the pertinent local variables, to get your bearings of is it where you believe it is, and is the tool you are interacting with is the type of tool that you expected.