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.
Created attachment 5563 [details]
When enabling the linker the class NSPrintPreviewGraphicsContext is not linked in.
As a result when the user access the Print dialog via File -> Print or Cmd + P the application crashes with the following exception.
System.ArgumentException: Could not find a valid superclass for type NSPrintPreviewGraphicsContext. Did you forget to register the bindings at MonoMac.ObjCRuntime.Class.Register() or call NSApplication.Init()?
- Run the attached project (linking is enabled)
- Go to File -> Print
`NSPrintPreviewGraphicsContext` is a special type and we'll add the code to handle it in a future release. In the meantime you should be able to workaround this by adding:
somewhere inside your code. The linker will see (and mark) the type and it will be available at runtime. That will allow you to re-enable the linker.
Fixed in maccore/master d047ee123f3bfc28126bb9258878fccfed8d1c7a
Backported in maccio/macios-cycle5 31b1c12e4d8890b585da9e8016b10246f3d0c6f1
The workaround (from comment #1) won't be needed in XM 2.0+
I have checked this issue with the following builds:
Xamarin Studio Version 5.9 (build 210)
Installation UUID: 011d70a5-dede-428b-ab04-ef451c2e539d
Mono 4.0.0 ((detached/1bd3b8a)
GTK+ 2.24.23 (Raleigh theme)
Package version: 400000051
Apple Developer Tools Xcode 6.2 (6776)
Xamarin.Mac Version: 126.96.36.199 (Business Edition)
=== Build Information ===
Release ID: 509000210
Git revision: f32ddb8c1f9836ba5e018ac51056008e9a1ac208
Build date: 2015-03-12 10:06:56-04
Xamarin addins: abfe34dd3ad6ef1a3b720d6cd74441c8e7aa22ff
Operating System Mac OS X 10.9.5
Darwin MacMini.local 13.4.0 Darwin Kernel Version 13.4.0
Sun Aug 17 19:50:11 PDT 2014
I observed that this issue is working fine. Now, user when access the Print dialog via File -> Print or Cmd + P the application does't crash.
Here is the screencast for the same: http://www.screencast.com/t/c6qX4iS3
This issue has been fixed, hence I am closing this issue.
I am doing a custom scheme pagination and also custom page border drawing. It seems that getting NSGraphicsContext.CurrentContext in DrawPageBorder (of the view being printed) leads to the following unhandled error:
MonoMac.RuntimeException: The ObjectiveC class 'NSPrintPreviewGraphicsContext' could not be registered, it does not seem to derive from any known ObjectiveC class (including NSObject).
at MonoMac.Registrar.DynamicRegistrar.Lookup (IntPtr class, Boolean throw_on_error) [0x00000] in <filename unknown>:0
at MonoMac.ObjCRuntime.Class.Lookup (IntPtr klass, Boolean throw_on_error) [0x00000] in <filename unknown>:0
at MonoMac.ObjCRuntime.Class.Lookup (IntPtr klass) [0x00000] in <filename unknown>:0
at MonoMac.ObjCRuntime.Runtime.GetNSObject[NSGraphicsContext] (IntPtr ptr) [0x00000] in <filename unknown>:0
at MonoMac.AppKit.NSGraphicsContext.get_CurrentContext () [0x00000] in <filename unknown>:0
at ProjectViewer_mac.SimpleReportRenderer.DrawPageBorder (SizeF borderSize) [0x00000] in <filename unknown>:0
at (wrapper managed-to-native) MonoMac.ObjCRuntime.Messaging:bool_objc_msgSend (intptr,intptr)
at MonoMac.AppKit.NSPrintOperation.RunOperation () [0x00000] in <filename unknown>:0
at ProjectViewer_mac.MyDocument.PrintReport (ReportsStandardEnum reportType) [0x00000] in <filename unknown>:0
In debug config this does not happen. Fortunately, I got away with the workaround suggested by Sebastien Pouliot. This issue should be reviewed and reopened or a new issue should be filed.