Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Adding a custom UIView and setting its class to something derived from iPhoneOSGameView will not work as it does not appear in the custom class list in identity inspector.
An easy way to see this is as follows.
1) Create a new solution and select c#->MonoTouch->iPad->OpenGL Application
2) Click on OpenGLViewController.xib
3) In Xcode, select the view and click on the identity inspector tab. The Custom class should be EAGLView
4) change the class to something else, eg just a plain UIView
5) Try changing it back again. You will see EAGLView is no longer in the list
There is no way to recover other than starting the project from scratch again or fooling IB into detecting your class by temporarily deriving it from UIView, selecting it in IB and then putting the code back as it was.
Is there an objective-C header file for EAGLView? If so, what is its base class?
MonoTouch needs to decorate it's EAGLView with a [Register] attribute, probably.
EAGLView is in the template, not the class libraries, and MD used to have logic to short-circuit though unexported intermediate classes when exporting to Obj-C.
The problem appears to be that IType.GetAllBaseTypeDefinitions () is returning a list of types in bottom-up order instead of top-down order.
Mike: can you fix this?
As a workaround, can we just sort those ourselves?
In NRefectory it's documented as working that way, which seems unintuitive, and definitely different from the old behaviour. I wonder how many places are being affected by this.
Where are you using that and why ?
Fixed in master and 3.0.x branch.