[Mono-osx] [MonoMac] MonoMac add-in

[kjpou]

I forgot to reply all so it would also go to the list.

Kenneth

On 1/28/11 4:19 PM, kjpou wrote:
> Michael
>
> Thank you for the response.
>
> You need to add the added files to the addin's<Runtime>  element so
> that they get included in the addin when packed for the online
> repository.
>
> did not see those but have added them.
>
> In the .xft.xml files, LanguageName should be C#.
>
>
> I forgot to ask what that should be in my post.  Have now changed it 
> to c#
>
> Also, they both have
> a DependsOn for a nonexistent xib file,
>
>
> I thought I had taken those DependsOn out already.  Anyway got them 
> out for sure now.
>
> and since they don't have
> designer classes, don't need to be partial.
>
> For the way I was using them they had to be partial.  Probably short 
> sighted on my part (see below about the Register)
>
> Maybe I don't understand the purpose of the "Inherited NSView", but I
> assume they are meant to be able to be created either programmatically
> or as a child widget in a nib (rather than the owner/root widget).
>> From programmatic use, it would be useful to have a parameterless
> ctor, and for using in nibs it would be good to add a Register
> attribute to make the objective-C name of the class explicit (since
> there is no designer class doing this).
>
> Added the constructor that takes no parameters.  I assumed that it 
> would inherit the NSView constructor.
>
> I thought about the Register as well but the way I am using it there 
> was no need to add the Register.  Here is the only way I have been 
> using these.
>
> Within my nib I create a subclass of a NSView with the name of the 
> class I am going to use for example MyCustomView.  Then on the Custom 
> NSView that I add to the ContentView I change the Type to MyCustomView 
> within IB.  When I save this it is automatically sent back to the 
> designer class via the MonoDevelop Bridge with IB.
>
>     // Should subclass MonoMac.AppKit.NSView
>     [MonoMac.Foundation.Register("MyCustomView")]
>     public partial class MyCustomView {
>     }
>
> This automatically is registered and is marked as partial.  Thus you 
> can not decorate with Register nor mark the class as non partial.
>
> As I said probably a little short sighted.
>
> Kenneth
>
> On 1/28/11 7:56 AM, Michael Hutchinson wrote:
>> On Thu, Jan 27, 2011 at 11:36 PM, kjpou<kjpou at pt.lu>  wrote:
>>> Hello all
>>>
>>> This may not be found useful but would have definitely loved the
>>> Inherited NSView while going through the Core Animation Book samples.
>>> They are very simple and was just trying to get my feet wet with the
>>> add-in code.
>>>
>>> What it does is add two new File types to the add-in.
>>>
>>> Inherited NSView    -    Creates a class that inherits from NSView.
>>> Inherited NSWindow    -    Creates a class that inherits from NSWindow.
>>>
>>> These do not create NIB files associated like what is delivered but are
>>> used to override what is defined in a NIB file when creating a custom
>>> view or custom window.
>>>
>>> I definitely find the Inherited NSView handy and a time saver.  
>>> NSWindow
>>> less so as have only had need to do that twice so far.
>>>
>>> Added the Inherited NSWindow because it was basically a copy and paste
>>> of the Inherited NSView.
>>>
>>> If there are problems with what was done please let me know.
>> You need to add the added files to the addin's<Runtime>  element so
>> that they get included in the addin when packed for the online
>> repository.
>>
>> In the .xft.xml files, LanguageName should be C#. Also, they both have
>> a DependsOn for a nonexistent xib file, and since they don't have
>> designer classes, don't need to be partial.
>>
>> Maybe I don't understand the purpose of the "Inherited NSView", but I
>> assume they are meant to be able to be created either programmatically
>> or as a child widget in a nib (rather than the owner/root widget).
>> > From programmatic use, it would be useful to have a parameterless
>> ctor, and for using in nibs it would be good to add a Register
>> attribute to make the objective-C name of the class explicit (since
>> there is no designer class doing this).
>>