I m reading a Kudan for Unity exaple project
(Kudan is a framework for AR)
in the file KudanTracker.cs they use a TrackerBase object called _trackerPlugin
using UnityEngine;
using System.Collections;
using System.Collections.Generic;
#if UNITY_EDITOR
using UnityEditor;
#endif
namespace Kudan.AR
{
[DisallowMultipleComponent]
[RequireComponent(typeof(Camera))]
[AddComponentMenu("Kudan AR/Kudan Tracker")]
public class KudanTracker : MonoBehaviour
{
protected TrackerBase _trackerPlugin;
public bool ArbiTrackIsTracking()
{
return _trackerPlugin.ArbiTrackIsTracking();
}
...
}
So i head over to TrackerBase.cs to see the implementation for ArbiTrackIsTracking() but all i find is this:
using UnityEngine;
using System.Text;
using System.Collections;
using System.Collections.Generic;
using System.Runtime.InteropServices;
namespace Kudan.AR
{
/// <summary>
/// Base class for the tracker plugin. This abstracts the native plugin for each operating system.
/// </summary>
public abstract class TrackerBase : ITracker
{
public abstract bool ArbiTrackIsTracking ();
...
}
}
How is it possible to call a method that was never implemented?
where is the implementation hiding?
thank you
They probably deal with it, like Microsoft dealt with the XmlReader:
You are using a derived class for the object you are using, but access it via its base class.
In the XmlReader it goes like this:
XmlReader reader = XmlReader.Create("something");
and then you can read every element within the xml-file via
reader.Read();
But as you can see, XmlReader.Read() isn't even implemented: Source
Instead, XmlReader.Create() creates an XmlTextReader which inherits from XmlReader and implements everything, especially how Read() is handled.
I guess they do the same in the plugin. See here in the API it states "Implemented in Tracker" KudanAR - Unity Plugin V1.4
This is perfectly normal.
Such behavior is normal, IF the class is properly instantiated with a non-abstract version of Trackerbase.
However, you don't provide the relevant instantiation code, so its impossible for me to verify if the code sample you provided is properly instantiated or not, without myself going to get that code.
Theoretically, the instantiation code might look like this:
//Constructor
public KudanTracker(TrackerImplementation track) {
_trackerPlugin = track;
}
IF the code has proper instantiation, such as above, you're fine.
It's impossible to call an abstract method without any implementation.
As the comment for TrackerBase class says, Tracker classes are different for each OS, so look for TrackerWin.cs or something like that
Related
This is an image of the errors
This is the script
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.SceneManager;
public class LevelComplete : MonoBehaviour
{
public void LoadNextLevel ()
{
SceneManager.LoadScene(SceneManager.GetActiveScene().BuildIndex + 1);
}
}
Please help me with the errors
I tried to debug the error by checking the script and UI animations that connect to the event that changes the scene. I also tried using SceneManager.LoadScene (name); but it did not work.
You have two issues here. First of all, you declared the class twice. It might be twice in the same file, or in different files. Second of all, you need to use UnityEngine.SceneManagement instead of SceneManager.
The simplest solution is to check for double declarations, and for the using, replace
using UnityEngine.SceneManager; with using UnityEngine.SceneManagement.
In Nunit C# Im trying to open the application only once and make modification to it, for example i created this demo of Notepad application. In my real time project,i just have to log in to the application just once and execute all 100 test cases and only then close the Desktop application. Kindly tell me what am i doing wrong here,thanks a lot! Btw,im new to C#
using NUnit.Framework;
using OpenQA.Selenium.Remote;
using System;
using OpenQA.Selenium;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Threading;
namespace Notepad
{ }
[SetUpFixture]
public class BaseClass
{
public static IWebDriver driver;
[OneTimeSetUp]
public static void AssemblyInitalize()
{
var dc = new DesiredCapabilities();
dc.SetCapability("app", #"C:\\Windows\\System32\\notepad.exe");
driver = new RemoteWebDriver(new Uri("http://localhost:9999"), dc);
Thread.Sleep(5000);
}
[OneTimeTearDown]
public static void oneTearDown()
{
driver.FindElement(By.Id("Close")).Click();
}
}
---First Test---
namespace Notepad
{ [TestFixture]
public class Notepad2:BaseClass
{
[Test]
public void test2()
{
driver.FindElement(By.Id("15")).SendKeys("My Teacher ");
}
}
}
---- Second Test Class ----
using NUnit.Framework;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using OpenQA.Selenium;
namespace Notepad
{ [TestFixture]
public class NoteTest : BaseClass
{
[Test]
public void Test()
{
driver.FindElement(By.Id("15")).SendKeys("...is Coming now");
}
}
}
Regarding SetUpFixture, the first answer is incorrect.
SetUpFixture works exactly the same way as it has always worked. If you have a SetUpFixture, it's OneTimeSetUp and OneTimeTearDown methods will run once for all the fixtures under the same namespace.
On the other hand, inside a TestFixture the OneTimeSetUp and OneTimeTearDown methods run just once for the fixture itself.
In other words, the methods run "one time" within the particular scope in which they are used, namespace or fixture.
The problem is that you are using the same class as both a SetUpFixture and as the base class for all your TestFixtures. That means if you have n test fixtures, it will run n + 1 times! That's what you are seeing.
SetUpFixtures do not (have never had) anything to do with fixture inheritance. You should either make your class a SetUpFixture or a TestFixture base class. If, for whatever reason, you need both, then use two classes. In this case, you need only the SetUpFixture, without the inheritance.
When to inherit from a base class: When you want the same code to execute many times, once for each fixture. Note that your base class, when used for one-time setup and teardown in this way, should normally not be marked as a TestFixture.
When to use a SetUpFixture: When you want some code to execute only once, before every any fixture runs and again once after all the fixtures have run.
In your example, you are using a SetUpFixture to control the timing of the initialization. You are using inheritance to allow you to share the driver. Problem is that the OneTimeSetUp in the base class is actually part of each test fixture and you don't want that.
I'd be concerned about a hundred or so tests all using the same driver. I've seen some people use one driver per test and others one driver per fixture_. Using one for __everything implies that you are being extraordinarily careful that each test cleans up after itself and restores the driver to the same state. I doubt that's possible.
However, as an exercise, here is how to do it if you really want to:
1. Have a base class with nothing but the driver member.
2. Derive the SetUpFixture from the base class and create / destroy the driver there.
3. Derive the TestFixtures from the same base class. They use but don't change the driver.
From the documentation, OneTimeSetup is called once before all tests in a TestFixture. Your example has two fixtures, so the set up is called twice. You need to have all your tests in the same Fixture.
This behaviour is different to the old [Setup] on SetupFixture attribute, which ran once for all tests in a namespace.
I have a Visual C# 2010 application, and it has one main form called MainWnd with other tool windows and dialogs. I want the other tool windows to be able to 'talk' to the main form, and call its methods. But that requires an instance of MainWnd, and since there will only be one of these forms created at any given time there is no reason while I should enumerate through all instances of MainWnd or look for the first one. So I want my main application form MainWnd to be a singleton so other windows can easily call code from it.
Here is the code of the main form that I would like to make a singleton:
using System;
using System.ComponentModel;
using System.Windows.Forms;
namespace MyLittleApp
{
public partial class MainWnd : Form
{
public MainWnd()
{
InitializeComponent();
}
public void SayHello()
{
MessageBox.Show("Hello World!");
// In reality, code that manipulates controls on the form
// would go here. So this method cannot simply be made static.
}
}
}
I am looking to be able to call SayHello() from another form, simply by writing:
MainWnd.SayHello();
How could I accomplish this?
You could probably find a way to make the main window a singleton, however that's not the best way to achieve the outcome you want, nor is it really an appropriate situation in which to use the singleton pattern.
If all of the other tool windows/ dialogs are encapsulated within the main window, then a much better pattern to use for communication would be events.
Have the inner windows/dialogs raise events to represent a 'request' for the main window to do something. Have the main window subscribe to these events, and do the work via the event handlers.
By avoiding the singleton approach, you avoid the difficulties of testing the singleton, as well as avoiding extensive explicit circular references, where not only does the main window have references to the encapsulated windows/dialogs, but they in turn have explicit references back to the main window.
See below.
using System;
using System.ComponentModel;
using System.Windows.Forms;
namespace MyLittleApp
{
public partial class MainWnd : Form
{
public static MainWnd Instance;
public MainWnd()
{
Instance = this;
InitializeComponent();
}
public void SayHello()
{
MessageBox.Show("Hello World!");
// In reality, code that manipulates controls on the form
// would go here. So this method cannot simply be made static.
}
}
}
You can now use it anywhere in your code by calling MainWnd.Instance
All its members are also available to the instance.
You can certainly do this.
public MainWnd Instance = new MainWnd();
Then access as MainWnd.Instance.SayHello().
Replace following calls
MainWind instance = new MainWnd();
To
MainWnd instance = MainWnd.Instance;
I am not sure how Visual Studio designer would react after making the constructor as private though.
But if it does not allow, it will be Visual Studio issue, rather than language/compiler issue.
This is an example console application (it will run fine after adding the Unity NugGet package) that seems to show a bug in Unity:
using System;
using Microsoft.Practices.Unity;
class GC { public static UnityContainer Container = new UnityContainer();}
class Program
{
static void Main(string[] args)
{
GC.Container.RegisterType<MyView>();
var myView = GC.Container.Resolve<MyView>();
Console.ReadLine();
}
}
public class MyClassDesign: MyClass{}
public class MyClass: VMBase<MyClass, MyClassDesign>{}
public abstract class VMBase<TViewModel, TDesignVM> where TDesignVM:TViewModel
{
static VMBase()
{
if (!GC.Container.IsRegistered(typeof(TViewModel)))
GC.Container.RegisterType(typeof (TViewModel), typeof(TDesignVM));
}
}
public class MyView
{
public MyView(MyClass myClass)
{
Console.WriteLine("Bad: "+myClass.GetType().ToString());
Console.WriteLine("Good: "+GC.Container.Resolve<MyClass>().GetType());
}
}
The output is:
Bad: MyClass
Good: MyClassDesign
The resolved type is MyClass. But it should be MyClassDesign. (The static constructor runs prior to MyClass being resolved in the MyView class.)
How can I get Unity to allow me to setup my Mapping in the Static Constructor?
Note: When I changed this setup the UnityContainer with a file (instead of in code) it all works fine. But I would rather not be dependent on an external file for this. (I am making a reusable template that I don't want to have too many dependencies in.)
Why do you want to put the registration logic inside your view model at all? This couples your application code to the container which is never a good idea. Have a look at the concept of Composition roots.
All setup code for the DI container should be placed there.
This isnt really a bug with Unity. The issue is that the static ctor is not run until an instance is requested (at which point unity still does not know about MyClassDesign). Which means that Unity has already started creating an instance of MyClass to fulfill the request. Any subsequent calls to GC.Container.Resolve<MyView>(); will result in the output you expect. As Sebastian Weber suggests, putting all your setup code in a completely seperate location (so your classes are not dependent on a specific DI container) is the best option.
Consider following piece of code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace RemotingNonVirtualCall
{
class Program
{
static void Main(string[] args)
{
var domain = AppDomain.CreateDomain("Second Domain");
A extA = (A)domain.CreateInstanceAndUnwrap(typeof(A).Assembly.FullName, typeof(A).FullName);
Console.WriteLine(extA.CurrentDomain());
}
}
[Serializable]
sealed class A : MarshalByRefObject
{
public string CurrentDomain()
{
return AppDomain.CurrentDomain.FriendlyName;
}
}
}
Method A::CurrentDomain is non-virtual, class A is sealed. But CLR intercepts method call and redirect it to another instance. How it is possible? Is it some sort of voodoo magic? Does CLR make some exception in method calling for object inherited from MarshalByRefObject class? How is it performed?
Thanks for advance.
It's essentially magic, i.e. the ability to do this is built into the .NET runtime. The good news is that your code can also do this, if it needs to: http://msdn.microsoft.com/en-us/library/system.runtime.remoting.proxies.realproxy.aspx
The JIT compiler is keenly aware that it generates code for a proxy. You can have a look-see with the SSCLI20 source code, clr\src\vm\jithelpers.cpp, search for "proxy".