Newsgroup: it.comp.lang.delphi
Titolo: Inibire visualizzazione di alcuni dati

Dopo aver realizzato un nutrito pacchetto per un cliente, quest'ultimo
(utonto per esprimerla in termini di Salvati) mi richiede di inibire
alcune informazioni a 2 nuovi utenti a cui pensa di far utilizzare il
programma.
Le informazioni in questione si ritrovano in tedits, tdbedits e in
tdbedits in diverse (parecchie) forms.
Il DB utilizzato è MSSQL.
Qualcuno ha un'idea su come poter ottenere il risultato senza dover
intervenire pesantemente su ogni form e per di più su ogni query
interessata ?
Grazie
Gianni

 intervenire pesantemente su ogni form e per di più su ogni query
hai una gerarchia di form?
A.

> hai una gerarchia di form?
Trattasi di applicazione MDI.
(non scandalizzarti. funziona benissimo)
Gianni

 Trattasi di applicazione MDI.
ehm..nn ho chiesto se 6 in mdi o sdi.
Ripeto: hai una gerarchia di form si o no??
A.

 Ripeto: hai una gerarchia di form si o no??
Scusa, ma dicendo MDI volevo dire che:
c'è una Form principale che contiene un componente actions (+ un menu)
che lancia
le Forms Child le quali a loro volta,  .... si .....,  nelle uses
hanno la Form principale in quanto
condividono con quest'ultima anche degli oggetti stile, toolbar .....
In effetti davo per scontato tutto ciò, ma scontato non era.

allora lo dico semplice... :-(((
i tuoi form ereditano da qlc fatto da TE o da TForm??
A.


Da Tform

 interessata ?
Se il tuo programma e' scritto nel modo "classico", ossia con le 
informazioni recuperate da query e scritte direttamente nei dbedit 
tramite campi persistenti, la vedo difficile.
Se utilizzi classi di business, tipo TFattura, TDocumento, ecc.. allora 
puoi costruirti un sistema di gestione security, al quale demanderai 
compiti quali il chiedere "sono l'utente pippo, dimmi i dati a cui posso 
accedere".
Credo che stai usando il modo classico: a questo livello le informazioni 
possono essere filtrate tramite un metodo per ogni form che, controllato 
l'utente, per tutti i controlli di tipo dbedit, tedit, ecc.. inibisca la 
visualizzazione dei dati.
Se avessi avuto una gerarchia di form come intendeva Alberto, allora 
estendevi il tuo form padre aggiungendo un metodo e poi in tutti i figli 
te lo ritrovavi.
Vedi tu qual'e' la soluzione a minor costo, ovviamente quella di 
modificare tutti i form ciclando sui controlli è la piu' veloce anche se 
  introduce molto codice da manutenere.
-- 
Morde


Ti ringrazio per la risposta. L'applicativo in questione è stato
realizzato quasi 3 anni e, sia in analisi, sia in questi anni,
l'esigenza di cui parlo non è mai emersa. Ormai il software è già
scritto pertanto non posso che adeguarmi alle possibilità esistenti.
Per quanto riguarda tutti i componenti visuali sto già utilizzando la
proprietà 'TAG' ch imposto ad un certo valore per i campi che non
devono essere visibili, ad altro valore per eventuali altre evenienze.
In questo modo con una semplice routine all'attivazione della form
riesco a fissare le impostaziopni per  ogni utente. Il problema è per
le griglie. Non ho trovato ancora una soluzione sbrigativa. .... Ci
sto pensando ..... magari mi viene in soccorso MSSQL.
Grazie ancora per l'interessamento
Gianni

 le griglie. Non ho trovato ancora una soluzione sbrigativa. 
Purtroppo le cose si complicano con le griglie: io a questo punto 
costruirei (se gia' non l'hai fatto) un dizionario che associ al field 
del database la security. Piu' in senso generale, introducendo un 
dizionario, incomincia ad annegare nell'esistente logiche di mapping. 
Immagina di avere un enorme dizionario con tutti i field del tuo 
database: se a questi ci associ una tua classe, TAttributo ad esempio, 
incominci a portarti in una logica di framework. cerca di incominciare 
ad iniettare nel software queste logiche.
Ciao
-- 
Morde


Forse una volta importati i campi della tabella nella unit con il
Fields Editor rinominare il Name di quei campi da inibire con un
prefisso  e poi con una semplice routine settare gli stessi a
visible := false, ciao Brunello

 wrote:

Chiarissimo quello che intendi. E' la strada sulla quale rimugino da
un po'.
probabilmente è la meno dispendiosa o, comunque, quella che mi attira
di +.
(Non che il cliente non voglia pagare, ma voglia da parte mia di
ottimizzare il mio tempo e migliorare il software).
Inizio subito a fare delle prove. Magari in quest'occasione ci
impiegherò un po' ma per il futuro potrà tornarmi molto utile.
Grazie
Gianni


Grazie per l'interessamento.
A questa ipotesi ci avevo già pensato. Il punto è che rinominare i
campi nelle tabelle costringe anche a rinominare gli stessi nel codice
di delphi e nelle query,scripts, trigger.....
... Si tratta di una soluzione ...... che comunque terrò presente.
Grazie ancora
Gianni

 wrote:

Scusami, Brunello. Ti ho risposto poco fa dopo aver letto troppo
velocemente la tua proposta e l'avevo interpretata male.
In effetti la tua soluzione mi sembra 'EGREGIA', ho provato e funziona
perfettamente. Ottimo, grazie.
Mi costringe ad avere tutti campi persistenti..... ma per l'occasione
va bene lo stesso.
Intanto, comunque, farò ugualmente qualche esercizio secondo i
suggerimenti di Morde.

Brunello, la tua soluzione è stata fantastica. In poco tempo ho quasi
ultimato il lavoro.
Ho utilizzato anche per i campi delle query gli stessi valori per il
TAG che avevousato per i componenti tipo TEdit e TDBEdit.
In questo modo, con una routine del tipo:
For I:=0 to ComponentCount -1 do
if Components[i].Tag = 1 then
if Components[i] is TDBEdit then (Components[i] as TDBEdit).Visible :=
False;
if Components[i] is TEdit then (Components[i] as TEdit).Visible :=
False;
etc. etc.
valida per tutte le unit il problema è stato risolto.
con lo stesso stratagemma si può utilizzare con altre proprietà tipo:
Enabled,Color, Font, ReadOnly per scopi diversi o per altre tipologie
di utenti.
Avevo sempre fatto raramente uso dei campi persistenti e per questo,
quando avevo pensato alla soluzione con i TAG non mi era venuta in
mente che anche per i campi di queries e tabelle può essere
utilizzato.
Molto Bene
Gianni