Newsgroup: it.comp.lang.delphi
Titolo: Creare oggetti TShape col costruttore di una classe

Ciao a tutti. 
Per sperimentare un po' con la OOP , ho creato una classe TAbitanti ; da questa derivo due classi TRed e TBlu. Vorrei che quando creo un oggetto di classe Red , usando il suo costruttore, venga creato un oggetto grafico TShape che rappresenterebbe l'oggetto TRed su una mappa. 
Ho dichiarato nella definizione della classe TRed un array di tipoTShape perchè prevedo di avere diversi oggetti TRed : 
ShapeRed: array[1..4] of TShape;
poi con queste istruzioni inserite nel costruttore della classe TRed pensavo di creare  il componente TShape in contemporanea all'oggetto TRed:
  ShapeRed[1] := TShape.Create(self);
  ShapeRed[1].Parent := Self;
  ShapeRed[1].Shape := stEllipse;
  ecc...
ma niente non me lo fa' nemmeno compilare.
In sostanza è possibile creare dinamicamente un oggetto TShape dal costruttore di un'altra classe e disegnarlo direttamente sulla FORM ?
Grazie dell'aiuto
daniele
ma probabilmente sbaglio ad usare "self" perchè

 ma niente non me lo fa' nemmeno compilare.
Dovresti dire che errore ti viene restituito e dove, innanzitutto.
A parte questo, le informazioni sono sufficienti: la classe "TRed" o le 
sue antenate ereditano in qualche modo da "TComponent"? In caso 
negativo, non puoi passarle come parametro al costruttore di TShape, che 
si aspetta di ricevere il componente designato come "owner" del 
controllo. Addirittura tu hai assegnato la proprietà "Parent", quindi 
TRed dovrebbe essere a maggior ragione un controllo visuale per poter 
funzionare (e la cosa ha senso, visto che stai creando un controllo 
visuale e stai definendo il suo contenitore, che deve essere ovviamente 
un controllo visuale).
Dal punto di vista architetturale, comunque, c'è troppa confusione: 
classe base con nome plurale da cui ereditano classi che richiamano un 
aspetto grafico dall'origine sconosciuta che creano al proprio interno 
direttamente gli oggetti necessari alla rappresentazione delle informazioni.
Legare assieme così tante cose eterogenee per tipo e per finalità non 
potrà mai essere buona cosa, anche ammesso che tu riesca a compilare.
In generale (e a maggior ragione con le novità arrivate in Delphi XE2), 
è sempre più importante e fondamentale separare questi tre elementi: il 
modello dei dati, la logica applicativa e l'interfaccia utente.
Ciao,
   Marco.
-- 
Marco Breveglieri
   (
http://www.marco.breveglieri.name
)

 ShapeRed: array[1..4] of TShape;
ma xche tutti hanno sta fissazione per gli array quando le TList e
similari sono decisamente piu' comode? :-|
A.

 similari sono decisamente piu' comode? :-|
...soprattutto da quando ci sono i Generics, e quindi puoi utilizzare direttamente il tipo
  TList<MiaClasse>
senza la necessità di creare "wrapper" o altri intermediari scomodi.


