[Drawkit] validateMenuItem:

[Graham Cox]

On 24/06/2009, at 12:05 AM, V1ru8 wrote:

> DKDrawingView *view = [self mainView];
>    DKViewController *controller = [[MyDKViewController alloc]  
> initWithView:view];
>    [view setController:controller];
>
> Maybe thats the  wrong way?


I'm afraid so, though it's not too difficult.

The network of relationships between views, the drawing and the  
controllers needs to be carefully orchestrated, so simply creating a  
controller and adding it to the view isn't sufficient, at least at  
present (it might be possible to revise the code to allow this to work).

Normally you would override the -makeViewController method of the  
view, and return the controller object you want. To do this you  
naturally have to subclass the view - the thinking here is that if you  
have a special view, you will probably want a special controller for  
it, so this is readily available to a subclass. Alternatively the  
document gets a shot at this also, in its -makeControllerForView:  
method - this hands off to the drawing view if it implements the above  
method, or makes a default controller for any other view (the thinking  
here being that controllers could be made for arbitrary views that use  
the drawing as the data model, such as a layers list view, or anything  
else you like).

If you really don't want to subclass, you can stitch together the  
correct relationships quite easily as follows:

DKDrawingView* mainView = [self mainView];
DKViewController* controller = [[MyViewController alloc]  
initWithView:mainView];
[[self drawing] addController:controller];
[controller release];

This is assumed to be taking place in the document that owns the  
DKDrawing instance. The DKDrawing instance in turn owns the  
controllers. It's also important *when* this takes place, since there  
must actually be a drawing instance and a view available so that the  
controller can be placed in between them. Overriding the mentioned  
methods avoids this being an issue, as they are called at the right  
time, but if you're doing it yourself, it needs to happen either in - 
setDrawing:, or -windowControllerDidLoadNib. If you look at the code  
you'll see it does both by default, to allow for different ways that  
views and drawings might come into existence.

Note also that if you do the above in addition to the standard setup  
(rather than replacing it), you should first remove the old controller  
from the drawing or it will leak. Again, overriding the appropriate  
methods avoids that issue.

So, I suspect the problem with your code is that it's not happening at  
the right time, and the default controller is getting made and  
installed after yours, putting the system into its normal state. If  
things work properly (other than your menu) I'd say that was the case,  
since if your controller were there but not being linked up correctly,  
most things wouldn't function.

The attached diagrams may help in understanding some of the object  
relationships in DK.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: DK Object Relationships.pdf
Type: application/pdf
Size: 17021 bytes
Desc: not available
URL: <http://lists.apptree.net/pipermail/drawkit-apptree.net/attachments/20090624/1b73e29f/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Object relationships 2.pdf
Type: application/pdf
Size: 19719 bytes
Desc: not available
URL: <http://lists.apptree.net/pipermail/drawkit-apptree.net/attachments/20090624/1b73e29f/attachment-0003.pdf>
-------------- next part --------------