2013-01-04 17 views
6

Mam NSTableView oparty na widoku z NSTableCellView w widoku tabeli konfiguracji graficznie za pomocą konstruktora interfejsów w najnowszej wersji Xcode na 10.8.2.Niezadowalające ograniczenia z NSTableView podczas wywoływania reloadData

Kiedy zadzwonić -reloadData na NSTableView, to wywala z:

Unable to simultaneously satisfy constraints: 
(
    "<NSAutoresizingMaskLayoutConstraint:0x105cb8bf0 h=--& v=--& V:[NSTableRowView:0x105ca7020(0)]>", 
    "<NSAutoresizingMaskLayoutConstraint:0x10596aa30 h=--& v=-&- V:[GroupTableRowView]-(2)-| (Names: GroupTableRowView:0x100185860, '|':NSTableRowView:0x105ca7020)>", 
    "<NSAutoresizingMaskLayoutConstraint:0x1058d9770 h=--& v=-&- V:|-(1)-[GroupTableRowView] (Names: GroupTableRowView:0x100185860, '|':NSTableRowView:0x105ca7020)>" 
) 

Will attempt to recover by breaking constraint 
<NSAutoresizingMaskLayoutConstraint:0x10596aa30 h=--& v=-&- V:[GroupTableRowView]-(2)-| (Names: GroupTableRowView:0x100185860, '|':NSTableRowView:0x105ca7020)> 

nie mogę wyłączyć auto-rozmiaru tłumaczenie maski na dowolny z widokiem zaangażowanych jako swoich ograniczeń są zarządzane przez NSTableView. Jest oczywiste, że ograniczenia są w konflikcie, ponieważ NSTableRowView nie może mieć 0 wysokości, a jednocześnie spełnia pozostałe dwa ograniczenia w GroupTableRowView, które określają obowiązkowe dopełnienie między superview (widok wiersza?). Nie jestem pewien, jak rozwiązać ten problem, wszelkie spostrzeżenia będą mile widziane. Dzięki!

Aktualizacja: Znalazłem obejście. Problem polega na tym, że z jakiegoś powodu NSTableRowView był wysyłany o rozmiarze ramki {0, 0} podczas wywoływania -reloadData w widoku tabeli. Przeanalizowałem -setFrameSize: w podklasie NSTableRowView i przekazuję komunikat tylko do łańcucha responderów, gdy rozmiar nie jest {0,0}.

- (void)setFrameSize:(NSSize)newSize 
{ 
    if (!NSEqualSizes(newSize, NSZeroSize)) 
     [super setFrameSize:newSize]; 
} 

Aby użyć podklasy realizacji -tableView:rowViewForRow: sposób NSTableViewDelegate do powrotu wystąpienie niestandardowego podklasy.

- (NSTableRowView *)tableView:(NSTableView *)tableView rowViewForRow:(NSInteger)row 
{ 
    id rowView = [[GroupTableRowView alloc] init]; 
    // configure any custom properties 
    return rowView; 
} 

Jeśli widok tabeli jest zaprojektowany w całości w IB, można po prostu przeciągnij nowy NSView do widoku tabeli i ustaw jego własnej klasy do podklasy NSTableRowView i zmienić jego interfejs użytkownika Element Identifier do NSTableViewRowViewKey

+0

Bump. Wystąpił podobny problem podczas korzystania z widoków tabel opartych na widoku. Czy zrobiłeś postęp w swoim problemie? –

+0

Zaktualizowałem moje pytanie z obejściem. Nadal szukam, dlaczego NSTableCellView jest wysyłany '{0,0}', ale nie mogę tego odtworzyć w aplikacji demonstracyjnej do przesłania z raportem o błędzie do Apple. – Andrew

+0

@Andrew Myślę, że to jest rzeczywiście rozwiązanie, dzięki za to! – NSAddict

Odpowiedz

1

Miałem ten sam problem i to zawsze doprowadzało mnie do szału ..

Rozwiązałem go, używając Twojego kodu, ale pod podklasowaniem NSTableRowView. Aby automatycznie pozwolić tabeli korzystać z niestandardowego widoku wiersza, dodaj niestandardowy NSView do swojej tabeli. Ustaw klasę na niestandardowy widok wiersza i ważny identyfikator na NSTableViewRowViewKey.

Za pomocą tego specjalnego identyfikatora tabela automatycznie używa go jako widoku wiersza.

+0

Masz rację, wróciłem i spojrzałem na mój kod i faktycznie podklasowałem NSTableRowView. Dzięki! – Andrew

1

Miałem podobny problem, ale o szerokości kolumny zamiast wysokości wiersza. Niespełnione ograniczenia związane z autouzupełnianiem pojawiały się na komórkach opartych na widoku NSTableView s natychmiast po wywołaniu reloadData. W moim przypadku było to spowodowane tym, że ustawienie minimalnej szerokości na NSTableColumn było zbyt małe, aby zawierało minimalną szerokość dla więzów w komórce. Tak więc dla każdego, kto ma podobny problem, najpierw to sprawdzę.

"Ciekawą" częścią było to, że był to problem tylko dla reloadData, a nie dla normalnego układu, ponieważ istniały ograniczenia na szerokości NSTableView, które uniemożliwiały normalne próby utworzenia tak małej komórki. Ale gdy wywołano reloadData, najwidoczniej najpierw utworzy nową komórkę z ustawionym rozmiarem ramki na minimalną szerokość kolumny, przed późniejszym zmieniem rozmiaru kolumny tak, aby pasowała poprawnie (jeśli masz ustawioną tabelę). Mimo że wszystko wydawało się działać poprawnie, nadal wypisywano by błąd związany z niespełnionymi ograniczeniami zaraz po wywołaniu reloadData, ponieważ początkowa szerokość widoku komórki była zbyt mała dla wypełnienia itp.

Morał z tej historii jest to, aby zawsze sprawdzić, czy minimumNSTableColumn szerokość jest wystarczająco duży dla ograniczeń w komórce, nawet jeśli nie sądzę kolumna nigdy nie będzie, że małe. IB ułatwia majstrowanie przy ograniczeniach i łatwo zapomnieć o ponownym sprawdzeniu opcji szerokości kolumny po zmianie elementu w komórkach.

+0

Wielkie dzięki! To zaoszczędziło mi godzin bolesnego debugowania. –

Powiązane problemy