E dura per un semplice hobbista , quando a rispondere alle sue domande sono i GURU della programmazione. Forse da lassu' non avete più , quell'elasticità mentale che si chiama fantasia.... :-))  Allora quest'ultima , visto che in informatica sono una schiappa ce la metto io e vi riformulo la domanda, eliminando l'array e , GENERALIZZANDOLA  :
Ho una classe ANIMALE . Derivo una classe GATTO e una CANE. (prendetele per buone cosi come sono , è solo un esempio) ... Istanzio un oggetto PIPPO di tipo CANE.
Io voglio che quando creo l'oggetto PIPPO  (PIPPO := TCANE.CREATE) , contemporaneamente possa creare (personalizzando il costruttore,presumo) anche un oggetto di tipo TSHAPE , che fungerà da segna posto per PIPPO 
(PIPPO si dovrà anche muovere , con PIPPO.RIGHT(2), PIPPO.UP(3) ECC.)
Quindi la mia domanda è : E' POSSIBILE "DIRE" AL COSTRUTTORE DI PIPPO : "CREA ANCHE" L'OGGETTO DI TIPO TSHAPE  E "PIAZZALO" ALLE COORDINATE X,Y 
(UTILIZZO LEFT E TOP). 
(SALTO LE ISTRUZIONI PER DEFINIRE LE DIMENSIONI O IL TIPO DI SHAPE , ELLISSE,QUADRATO , CERCHIO ECC) ??
CIAO E GRAZIE
DANIELE
PS : 
non ve la prendete per la "FANTASIA" .... (noi schiappe oltre ad avere fantasia abbiamo un senso dell'humour sviluppato :-))
 

 non ve la prendete per la "FANTASIA" .... (noi schiappe oltre ad avere fantasia abbiamo un senso dell'humour sviluppato :-))
Non preoccuparti, non siamo così suscettibili, anzi abbiamo anche noi un buono humour. Il problema è che qui non si capisce dove sia la tua "battuta" che fa così tanto ridere... :D


 (PIPPO si dovrà anche muovere , con PIPPO.RIGHT(2), PIPPO.UP(3) ECC.)
QUESTA COSA E' UN ERRORE.
Dai un occhio al pattern MVC
A.

 (UTILIZZO LEFT E TOP).
Se delphi supportasse l'eredità multipla come in c++ sarebbe possibile 
definire che cane deriva sia da animale che da tshape.
A questo punto, scrivendo pippo := tcane.create(parent,...); tu ottieni 
che pippo è istanza della classe cane ma è anche un tshape.
Un disegno di questo tipo fortunatamente in delphi non si puo' ottenere 
e poi a me non piace perchè l'eredità multipla comporta parecchi 
problemi di gestione delle classi e delle gerarchie.
Un disegno del software come lo intendi tu potrebbe essere possibile 
creandoti due diverse gerarchie di classi: una discendenza di classe 
animale->cane e una discendenza di oggetti grafici tshape->shape_cane. 
Un oggetto di tipo cane ha un riferimento interno ad un'istanza di tipo 
tshape. In qeusto modo tieni separate le gerarchie di classi e mantieni 
i collegamenti attraverso il riferimento. In UML questo tipo di 
relazione di esprime con un class diagram e un'associazione che collega 
le due classi tcane e tshape.
Quando vai a costruire l'istanza di cane, nel costruttore implementi una 
tcane_shape.create e te la gestisci come ti pare. ricordati di 
distruggerla quando sei nel distruttore di cane.
-- 
morde
QT 4.7
Delphi (5,6,7.. expired)
Firebird Database

 Dai un occhio al pattern MVC
Ciao Alberto sono pienamente d'accordo con te, tuttavia devi anche 
considerare che l'OP ha dichiarato che si sta esercitando sugli oggetti 
come hobbista..Per questo motivo, consigliare di andare a guardare il 
pattern MVC è sì formalmente corretto, ma credo possa sortire l'effetto 
opposto, cioè quello di allontanarlo dallo sperimentare e dall'imparare, 
divertendosi, i fondamenti dell'OOP.
Io gli ho suggerito una soluzione che non è correttissima dal punto di 
vista formale, ma se messa in pratica dovrebbe metterlo in grado di 
realizzare un prototipo che funzioni senza troppo perdersi nella teoria 
dei design patterns e dell'MVC.
Mi permetto di suggerire all'OP questo tutorial:
http://delphi.about.com/library/bluc/text/uc052102a.htm
molto basic, e dovrebbe metterelo in grado di produrre qualcosa di 
funzionante in tempi brevi.
Se poi, evolvendo il prototipo, l'OP arriverà a separare la creazione 
degli oggetti cane, gatto, da quella dei loro rappresentanti grafici 
tshape discendenti, si sarà avvicinato all'MVC senza neanche saperlo.
Immagino per esempio che al click di un bottone si farà la create degli 
animali, li metterà in una lista, e passerà quest'ultima ad un form che 
disegna le shape in relazione agli animali contenuti nella lista. E così 
via..


 divertendosi, i fondamenti dell'OOP.
Questo e' vero.
Per contro, sono convinto che iniziare male e correggersi in seguito
sia molto piu' complesso che iniziare bene.
A.

 sia molto piu' complesso che iniziare bene.
Effettivamente, io sono uno di quelli che ha fatto cosě.. :-D
Ho imparato sbagliando e devo dire che mi č costato molta molta fatica.. 
(tuttavia, si puň sempre rimediare dopo: libri, scuole, internet, 
colleghi di lavoro, gruppi di discussione, ICLD..  ;-))
Ma vuoi mettere la soddisfazione di vedere le tue prime classi che ti 
danno l'esatto output che ti aspetti, gratificandoti della sensazione di 
aver capito esattamente come si fanno le cose?
Mettiamolo in condizione di *fare*.
Ciao ;)


