No problem.  The DLL vs EXE is mostly just a compiling change.  Rather than
compile as a DLL compile it as an executable for use on the Mac.  I have a
small static void Main() in my EXE that inits the monobjc framework.  Yes a
console app would work, though it will not run from the console, only from
within the cocoa app.

Yes you can use Core Data, though I have been advised not to use Core Data.
In fact the advice was to use the datasource solution.  So yes the table
view will ask the mono layer for every row and every column.  I have not
tested this for performance.  And yes you can populate the core data
entities from within mono and it should show up in the UI... haven't tried
it myself.

NSNotificationCenter has a few methods to post notifications, you can
observe for notifications within mono as well as send.

It does seem odd to revert back to using the datasouce method essentially
not using the advances of bindings and core data.  But the theory is this
will greatly reduce the amount of code.  I have not verified performance of
the datasouce method.  As is right now I populate the tree controllers
manually from within C#, which works.  Though now I'm trying to use mutiple
NIBs and my current approach is causing problems in splitting the NIBs.

Duane

On Fri, Nov 21, 2008 at 11:34 AM, Mario De Clippeleir <[EMAIL PROTECTED]>wrote:

>  Thanks a lot Duane !
>
>
>
> Couple of questions though :
>
> -          The reason I want to work with the DLL is because I include
> this in another Windows Forms project, which has the Windows Gui. Should I
> compile it then to a Console application ?
>
> -          The way you explained it, is that you have to populate
> everything yourself.. is it possible to use the Core Data Framework ?
>
> -          (perhaps silly question : what do you mean by
> "PostNotification" ?)
>
> -          If you embed the datasource methods in the c# class, isn't that
> like polluting the model with View methods ?
>
>
>
> Thanks for helping me out !
>
>
>
> Mario
>
>
>
> *From:* Duane Wandless [mailto:[EMAIL PROTECTED]
> *Sent:* vrijdag 21 november 2008 16:51
> *To:* users@lists.monobjc.net
> *Subject:* Re: [EMAIL PROTECTED] Data binding
>
>
>
> Not knowing what you have accomplished already I will briefly describe what
> I have done.  When I find time I'll post something with pictures.  My main
> application is a Cocoa ObjC app that controls the GUI.  When the app starts
> the very first thing I do is load my C# EXE, note not a DLL.  A bug/issue
> exists that loading a DLL does not completely init the mono environment.
>
> Using Monobjc I export my C# classes to the Cocoa world.  This is why the
> mono executable must be properly initialized first, so that when the NIB
> files are loaded by Cocoa it will find my registered mono classes.
>
> In the NIB file I add an NSObject and set the class to be the name of my C#
> class, say MonoObject.  Add some class outlets to the MonoObject in the NIB
> file that point to array/tree controllers within that NIB file.  The tree
> controller's mode should be class and the class name most likely will be
> NSMutableDictionary, though it can be a class defined in mono as well.  You
> can add keys to these controllers to make binding easier on the table
> views.  Speaking of the table views, you simply point them to the tree
> controller and bind as usual.
>
> Back in your C# class you will have a NSTreeController variable that is
> hooked up by monobjc to the tree controller in the NIB file.  Whenver
> appropriate you can, from within C#, clear the tree controller data, add
> data, remove data etc.  I call something like
> treeController.addObject(<myobject>) where myobject is an instance of a C#
> class.  That class then must register the methods to expose the keys you
> have setup in the tree controller.
>
> You most likely will need to send a reload data notification to the views
> that use these tree controllers.  So you should also set class outlets that
> point to these views so that you can send them reload data messages.
> PostNotification is a nice way to send messages to your mono class so that
> it can load the data as needed.
>
> Another solution is to set your table view's/outline view's datasource to
> be MonoObject.  Just provide the datasource methods in your C# class.  I
> have not implemented this way but I think I'm leaning toward switching.
>
> Not a lot of detail here but hopefully it helps.
> Duane
>
> On Fri, Nov 21, 2008 at 9:44 AM, Mario De Clippeleir <[EMAIL PROTECTED]>
> wrote:
>
> Hi,
>
>
>
> I am trying monobjc to port an existing .NET application to the Mac. I
> would like to use a DLL in which an object model resides. When loading a
> file, the object model is being filled. This logic is all in the library.
>
> Now, my question is : if I want to use binding for the Mac gui, do I need
> the "wrap" the object classes from the library into Managed object classes ?
> What would be the best way to handle this ?
>
>
>
> On another note : In the latest monobjc distribution, I can't seem to get
> the TwoManyControllers project working. "The document TwoManyControllers.exe
> could not be opened. TwoManyControllers cannot open files in the EXE File
> format."
>
> I mean, it loads up, but you can't do anything…
>
> Does anyone else has this problem ?
>
>
>
> Thanks,
>
>
>
> Mario
>
>
>

Reply via email to