Newsgroup: it.comp.lang.delphi
Titolo: Evitare uso dei Timer

ho un Form MDI + vario Child , ed un Frame esterno che contiene
vari SpeedButton
il Frame viene istanziato a runTime su un Panel di ciscun Child
  BarraPulsanti:=Tfrm_ToolBar.Create(Self);
  with BarraPulsanti do
  begin
   Parent:=Panel3;
   Align:=alClient;
   Show;
  end;
il problema e' quando clicco su uno SpeedButton , come faccio a ritornare
il valore al form Child.
ogni FormChild usa il Frame con i Pulsanti, quindi non  e' possibile dal 
Frame
chiamare il Child
--> Form MDI
  ---> Child 1
   -- uses frm_ToolBar
  ---> Child 2
   -- uses frm_ToolBar
--> Frame
si puo' evitare l'uso di un Timer su ogni Child che legga il valore di una
Function pubblica nel Frame.
con il Timer sul Child potrebbe essere cosi'
procedure Tfrm_Preventivi.Timer1Timer(Sender: TObject);
begin
  VerificaPulsanteToolBar;
end;
// legge il valore dal modulo Frame
procedure Tfrm_Preventivi.VerificaPulsanteToolBar;
var sPulsanteToolBar:String;
begin
  sPulsanteToolBar:=BarraPulsanti.PulsantePremuto;
  if sPulsanteToolBar<>'' then bFlgPulsanteToolBar:=True;
  if bFlgPulsanteToolBar then
  begin
   bFlgPulsanteToolBar:=False;
   if sPulsanteToolBar='Successivo'  then
   begin
     sPulsanteToolBar:='asda';
   end;
  end;
end;
// Parte sul Frame
// accetta lo SpeedButton cliccato
procedure Tfrm_ToolBar.AzioneToolBar(var Pulsante:String);
begin
  PulsanteCliccato:=Pulsante;
end;
// ritorna il valore attribuito
function Tfrm_ToolBar.PulsantePremuto:String;
begin
  Result:=PulsanteCliccato;
  PulsanteCliccato:='';
end;
grazie Maurizio 

1) il with peggiora la leggibilita del codice.
Ergo, abituati gia da esso a fare finta che non esiste.
2) xche incasinarsi cosi e non usare una toolbar gia bella e pronta?
1) crea un form che urerai come ancestor degli altri
3) metti un TActionList e ci schiaffi dentro una tAction per ogni 
pulsante.
Ogni TAction, nella sua execute chiama un metodo (ovviamente virtual..):
procedure TRootForm.ActionSomethingExecute(sender: tobject);
begin
   __DoSomeThing(sender);
end;
3) metti il codice che serve per attivare o disattivare il frame
4) usi questo form come ancestor per gli altri.
A quel putno oin ogni discendente ti basta dare l'override dei metodi 
virtuali usati dalle TAction.
Se poi leggi bene cio che fanno i form probabilmente riesci a spostare 
molto nel form genitore, evitando la ridondanza di codice.
Questa si chiama OOP...
A.


Io non sono cosi' assolutista a riguardo. Il _with_ e'
come il vino: il suo uso moderato e consapevole non provoca
danni ma, anzi, puo' avere qualche effetto positivo.
Io trovo piu' leggibile questo codice:
 // inizializzo il form principale
 with FormPrincipale do
  begin
    Caption := 'Prova';
    Color := clAqua;
    Width := 250;
    BorderIcons := BorderIcons - [biMinimize];
  end; // fine with
rispetto al corrispondente codice senza il "with". Oppure:
  with FSecurityAttributes do
    begin
      nLength := SizeOf(FSecurityAttributes);
      lpSecurityDescriptor := SecurityDescriptor;
      bInheritHandle := Inheritable;
    end;
O ancora:
procedure TForm1.SomeCheckboxClick(Sender: TObject);
 begin
    with Sender as TCheckBox do
      Checked := not Checked;
 end;
Anche l'uso di _with_ annidiati, se ben gestito, non dovrebbe
dare problemi di comprensione
  with Sender as TButton do
    case Tag of
     0 :
       begin
         Tag := 1;
         with mp := TMediaPlayer.CreateParented(Handle) do
           DeviceType := dtSequencer;
           FileName := 'c:\winnt\media\Canyon.mid';
           Wait:= True;
           Open;
           Play;
         end;  // fine utilizzo mp
       end;
     1 :
       begin
         Tag := 0;
         // ecc...
       end;
    end;
Certo, l'abuso e il mal utilizzo del _with_ possono di certo provocare
l'illegibilita' e la difficile manutenzione del codice, ma non
sono d'accordo nello sconsigliarne l'uso - e inoltre risparmi un bel po' di
digitazione, rendendo piu' lunga la vita della tua tastiera ;-)
Ciao
ACSH
(presidente del comitato per un utilizzo consapevole del
tanto vituperato WITH) 

 digitazione, rendendo piu' lunga la vita della tua tastiera ;-)