Grazie a morde per i suggerimenti , direi centrati per il mio livello .... non mi sento di ringraziare Alberto Salvati  , per il semplice motivo che "non è stato utile" alla discussione , anzi direi che forse era infastidito nel rispondere.  
PS . tra me e me mi viene da dire "..ma che rispondi a fare se non hai pazienza.." :-).
Perdonate le spiritosaggini sui guru ma era solo per ridere un po'.
Questo è un po' OT , ...il mio lavoro e' condurre treni , sono un macchinista... il nostro lavoro sino poco tempo fa si imparava come insegnamento diretto del collega con cui venivi messo in turno .... per fortuna c'e' sempre stata tanta pazienza e soprattutto tanta modestia .... altrimenti sai quanti incidenti se l'allievo non capiva ciò che doveva fare :-))
ciao e grazie comunque
daniele

tcane_shape.create e te la gestisci come ti pare
 
---------------------------------COSTRUTTORE CLASSE CANE
constructor TCane.Create();
begin
   inherited Create; //costruttore classe ANIMALE
   ShapeDog := TShapeCane.Create(self); //ERRORE 1
   ShapeDog.Parent := self;             //ERRORE 2
end;
 
il compilatore mi dà questo errore sulla prima riga :
 
"Incompatible types: TComponent and TCane"
 
e questo sulla seconda :
 
"Incompatible types: TWinControl and TCane"
 
Allora , so' che la proprietà .Parent dice al componente dove deve essere visualizzato , .... io lo voglio sulla Form , ma come faccio?
 
Il primo errore , scompare se al posto di 'self' uso 'nil'.... ha a che fare col fatto che essendo un componente ha bisogno di un owner ? Con nil la distruzione deve avvenire , poi in modo manuale?
 
Grazie della vs pazienza
 
ciao
daniele
 

 Il primo errore , scompare se al posto di 'self' uso 'nil'.... ha a che fare col fatto che essendo un componente ha bisogno di un owner ? Con nil la distruzione deve avvenire , poi in modo manuale?
Non ricordo la firma del costruttore, cioè non ricordo quando passi il 
parent e quando l'owner. Quando costruisci il tcane, devi passargli NIL 
come parent, poi devi recuperare l'handle del grafico e settarlo come 
parent al tshape.
 
Per il resto credo che sia corretto.
Manca il codice della classe tanimale dalla quale discende tcane, se hai 
quell'errore sicuramente non è un tcontrol discendente. (ed è giusto che 
non lo sia. lo scopo è di disaccoppiare i dati di business dalla loro 
rappresentazione grafica.
 
Continua a sviluppare e posta tutto il codice qui sopra.


 Il primo errore , scompare se al posto di 'self' uso 'nil'.... ha a che fare col fatto che essendo un componente ha bisogno di un owner ? Con nil la distruzione deve avvenire , poi in modo manuale?
 
Tutto questo avviene perché non hai seguito i suggerimenti di Alberto, 
che hai tanto bistrattato.
 
Gli errori che riscontri sono facilmente risolvibili passando i 
parametri che vengono richiesti: se vuoi che il "Parent" del tuo 
controllo "Shape" sia la Form, dovrai passare il riferimento al Form... 
ovvio che se passi invece il riferimento all'oggetto "TCane", questo non 
può funzionare, e la condizione si evince leggendo il tuo stesso messaggio.
 
La tua architettura, così come è fatta, implica che dovrai passare al 
costruttore di TCane, che è un oggetto contenente solamente logica, un 
riferimento al Form in cui vuoi inserire il controllo grafico (quindi 
un'entità del tutto diversa dalla classe che lo contiene), realizzando 
un miscuglio logica/grafica mai visto e del tutto ingestibile, destinato 
a peggiorare man mano che vai avanti.
 
Per quanto si cerchi con tutta la buona volontà di aiutarti a 
raggiungere lo scopo, non potrai mai ottenere suggerimenti o consigli 
"giusti" in senso assoluto e tecnico se riferiti al far funzionare 
un'architettura che, così come è progettata, è sbagliata per i più 
svariati motivi, dalla commistione inutile e problematica di logica e 
grafica all'elevato accoppiamento di classi che svolgono compiti diversi 
(studiati il concetto di SRP, Single Responsibility Principle, 
http://en.wikipedia.org/wiki/Single_responsibility_principle
).
 
Se a tutto questo unisci anche la necessità di approfondire i principi 
fondamentali del linguaggio (ad esempio, i concetti di "ownership" e 
"parentship" e le politiche di gestione della memoria in Delphi), la 
confusione aumenta a dismisura.
 
Dal mio punto di vista, ti conviene fare un passo indietro, documentarti 
sugli elementi che ti sono stati indicati sopra, rivedere la tua 
architettura (e in questo caso ben disponibile a fornire tutti i 
chiarimenti necessari, ovviamente dal mio punto di vista) e scrivere 
codice che non sia uno stupro alla OOP. :)


 codice che non sia uno stupro alla OOP. :)
 
