NUnit AmbiguousNameException - a more specific error message

wolfganguhr

Hello

I've written some trouble shouting code and I think that it may be a good idea to leve some code inside.

Inside an internal n-unit routine in some cases the AmbiguousNameException is thrown

throw new AmbiguousNameException(name);

I have replaced it by a piece of code which tells something more about the problem:

System.Console.WriteLine("+++++++++++++++++++++++++++++");
foreach (object o in found)
  {
    WriteParentListOfControl(o);
  }
System.Console.WriteLine("+++++++++++++++++++++++++++++");
throw new AmbiguousNameException(name);

In the case of txtLedgerNumber is the value of the name which leads to some trouble, you get the result:

+++++++++++++++++++++++++++++
ucoBatches.pnlContent.pnlInfo.tableLayoutPanel1.pnlLedgerInfo.tableLayoutPanel2.txtLedgerNumber
tabGLBatch.tpgJournals.ucoJournals.pnlContent.pnlInfo.tableLayoutPanel1.txtLedgerNumber
tabGLBatch.tpgTransactions.ucoTransactions.pnlContent.pnlInfo.tableLayoutPanel1.txtLedgerNumber
tabGLBatch.tpgAttributes.ucoAttributes.pnlContent.pnlInfo.tableLayoutPanel1.txtLedgerNumber
+++++++++++++++++++++++++++++

This is a list of different controls txtLedgerNumber and their parent name lists which helps to solve the problem inside the own test code.

I'll update the n-unit.dll

Best regars
Wolfgang

christiankatict

That is very good, Wolfgang. It will definitely save some time, esp. in more complicated screens!

What about feeding that improvement back to the NUnit people as a patch?

wolfganguhr

christiankatict wrote
What about feeding that improvement back to the NUnit people as a patch?

This ist not NUnit, this is NUnit-Forms. And NUnit-Forms seems to be a terminated project. Actually I'm not able to identify someone as a member or the active group and the foremost copy-right-note may be dated from 2008.

My suggestion is more to create either an own project at source forge - which actually may be a little overestimated - or to create separate branch in bzr.openpetra.org:8088/ only for the sources of that tool.

thiasg

Dear Wolfgang,

wolfganguhr wrote
christiankatict wrote
What about feeding that improvement back to the NUnit people as a patch?

This ist not NUnit, this is NUnit-Forms. And NUnit-Forms seems to be a terminated project. Actually I'm not able to identify someone as a member or the active group and the foremost copy-right-note may be dated from 2008.

My suggestion is more to create either an own project at source forge - which actually may be a little overestimated - or to create separate branch in bzr.openpetra.org:8088/ only for the sources of that tool.

you could add a branch on your Launchpad account. Then it is more visible to the community.

Matthias

wolfganguhr

Hello Mathias

If I initiate a launchpad project, I have to answer a lot of questions - the licence for example. And I'm not shure that 6 lines of code are enough to cut the umbilical cord

Best regards
Wolfgang

thiasg

wolfganguhr wrote
Hello Mathias

If I initiate a launchpad project, I have to answer a lot of questions - the licence for example. And I'm not shure that 6 lines of code are enough to cut the umbilical cord

Best regards
Wolfgang

Hello Wolfgang,

if you go to your userpage, then on the Code tab you will find the possibility to host a branch without all the question like adding an additional project...

Thias

pokorra

I have fixed this now in bzr.openpetra.org:8088/loggerhea ... ision/1097

The reason for that AmbiguousNameException was in csharp/ICT/Testing/NUnitForms/SgrdDataGridPagedTester.cs

It was necessary to overload the property
public override object TheObject
Otherwise that exception was thrown.

It was not necessary to change something in NUnit or NUnitForms for this.

wolfganguhr

That's a different problem Timotheus

I have define a button tester e.g.

btnNew = new ButtonTester("btnNew", tFrmGLBatch);

On the same dialog there are two buttons and so the error message AmbiguousNameException appears, pointing to a line like

btnNew = new ButtonTester("btnNew", tFrmGLBatch);

The error message tells me that there are two buttons

+++++++++++++++++++++++++++++
tpgBatches.ucoBatches.pnlContent.pnlDetailGrid.pnlDetailButtons.tableLayoutPanel4.btnNew
tpgTransactions.ucoTransactions.pnlContent.pnlDetailGrid.pnlDetailButtons.tableLayoutPanel2.btnNew
+++++++++++++++++++++++++++++

Now the standard solution of NUnit solves the problem:

btnNew = new ButtonTester("ucoBatches.pnlContent.pnlDetailGrid.pnlDetailButtons.tableLayoutPanel4.btnNew", tFrmGLBatch);

and also your solution solves it.

btnNew = new ButtonTester("ucoBatches.btnNew", tFrmGLBatch);

Your solution makes it possible to skip parts of the name. My solution makes it possible to find the correct name.

pokorra

Yes, I understand now, you are right, it was a different Exception that got thrown when the control was not found at all.

Another comment on this thread:
NUnitForms is not a terminated project. As you can see in the source code repository, it gets updated regularly to the latest versions of nant etc. Latest Update 2 weeks ago.
nunitforms.svn.sourceforge.net/v ... unitforms/
Yes, it seems no new features are implemented, but I don't think it is fair to say on the public Internet that NUnitForms seems dead. It is quite a useful tool.

Regarding the solution to get the full name of a control:
The problem is that the name of the tablelayoutpanels are generated by our winforms generator, so the name could change when new controls are added to the window. Therefore I prefer the solution to specify only the required names, that make the control unique.

wolfganguhr

Ok I'll reduce the names in my project part and I'll try to get in contact to the developer ...

I've subsribed the n-unit mails and I'll ask there ...