Feature Request: User code arguments

Bug reports.
tallahassee101
Posts: 169
Joined: Thu Jan 13, 2011 2:06 pm

Feature Request: User code arguments

Post by tallahassee101 » Fri Jun 08, 2012 2:42 pm

Hi,

I love the new Feature in version 3.3 that allows us to pass arguments through the recording into our user code methods. This is an extremely useful tool that is going to allow us to create tests faster that cover more cases.
The feature request I have is to be able to pass arguments to another CS file's user code. We have created a "Common" user code file that stores common tasks that require user code. Currently we would still have to write a new piece of user code for our recording that calls the Common user code method. We have several common user code methods that are used quite often in our tests.

Thank you for considering our request and thank you for the great new feature!
-Nick

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: Feature Request: User code arguments

Post by Support Team » Fri Jun 08, 2012 9:31 pm

Actually, this is already possible if you let a recording inherit from your Common class. You can then select the inherited methods from within the recording in your user code actions.
Just edit the *.UserCode.* file of the recording and specify your Common class as the base class.
public partial class Recording1 : Common
{
...
Regards,
Alex
Ranorex Team
.
Image

tallahassee101
Posts: 169
Joined: Thu Jan 13, 2011 2:06 pm

Re: Feature Request: User code arguments

Post by tallahassee101 » Mon Jun 11, 2012 5:30 pm

That is incredibly useful! Is there any way to do multiple inheritance? I tried comma separation but that didn't seem to work for me.

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: Feature Request: User code arguments

Post by Support Team » Mon Jun 11, 2012 6:33 pm

tallahassee101 wrote: Is there any way to do multiple inheritance?
No, sorry, the .NET Framework does not support multiple inheritance. You can achieve a similar effect by letting class A inherit from B and let B inherit from C.

Regards,
Alex
Ranorex Team
.
Image

tallahassee101
Posts: 169
Joined: Thu Jan 13, 2011 2:06 pm

Re: Feature Request: User code arguments

Post by tallahassee101 » Tue Jun 12, 2012 9:29 pm

Ok, that's what I was going to do if multiple inheritance was not an option. I am getting this warning however doing single inheritance:

'TacViewLib.UISpecific.BreakThroughFilters.Setup.repo' hides inherited member 'TacViewLib.UISpecific.Common.CommonUserCode.repo'. Use the new keyword if hiding was intended. (CS0108) - C:\Ranorex\TacViewLib\UISpecific\BreakThroughFilters\Setup.cs:34,55

Here is the code:

Code: Select all

namespace TacViewLib.UISpecific.BreakThroughFilters
{
	public partial class Setup : Common.CommonUserCode
	{
....
The user code methods from Common.CommonUserCode are available in the recording, however this warning comes up as if something is wrong. Am I doing something wrong? The warning points to the following line in the corresponding generated cs file:

Code: Select all

        public static TacViewLib.TacViewLibRepository repo = TacViewLib.TacViewLibRepository.Instance;

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: Feature Request: User code arguments

Post by Support Team » Wed Jun 13, 2012 11:48 am

Hi,

as both the inheriting and the inherited class have a member called repo which is automatically generated via code generation it's not really possible to get rid of this warning.
Basically, as we can say it's not a good idea to inherit one recording from another.

Regards,
Tobias
Ranorex Team
.
Image

tallahassee101
Posts: 169
Joined: Thu Jan 13, 2011 2:06 pm

Re: Feature Request: User code arguments

Post by tallahassee101 » Wed Jun 13, 2012 5:51 pm

Thank you, I totally looked over the fact that CommonUserCode was defining a variable "repo". CommonUserCode is just a cs code file, not generated. So this works great now, thanks for the new feature!

Huggybear
Posts: 1
Joined: Thu Jul 12, 2012 11:25 am

Re: Feature Request: User code arguments

Post by Huggybear » Thu Jul 12, 2012 11:40 am

I am using a "common" file much like you are.
But if you need the repo within your common file just make it private

private static TacViewLib.TacViewLibRepository repo = TacViewLib.TacViewLibRepository.Instance;

then it will not bug you with warnings and you can access all your repository handles from the common file :D

I had the same porblem with a desire with multi derive:
My test modules derive the common file
and the common file derive all my hw/instruments handles (another file)
This allows me to power on/off and measure stuff within a recording, its pretty sweet

tallahassee101
Posts: 169
Joined: Thu Jan 13, 2011 2:06 pm

Re: Feature Request: User code arguments

Post by tallahassee101 » Tue Apr 16, 2013 9:51 pm

So in Ranorex 4.02 this no longer works again. We just recently upgraded from 3.3 to 4.02 and now the usercode that inherits from the baseclass is generating empty methods that are in the baseclass. This generates the same warning as before:

Code: Select all

'TacViewLib.Common.SetDeclutterState.TurnOffDeclutter()' hides inherited member 'TacViewLib.Common.CommonUserCode.TurnOffDeclutter()'. Use the new keyword if hiding was intended. (CS0108) - C:\Ranorex\TacViewLib\Common\SetDeclutterState.UserCode.cs:35,21
Additionally its generating empty methods that will override the baseclass methods and cause the tests to no longer work since the baseclass won't be called.

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: Feature Request: User code arguments

Post by Support Team » Wed Apr 17, 2013 9:51 am

Hi,

There is unfortunately an issue in 4.0.3 under the following case, but this should work with 4.0.2, so could it be that you use 4.0.3?
When UserCode Class inherits from Class A and Class A inherits from Class B and the method is defined in Class B, the method is not found and therefore it will be replaced. However it should be found and not be replaced.
Again this problem is only known to exist in 4.0.3.

Regards,
Markus
.
Image