TW e quantità di oggetti bloccati

[poidomani]

in ufficio da me cominciamo ad essere in molti a lavorare sugli stessi progetti quindi una logica per cui modificando una procedura di un Form mi si blocca l'intero Form comincia a starci stretta, bisognerebbe bloccare solo lo stretto indispensabile.

[a.maioli]

Quando modifichi il codice di un metodo di form viene bloccato solo il metodo e non la form. Quando invece modifichi l'aspetto visuale (ad es sposti un campo) viene bloccata la form perchè non ha senso che un'altra persona modifichi il layout visuale insieme con te.

[poidomani]

concordo su quello che hai scritto, quindi ero male informato sul funzionamento, farò qualche prova,
grazie

[C.Zecca]

Quando si modifica l'aspetto visuale di una videata viene eseguito un lock di contenuto su tutta la maschera.
Questo introduce una non facilmente riconoscibile dipendenza temporale nelle azioni che può fungere da trappola per lo sviluppatore e portare a check-in e relativi stati di versionamento impropri.

In questo caso (modificare con sequenza (casuale) prima l'aspetto della videata e poi il codice ad essa relativo) aggiungendo o modificando un metodo (procedura o funzione) NON è possibile eseguirne il check-in singolo come invece, se ricordo bene, è possibile fare modificando o aggiungendo prima il metodo e POI modificando l'aspetto visuale della videata.

TW mi ha appena fregato nel senso che in una videata in check-out da qualche giorno e che è che è stata anche modificata nell'aspetto ho aggiunto un metodo ImpostaTooltip() del quale volevo eseguire bottom-up il check-in di una prima versione prima di altre modifiche sostanziose ad essa.
Mi ero preparato il commento specifico e
ImpostaTooltip() appariva come elemento in check-out nella lista prodotta da Team Works - Mostra Lock

Questo mi ha tratto in inganno in quanto al momento di eseguirne il check-in mi ha eseguito il check-in di tutta la videata (peraltro in uno stato incongruente) perché essa era stata casualmente modificata prima.

Proposte:
o - in caso di modifica degli attribuiti di aspetto restringere il lock ad essi ovvero separare nettamente gli elementi per l'aspetto dal codice e relativi lock
o - richiedere conferma del check-in per elementi che appaiono nella lista dei lock quando essi sono comparsi in un lock di contenuto in un entità più ampia avvisando che proseguendo verrebbero check-inati anche gli elementi di questa
o - ingrigire gli elementi in lock che non possono essere checkinati autonomamente in quanto contenuti in lock di contenuto e inibire il check-in su di essi

[a.maioli]

In realtà Team Works quando fa check-in di un metodo non fa check-in della videata che lo contiene. Probabilmente il metodo conteneva un riferimento ad un oggetto visuale che il server non conosceva, per cui senza fare check-in della videata non avrebbe potuto fare check-in del metodo.

[C.Zecca]

In realtà non è così semplice seguire sempre a mente gli algoritmi di TW.
Il grafo delle dipendenze potrebbe non essere quello che appare.
Faccio un' esempio che mi è appena capitato:
Videata GestioneComponenti, cambiata query di pannello master, passati da una tabella ad una vista non aggiornabile.
Rotti gli automatismi In.De mi preparo il metodo InsertUbCo() per gestire l'insert di un tab "detail".
Versione id prova, ho ancora una MessageBox di "sviluppo" del tutto estemporanea in BeforeInsert().

In effetti è vero, la InsertUbCo() utilizza alcuni dati del pannello principale ma... sul momento il ragionamento è stato:
siamo alla foglia delle dipendenze (ed in effetti ciò non era vero) faccio il check-in della prima versione e poi passo a finire di integrarla e quindi al check-in del resto.

Il (primo) check-in di InsertUbCo() mi ha eseguito il check-in di tutta la videata.
Ora, se io fossi stato avvisato con un messaggio tipo: Vuoi continuare? Questa operazione comporta il check-in di altri elementi? <SI> <No> avrei potuto evitare di proseguire con un check-in in cui InsertUbCo() è(ra) corretta, pulita e finita, ma non il resto che la usava/contiene.