Hai perfettamente ragione e penso che seguirò il tuo consiglio , ma parallelamente volevo riuscire a risolvere il mio quesito anche senza logiche imposte ,... "a modo mio". Ora posto il mio codice , e ad essere sincero tutto questo stupro non mi sembra. 
 
Ho una classe ANIMALE da cui di scende una classe CANE ; poi dalla classe SHAPE derivo una classe SHAPEDOG. Nella classe CANE c'è un riferimento a SHAPEDOG : quando nasce il cane (oggetto) nasce anche il suo simbolo grafico che lo rappresenta sullo schermo ; quando il cane muore , sparisce il suo simbolo grafico dallo schermo! .... a me sembra semplice?
 
****************************************************************************
unit Cane;
 
interface
  uses Animale, ShapeCane, Dialogs , ExtCtrls , Graphics ;
 
type
  TCane = class(TAnimale)
  private
   {PRIVATE}
  public
    ShapeDog: TShapeCane;
    constructor Create ; overload;
    destructor  Destroy; override;
end;
 
implementation
  uses Zoo; //Indicare la unit nelle uses dell'implementation
            //risolve il problema dei riferimenti incrociati
 
 
constructor TCane.Create();
begin
   inherited Create;
   ShapeDog := TShapeCane.Create(nil);    //owner
   ShapeDog.Parent := Cortile;            //parent .... Cortile è il form
    //MODELLO IL CANE
   ShapeDog.Shape := stEllipse;
   ShapeDog.Brush.Color := clBlue;
   ShapeDog.Width := 50;
   ShapeDog.Height := 50;
   ShapeDog.Left := 50;
   ShapeDog.Top := 50;
 
   ShowMessage('Sono il costruttore dei cani!!');
end;
 
 
destructor TCane.Destroy;
begin
   ShowMessage('Sono il distruttore dei cani!!');
   ShapeDog.Free;
   inherited Destroy;
end;
 
end.
 
*****************************************************************************
unit ShapeCane;
 
interface
   uses ExtCtrls, Graphics;
 
type
  TShapeCane = class(TShape)
end;
 
implementation
 
end.
 
****************************************************************************
unit Animale;
 
interface
  uses StdCtrls, Dialogs;
 
type
   TAnimale = class
   Nome: string;
end;
 
implementation
 
uses Zoo;
 
end.
 
*******************************************************************************
 
unit Zoo;
 
interface
  uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, Animali, Cane, ShapeCane, StdCtrls, ExtCtrls;
 
type
  TCortile = class(TForm)
    Button2: TButton;
    Button3: TButton;
    procedure Button2Click(Sender: TObject);
    procedure Button3Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;
 
var
  Cortile  : TCortile;
  Bassotto : TCane;
 
implementation
 
{$R *.dfm}
 
 
procedure TCortile.Button2Click(Sender: TObject);
begin
 if Assigned(Bassotto) then
  begin
    Bassotto.free;
    Bassotto := nil;
    ShowMessage('Oggetto distrutto');
  end
 else
    ShowMessage('Devi prima creare l''oggetto');
end;
 
procedure TCortile.Button3Click(Sender: TObject);
begin
 if not Assigned(Bassotto) then
  begin
   {Oggetto BASSOTTO}
    Bassotto := TCane.Create;
  end;
