Hello Ammar,

Actually, the controls we are using are .NET Win Forms controls; the application is a desktop based app. What other things can I possibly try? Are there log files I can send you to ensure configurations are in order?

Fayez

Hi Fayez,

    There are a number of possibilities, almost all stem around the idea that either the .NET add-in is not functioning as expected.  There are a number of possibilities why. The reason why I believe this, is with the .NET add-in functioning as expected, if it identifies an object as deriving from a WinForms control it it maps it internally to an identifier with the prefix of swf. It then uses the swfconfig.xml to see if there is a custom proxy, such as TestAdvantage, defined for the control type, and if it finds it uses that to define how to handle the control. If it doesn't find one, it uses it's internal definitions instead. The fact that it is identifying the object as Window and WinObject, means that QTP is not identifying either the Window or the control as .NET controls for some reason, and therefore is not attempting to load a custom proxy such as TestAdvantage, so while you may or may not have the correct version of TestAdvantage, at this point it is not a factor.

    That being said, some of the root causes for the .NET add-in to not function correctly are, not installed\not enabled\not licensed. This I believe from previous entries in the thread we can rule out.

     Another possible factor that could cause QTP and in turn the .NET add-in issues are the application is running in 64 bit mode, this should only be possible if the machine is a 64 bit machine. If it is, and your application wasn't built specifically to target an x86 CPU architecture then it will run in 64 bit mode, and not record properly. QTP has created a patch for this(QTP_00699.EXE), but it only works with QTP 11 on Windows 7.Since you are using TestAdvantage 10.1 one suggestion I have is to try recording on the installed samples, as of 10.1 we compiled our samples to always target the x86 CPU, and therefore they will always run in 32bit mode. If they work, this maybe you problem.

    Another possibility is  QTP, the application under test, or some of it's references are not on the local machine. If this is the case I would try installing them all on the local machine and see if this resolves your behavior.

   The latter two possibilities have a wider range of outcomes, from crashing the AUT or QTP, just not recording, as well as just recording Window\WinObject hence why we go mainly to the first one.

    If none of the suggestions seem to correct your behavior, let me know and I will be happy to have one of our developer support personnel open a case for you, and we will work with HP on your behalf to try to resolve this for you. Some information to have handy at the start of any case such as this would be to have:
     QTInfo.html - You can get this via Help -> About QuickTest Professional -> Click to generate product information
     swfconfig.xml - may not be necessary for this case but always useful to have. Located under the dat folder of QTP's install directory
     process information as gathered from the sysinternals freeware application processexplorer. You can easily get this online, instructions on how to get the necessary information is below:

  Start QTP
  Open up Process Explorer
      Select the AUT process
      Make sure the following columns are visible in the upper pane view Description, Company Name, Image Type for the exe’s are visible via right clicking on the column in the upper pane view -> Select Columns -> Process Image tab
      Make sure the lower pane view is displaying DLL’s, either simply (Ctrl+D) or View->Lower Pane View->DLLs
     Make sure the data is fresh, IE the update speed wasn’t paused (Ctrl+2) or View->Update Speed-> 1 second
      Make sure the following columns are visible in the lower pane view Name, Description, Version, Company Name and Path for the dll’s are visible via right clicking on the column in the lower pane view -> Select Columns -> DLL tab
      Record the data supplied via (Ctrl+A) or File ->Save As…

Let me know how it turns out,

Thank you for the detailed explanation. I'm going to address your suggestions one at a time in order to better rule out potential causes:

1. Your concern with the .NET add-in not being installed/enabled: The QTP Splash screen confirms that both .NET/Web add-ins are loaded upon launch of the QTP application. Furthermore, under Help -> About QuickTest Professional 11.00, the same add-ins are confirmed to be active.

2. I reinstalled the QTP software for good measure; please note that we are running the 30-day eval version, but I highly doubt that that is the case -most applications include the full feature set in their trials. So unless this is a know issue, it's a moot point.

3. I'm running a 32-bit machine with Windows XP Pro SP3; I suspect that QTP is running in 32-bit mode, but if there's a way to verify I'll be happy to do so.

4. The application under test includes all resources; required assemblies where bundled, and I verified that said assemblies live in their proper place.

5. I am more than happy to provide you with the data sets your require. What would be the best way to deliver them to you?

Thanks again for taking the time.

Fayez

Hello Fayez,

Once you have the information that Mike requested, you can attach it by putting it into a ZIP file and attaching the ZIP file by clicking the Options tab when writing your post.

Good day Dave,

I have uninstalled and reinstalled TestAdvantage and now the sample applications are registering activity in QTP when I'm recording a test. This is not the case with our application which uses NetAdvantage controls.

I thought I would let you know in case this might help you identify the problem better.

Thanks again,

Fayez

Hello Fayez,

Thanks for the update.  One thing that could cause QTP to not record properly is having a version of TestAdvantage that's different than the version of NetAdvantage the AUT is using.  Please check to ensure that both are the same.