NSOutlineView no volver a dibujar

Question

Tengo una NSOutlineView con casillas de verificación. Tengo el estado casilla unido a un elemento del nodo con la clave shouldBeCopied. En el punto de nodo tengo los captadores y definidores de esta manera:

-(BOOL)shouldBeCopied {
    if([[self parent] shouldBeCopied])
        return YES;
    return shouldBeCopied;
}

-(void)setShouldBeCopied:(BOOL)value {
    shouldBeCopied = value; 
    if(value && [[self children] count] > 0)
        [[self delegate] reloadData];
}

La idea aquí es que si se comprueba que el padre, así que si los niños. El problema que estoy teniendo es que cuando puedo comprobar el padre, que no actualiza la vista de los niños si ya se expanden. Puedo entender que no debe ser actualizada por los enlaces porque no estoy realmente cambiar el valor. Pero debe reloadData no causar los enlaces para volver a obtener el valor, -shouldBeCopied por lo que exigen a los niños? He intentado algunas otras cosas como -setNeedsDisplay y -reloadItem:nil reloadChildren:YES pero ninguno trabaja. Me he dado cuenta de que la pantalla se actualiza cuando SWAP para Xcode y luego de vuelta otra vez y eso es todo lo que quiero, así que ¿cómo hago para que se comporte de esa manera?

Answer 1

Tengo una NSOutlineView con casillas de verificación. Tengo el estado casilla unido a un elemento del nodo con la clave shouldBeCopied.

¿Está enlazando la columna o la celda? Usted debe enlazar la columna.

-(BOOL)shouldBeCopied {
    if([[self parent] shouldBeCopied])
        return YES;
    return shouldBeCopied;
}

¿No sería mejor utilizar el valor del niño en primer lugar? Si nada más, es más barato para recuperar (no se requiere mensaje).

El captador modificado sería el siguiente aspecto:

- (BOOL) shouldBeCopied {
     return (shouldBeCopied || [[self parent] shouldBeCopied]);
}

El problema que estoy teniendo es que cuando puedo comprobar el padre, que no actualiza la vista de los niños si ya se expanden.

Hay dos soluciones. Una de ellas es más limpio y funcionará en 10.5 y posteriores. El otro es un poco sucio y funcionará en cualquier versión de Mac OS X.

La solución sucia es tener los padres, desde el método setter, notificaciones MVA postales en nombre de todos sus hijos. Algo así como:

[children performSelector:@selector(willChangeValueForKey:) withObject:@"shouldBeCopied"];
//Actually change the value here.
[children performSelector:@selector(didChangeValueForKey:) withObject:@"shouldBeCopied"];

Este es sucia, ya que tiene uno notificaciones objeto de contabilización MVA sobre una propiedad de otro objeto. Cada objeto sólo debe pretender conocer los valores de sus propiedades; un objeto que afirma conocer los valores de las propiedades de otro objeto corre el riesgo de equivocarse, lo que lleva a mal y / o el comportamiento ineficaz, por no hablar de una propensión para el código para inducir dolor de cabeza.

La solución más limpia es que cada objeto observe esta propiedad de su padre. Pass la opción NSKeyValueObservingOptionPrior cuando se añade a sí mismo como un observador con el fin de obtener una notificación antes del cambio (que podrás responder, en la método de observación , mediante el envío de [self willChangeValueForKey:] ) y una notificación después del cambio (que podrás Respon d a, en el método de observación, mediante el envío de [self didChangeValueForKey:] )

Con la solución limpia, cada objeto sólo envía notificaciones MVA sobre el cambio de su propiedad; ningún objeto es la publicación de notificaciones acerca de las propiedades de otros objetos.

Usted puede verse tentado a tener el mismo niño no enviar estas notificaciones MVA cuando su propio valor de la propiedad es YES, porque en ese caso el valor de la matriz no importa. No debe, sin embargo, ya que esto sólo funcionaría para los niños; Si un descendiente más abajo tiene el conjunto de propiedades a NO, a continuación, que los valores de los antepasados ??de la materia objeto después de todo, y ese objeto no harán más que la notificación si cada uno de sus antepasados ??mensajes a él.

Answer 2

Su colocador no envía -willChangeValueForKey: y -didChangeValueForKey:. Antes y después del cambio, por lo tanto, los cambios no se "notan" por el mecanismo de atascamientos

Además, contando una vista lo directamente de un objeto modelo es ... no es una buena aproximación. En este caso, dado que está utilizando enlaces, su controlador árbol debe tener en cuenta el cambio (cuando haya corregido el colocador para enviar las notificaciones apropiadas) y actualizar la vista de esquema.