end;
end.
 
 
Mi spiace se avete preso le mie uscite per scortesi , non era mia intenzione ; il mio scopo è studiare un ambiente dove gli abitanti devono rispondere ad alcune regole che impongo al loro comportamento , e poter osservare le interazioni che nascono fra loro (una specie di GAME'S LIFE). Ho pensato di usare Delphi e quindi ho cominciato a armeggiare col compilatore.... capisci bene che se per arrivare a un qualche risultato devo leggermi il pattern MVC , il concetto di SRP ecc. allora la cosa diventa un lavoro , non piu' un hobby!.
 
La soluzione che ho ottenuta , in una certa misura mi è stata suggerita da morde in un suo intervento , e .... funziona! 
Il problema che si presenterà , se continuassi con questa architettura sarà sicuramente il dover creare e gestire più istanze del cane e di shapecane !
 
Bè vedro' , io cercherò di colmare le mie lacune , ma se il codice mi funziona, anche se cozza con tutti i concetti sopraesposti , me lo tengo cosi' comè....
 
grazie Marco
 
ciao
  daniele
 
 

 Bè vedro' , io cercherò di colmare le mie lacune , ma se il codice mi funziona, anche se cozza con tutti i concetti sopraesposti , me lo tengo cosi' comè....
Gurda, il tuo approccio mi piace: continua per la tua strada!
 
La curiosità di sapere come funzionano le cose e di provare è sempre 
stata quella cosa che ha fatto progredire la conoscenza. La curiosità mi 
ha sostenuto quando ho iniziato a fare il programmatore senza essere 
diplomato. Ha continuato a sostenermi quando ho studiato i design 
pattern senza essere laureato. E continerà a farlo: quando una cosa mi 
incuriosisce, la studio. Cerco di spingermi fino a dove possono portarmi 
le mie capacità. Mi piace imparare, e applicare poi le conoscenze 
acquisite per migliorarmi.
 
Per chiudere, esco dal discorso: se conosci un pò l'inglese leggi questo 
post, a me ha fatto riflettere molto.
http://matt.might.net/articles/phd-school-in-pictures/
 
 
PS: nella scala dei titoli di studio il phd
http://en.wikipedia.org/wiki/Doctor_of_Philosophy
 
è i massimo titolo di studio accademico che uno arriva a prendere e 
significa che ha compiuto anni e anni di approfondimento su una materia 
dove ha preso il dottorato.


 i concetti sopraesposti , me lo tengo cosi' comè....
 
Come ho già detto, se il tuo interesse è che il programma funzioni, il codice che hai scritto è già inutilmente complicato: a cosa ti serve programmare a oggetti se non lo fai come si deve? Se ti interessa un risultato approssimativo, allora non è nemmeno necessario. Se l'obiettivo è continuare a manutenere ed espandere il progetto, motivo per cui hai scelto di utilizzare la programmazione a oggetti, allora questa va usata come si deve, altrimenti avrai solo problemi.
 
Il fatto che si ritenga una soluzione valida solo perché funziona ora, per me, è un ragionamento assurdo, che avrebbe senso se la teoria fosse nuova e mai discussa, ma su alcune tematiche ormai si discute da decenni (motivo per cui sono nati, ad esempio, i "design pattern" e altri strumenti analoghi.


 stata quella cosa che ha fatto progredire la conoscenza.
 
La conoscenza progredisce anche perché quando qualcuno scopre qualcosa, gli altri non devono fare gli stessi errori ma possono allinearsi al suo punto di partenza per andare oltre.
 
Ripetere gli stessi errori non fa progredire la conoscenza, fa rimanere al palo.
 
Se parlassimo di cose nate oggi, allora è un conto, ma qui si parla di cose assodate, conosciute, provate, ben documentate e ampiamente condivise.


 Se parlassimo di cose nate oggi, allora è un conto, ma qui si parla di cose assodate, conosciute, provate, ben documentate e ampiamente condivise.
 
Guardiamo la realtà da un punto di vista un pò più concreto senza 
restare nelle nostre argomentazioni sul disegno del software: l'OP per 
lavoro conduce treni, e per diletto sta cercando di imparare a 
programmare ad oggetti, rappresentandoli anche graficamente.
 
Ha fatto un qualcosa che non sarà lo stato dell'arte dei design pattern 
ma gli dà modo di capire, di correggersi, di migliorarsi. E questo, per 
me, è stato sufficiente: ora lui sa dove può trovare materiale da 
leggere e studiare per poter scrivere qualcosa di più organico, 
coerente, maturo, grazie anche ai nostri consigli.
 
PS: io potrei anche avergli suggerito un'architettura sbagliata, ma solo 
per il fatto che questo non sia nei libri di design pattern non 
significa che non possa funzionare ed essere studiato per migliorarlo 
oppure riscriverlo con un'altra vision più erudita.


 coerente, maturo, grazie anche ai nostri consigli.
 
Io e Alberto gli abbiamo suggerito determinate cose per indirizzarlo su come scrivere da subito qualcosa di fatto un po' meglio, e i consigli sono stati presi abbastanza male dall'utente.
 
Bisogna tenere conto anche del fatto che, banalmente, se qualcuno mi chiede una cosa, io non posso sapere fino a che punto arrivano le conoscenze di chi mi interroga prevedendole in anticipo; in ogni caso, una volta capito il livello, tutt'al più posso spiegare una cosa in un modo più semplice, o esemplificare, o dire dove cercare.
 
Continuo a non rimanere d'accordo sul fatto che io debba dare un suggerimento che ritengo personalmente sbagliato valutando le mansioni e la voglia di studiare di chi pone la domanda: se è interessato approfondirà, altrimenti farà come crede, ma questo è implicito.


Questo è il mio ultimo intervento , dopo di che per quanto mi riguarda il thread è chiuso. Mi sembra che in questo NG la maggior parte di risposte a chi chiede la diano sempre i soliti .... e questo è encomiabile , perchè , voi con la programmazione , credo , ci mangiate , quindi usate il vs tempo libero... Ho notato però che diversi utenti si sono trovati a discutere , con i "soliti di cui sopra" , non tanto in merito a cio' che chiedevano , ma a "come" ponevano le domande!!
Un esempio?....
https://groups.google.com/forum/#!topic/it.comp.lang.delphi/fNYGxQNHE5U
 
(qui il povero Cooper addirittura viene accusato di essere un Troll,in modo del tutto gratuito ,solo perchè era incerto nelle domande e nelle risposte!!)
 
Avrei voluto , e morde è l'unico che l'ha fatto , sentirmi dare uno o più suggerimenti   , su "come" fare la cosa che chiedevo e comunque avrei accettato i consigli sulla mia scarsa preparazione e dove potermi correggere , magari con link a libri , siti, dispense ecc. Qui invece  , a parte morde , c'è stato solo una specie di "nonnismo informatico" ..... "vuoi le informazioni?" "...allora devi stare col capo chino , orecchie aperte, ad ascoltare la lezione!!"...... 
 
Ho sempre valutato la vita con una scaletta : prima l'istinto , poi la sperimentazione , e poi la cultura rigidamente applicata .... Questa valutazione , scusate il termine, mi ha salvato il culo , diverse volte sia a 200 all'ora con gli intercity che  con treni merci carichi di benzina! Checchè ne dica il mio istruttore dopo 25 anni che guido i treni la teoria , le rigide procedure da seguire, le regole alla fine devono essere filtrate dal mio cervello ..... e l'unico scopo rimane portare la pelle a casa!! 
 
Capisco , che il massimo che puo' accadere programmando è che il compilatore non compili, (non prendetela come una critica , ad ognuno il suo), ... è solo una considerazione ma mi serve per farvi capire il motivo per cui a volte alcune persone , come  me, vogliono seguire in modo testardo un'idea , un modo diverso di fare una cosa, e che i dogmi vengano visti come catene.... daltronde se i ricercatori del Cern avessere preso come un assunto le teorie di Einstein , non avrebbero "sperimentato" con i neutrini, o no?
 
Quindi , ripeto, io sono disponibile ad accettare consigli , nella misura in cui questi mi vengano dati in modo non ostile e propositivo , per me, ma anche per gli altri che ci leggono. 
Quindi per il futuro se io porrò una domanda in questo NG , sarò un umile allievo desideroso di imparare , ma pretendo che , se uno dei soliti noti risponde, mi si usi la stessa cortesia , altrimenti si astenga , cosi' da non riproporre questi flame , che non sono per niente utili alla comunità!
 
Un consiglio , ...rileggetevi questo thread e il link che vi ho postato , a me pare che a furia di dare consigli , qualcuno , abbia esaurito la tolleranza , o forse ha ragione Einstein :-)).......
 
 
"Non hai veramente capito qualcosa fino a quando non sei in grado di spiegarlo a tua nonna."
Albert Einstein
 
 
Ciao a tutti .
 
PS 
per morde:  
  La guida per Ph.D , l'ho trovata veramente illuminante, ... grazie!
 

 la tolleranza , o forse ha ragione Einstein :-)).......
 
Non rileggerò questo thread, e nemmeno i successivi, visto che non c'è "compatibilità".
 
Di tolleranza ne ho da vendere, anzi da regalare, ma la dedico poi a chi penso se la meriti.
 
Per quanto mi riguarda, la questione è chiusa.