imho, una tastiera costa non + di 15 euro. ;-P
Una giornata di debug, forse, costa un po di +. :-)))
E poi, sono nel settore IT dal 1990 e gli unici casi che ho visto di 
tastiera gettata via erano:
1) pin piegati nel connettore
L'utOntO aveva tutti i neuroni in posizione off, e questo gli ha 
impedito di considerare che FORSE il connettore ps/2 ha un verso...
2) Caduta di bevanda gassata tossica e corrosiva (indovina quale...)
A
(Presidente dell'ANANAS)

 2) Caduta di bevanda gassata tossica e corrosiva (indovina quale...)
L'acqua di alcuni fiumi vicino a Cernobyl puo' quasi
arrivare a quei livelli di tossicita', ma sicuramente ha meno
controindicazioni!
Ciao
ACSH
(presidente dell'organizzazione nazionale contro gli
acronimi che non capisco)

 controindicazioni!
quoto. meglio birra, vino, sopratutto la vodka... ;-P
ANANAS
Associazione Nazionale Astronauti Non Attrezzati Sufficientemente
A.

> virtuali usati dalle TAction.
// dal Form principale
procedure AzioniToolBar.PrecedenteExecute(Sender: TObject);
var sPulsante:String;
begin
  inherited;
  sPulsante:='----';
end;
resta il fatto che l'Azione viene eseguita sul Frame ToolBar, quando clicco
sul puilsante esegue l'evento , ma non ha possibilta' di tornare al metodo
non a caso il compilatore ignora la procedure 
AzioniToolBar.PrecedenteExecute
che il Form principale non puo' chiamare.
la tua idea e' sicuramente valida , ma prova a concretizzare 
schematicamente.
ciao Maurizio 

 danni ma, anzi, puo' avere qualche effetto positivo.
I programmatori sono persone che non fanno un uso moderato e consapevole
di alcunché, anzi tendono spesso e volentieri ad abusare.  Il with è un
costrutto _MOLTO_ error prone e che può portare a bug e mal di testa anche
se non se ne abusa, ma si cambia solo una virgola nel codice.  In molti
ambiti della programmazione si è imparato a fare a meno di quei costrutti
che possono portare facilmente a sbagliare (non è un caso che il "with"
non sia presente in molti linguaggi), vedi il costrutto ?: di Java/C/C++.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 se uso un Frame , devo creare una Classe dentro il form Child
xche?
A.

> end;
non posso farlo , il Form usa il Frame, vi sarebbe un riferimento circolare
si dovrebbe trovare il modo che il Form "ascoltasse" le comunicazioni del 
Frame
Maurizio 

 esistesse
Secondo me, dobbiamo fare un passo indietro.
xche non spieghi a grandi linee cio che devi realizzare?
A.

> xche non spieghi a grandi linee cio che devi realizzare?
lo scopo e' creare una sola ToolBar (Barra Pulsanti personalizzata
tramite uso di TSpeedButton), altrimenti avrei 2 vie
1) una ToolBar sul form di avvio , pero' quando vado a cambiare la
Toolbar (abilitare / disabilitare pulsanti) devo crearmi un Array dove
memorizzare lo stato dei vari pulsanti in base al Form attivo.
2) avere una ToolBar su ogni form che abbia pero' in comune l'Action List
ho optato per questa seconda ed ho (al momento) risolto cosi'
ho
- 1 Form principale
- vari Frame che uso al posto dei vari Form
- 1 Frame per la ToolBar con i Pulsanti e gli eventi
quando creo un form secondario , creo istanza al Frame che deve essere
caricato
nell'evento OnCreate del Frame faccio creare istanza al Frame ToolBar
poniamo di avaere Frame2 per la ToolBar , Frame5 per il Form
dal form Avvio
procedure TForm1.N11Click(Sender: TObject);
begin
  frm2:=TFrame5.Create(Self);
  frm2.Parent:=ScrollBox1;
  frm2.Show;
end;
// nella classe del frame definisco il costruttore
type
  TFrame5 = class(TFrame)
    Panel1: TPanel;
  private
    { Private declarations }
    ToolBar:TFrame2;
  public
    { Public declarations }
    constructor create(AOwner: TComponent); override;
    destructor destroy; override;
  end;
// nel Frame creo il pannello strumenti
constructor TFrame5.Create(AOwner: TComponent);
begin
  inherited;
  ToolBar:=TFrame2.Create(Self);
  ToolBar.Parent:=Panel1;
  ToolBar.Align:=alClient;
  ToolBar.Show;
end;
cosi' ogni Form ha la sua ToolBar , ma un unico gestoire di eventi.
procedure TFrame2.Action2Execute(Sender: TObject);
begin
  SpeedButton2.Enabled:=False;
end;
procedure TFrame2.Action3Execute(Sender: TObject);
begin
 SpeedButton2.Enabled:=True;
 SpeedButton1.Visible:=False;
end;
al momento non ho trovato altre vie piu' eleganti.
Maurizio