---

Hej

Jeg har iflg nogens mening udviklet en dårlig vane, nemlig at opdatere en
FORM udefra.
Applikationen har ca. 20 FORMS. Form14 er en opsamling af diverse parametre.
Fra Unit14 kan jeg kalde et antal rutiner, som hver især skal kunne ændre
noget på Form14.
Indtil nu har jeg gjort det med en With Form14 do, men jeg kan godt se at
det er et problem, da man i Unit14/Form14 ikke umiddelbart kan se hvem der
piller i felterne.

Et af felterne er f.eks. en listbox, indeholdende prædefinerede lokationer.
Under listboxen har jeg en button "Vedligehold prædefinerede lokationer",
som så aktiverer en ny Form, som ved afslutningen skal opdatere nævnte
listbox.

Nu er der jo selvfølgelig den mulighed at lægge samtlige feltindhold i
variabler, og så gen-skrive hele formen hver gang, men jeg leder efter en
nemmere / bedre måde at gøre det på.

Nogen forslag ?

Nico

---

"Nico de Jong" <nico@farumdata.dk> skrev i en meddelelse
news:kLDEf.11$BG2.4@news.get2net.dk...
> Hej
>
> Jeg har iflg nogens mening udviklet en dårlig vane, nemlig at opdatere en
> FORM udefra.

Tilføjelse : jeg bruger Delphi 6 Personal

---

Hejsa,

man skal huske at overholde simple forholdsregler. Her er min top 10:

1. Tilstræb Svag kobling.
2. Tilstræb Høj samhørighed.
3. Brug Design Patterns.
4. Ha' konstant genanvendelse i hovedet.
5. Hvis du hele tiden copy/paster, så bør du sætte dig ind i de Object
Orienterede begreber.
6. Forstå de Object Orienterede begreber.
7. Analytisk flair sparer tid.
8. Analyser andres kode og løsninger. Det er ganske givtigt!
9. Hvis du bliver nød til at kvalificere dig mere end 2 - 3 niveauer i din
kode, så har du helt sikkert en designfejl. Altså
Form1.Component1.Other.Left := 1;
10. Hvis du har omgået punkt 9 mange gang i dit projekt, så læs punkt 1 - 8
igen.

Med hensyn til punkt 3:
Det er en Wauw oplevelse af de helt store, når man forstår principperne.
Design Patterns er helt klart værd at have i "værktøjskassen". Lige parat
til at tage op og bruge!

Med hensyn til punkt 6:
Et absolut Must!

Med hensyn til punkt 8:
Jeg husker et bestemt og givtigt projekt, hvor jeg var ude som selvstændig
konsulent. I firmaet havde der været høj udskiftning i den fastansatte stab
(underforstået: de ville ikke betale deres dygtige programmører, så de havde
fundet andre græsgange). Dette afspejlede sig klart i koden. Der var forskel
i stil og kvalitet. Jeg blev nød til at programmere store dele om. Dog var
der steder, hvor koden havde ekstrem høj kvalitet. Det var så heldigt, at
der var kommentarer i koden, så jeg kunne spore den tidligere programmør.
Ham fik jeg med på sidelinien og hold da kæft noget kode vi fik skrevet (o;
Vi supplerede hinanden ganske godt. Det var hårdt, at overlade "barnet" til
andre. Mindes stadigvæk de gode dag *s*.

PS. Jeg her klar over, at teksten "Med hensyn til punkt" er copy/paste.

/Brian

---

"Brian Andersen (www.europeansoftwarehouse.com)" <x@x.x> skrev i en
meddelelse news:i6FEf.6977$Cl2.135085@news000.worldonline.dk...
> Hejsa,
>
> man skal huske at overholde simple forholdsregler. Her er min top 10:
>
> 1. Tilstræb Svag kobling.
> 2. Tilstræb Høj samhørighed.
> 3. Brug Design Patterns.
> 4. Ha' konstant genanvendelse i hovedet.
> 5. Hvis du hele tiden copy/paster, så bør du sætte dig ind i de Object
> Orienterede begreber.
> 6. Forstå de Object Orienterede begreber.
> 7. Analytisk flair sparer tid.
> 8. Analyser andres kode og løsninger. Det er ganske givtigt!
> 9. Hvis du bliver nød til at kvalificere dig mere end 2 - 3 niveauer i din
> kode, så har du helt sikkert en designfejl. Altså
> Form1.Component1.Other.Left := 1;
> 10. Hvis du har omgået punkt 9 mange gang i dit projekt, så læs punkt 1 -
8
> igen.
>
Vi er helt enige i pkt 1-4.
Pkt 5 bruger jeg ikke; i givet fald lægger jeg tingene i en separat unit
6. det har jeg nogenlunde styr på
7. Jeg har været programmør siden 1967, så det har jeg prøvet i rigt mål
8. Helt enig, jeg har bare ikke kunnet finde noget der relaterer til mit
'problem'
9. Enig.

Nedenstående stump kode viser hvad der sker når jeg trykker på "Opdater
prædefinerede lokationer" (der er her tale om UTM koordinater)

procedure TForm1.Button4Click(Sender: TObject);
begin
form2.show;
display_utm_1;
display_utm;
form2.update;
end;

Nedenstående stump viser hvad der sker når jeg er færdig med at vedligeholde
tabellen :

procedure TForm2.button4Click(Sender: TObject); (* afslut vedligehold *)
var
i : integer;
begin
(* listboxen skal gemmes til en diskfil *)
skriv_koord;
(* luk vinduet *)
form2.hide;
(* gendan listbox på form1 *)
form1.listbox1.Items.clear;
i := 1;
while length(utm[i]) > 0 do
begin
form1.listbox1.items.add(utm_text[i]);
inc(i);
end;
end;

For lige at klare begreberne : form1 er hovedformularen, hvor der bl.a. er
en listbox med UTM koordinater og tilhørende stednavne. Indholdet af denne
listbox hentes fra en diskfil. På formen er der en knap hvor man aktiverer
form2, som er til vedligeholdelse af filen / listboxens indhold. Når form2
er færdig, skal listboxen på form1 genskrives, og diskfilen skal opdateres.

Jeg kan tænke mig frem til, at listboxen skal behandles som et objekt, men
hvordan fortæller man form1 at objektet skal genskrives ?

Nico

---

Jeg vil gerne lige tilføje et pkt. 7,5: Hold data og skærmbilleder adskilt
(Svag kobling og høj samhørighed).

Jeg har et par kommentarer jeg håber du kan bruge:

> procedure TForm1.Button4Click(Sender: TObject);
> begin
> form2.show;
> display_utm_1;
> display_utm;
> form2.update;
> end;

Uden at kende detaljerne, så ville jeg aldrig skrive så meget kode i et
event. Jeg ville nøjes med et kald til en procedure, hvor jeg så
implementere detaljerne. Det er efter min mening "renere". Jeg ville altid
have et entydigt navn på komponenter, hvor jeg har programmetet et eller
flere event til (TLabel's er ligegyldigt at navngive). Et eksempel på et
navn til din kanp kunne være: DisplayUTMButton. Såvidt som jeg analysere
det, så udfører funktionerne Display_utm_1 og Display_utm et eller andet på
Form2. Jeg ville dog give Display_Utm procedure'erne nogle bedre navne. Hvad
laver hver procedure kald? F.eks. DisplayUTMPrepare, DisplayUTMValues, osv.
Samtidig, så vil jeg implementere procedure'erne på Form2, som jeg ville
kalde: UTMViewerForm eller lignende. Jeg ville pakke det hele ind i et kald.

// TForm1
procedure TMainForm.DisplayUTMButton(Sender: TObject);
begin
UTMViewerForm.Display(Self);
end;

{ --- }

// TMainForm2
procedure TUTMViewerForm.Display(AMainForm: TMainForm);
begin
FMainForm := AMainForm;

Show;
DisplayUTMPrepare;
DisplayUTMValues;
Update;
end;


Igen her. Bedre navngivning. Jeg kan se, at Form1 (din TMainForm) og Form2
hænger uløseligt sammen. Derfor har jeg defineret din TForm2/TUTMViewerForm
med en parameter. Det er bare en anden måde at gøre det på. Jeg kan ikke
vurdere om det er praktisk anvenligt her? Din TMainForm må være at betragte
som en Associering???

> procedure TForm2.button4Click(Sender: TObject); (* afslut vedligehold *)
> var
> i : integer;
> begin
> (* listboxen skal gemmes til en diskfil *)
> skriv_koord;
> (* luk vinduet *)
> form2.hide;
> (* gendan listbox på form1 *)
> form1.listbox1.Items.clear;
> i := 1;
> while length(utm[i]) > 0 do
> begin
> form1.listbox1.items.add(utm_text[i]);
> inc(i);
> end;
> end;
>
> For lige at klare begreberne : form1 er hovedformularen, hvor der bl.a. er
> en listbox med UTM koordinater og tilhørende stednavne. Indholdet af denne
> listbox hentes fra en diskfil. På formen er der en knap hvor man aktiverer
> form2, som er til vedligeholdelse af filen / listboxens indhold. Når form2
> er færdig, skal listboxen på form1 genskrives, og diskfilen skal
> opdateres.
>
> Jeg kan tænke mig frem til, at listboxen skal behandles som et objekt, men
> hvordan fortæller man form1 at objektet skal genskrives ?
>
> Nico

Jeg forstår ik' helt hvad du skriver? Det du skriver sidst i din kode til
TForm2.button4Click, ser ud til at opdatere din listbox1?

Men, det lyder som om du kan kigge på Observer Design Pattern. Man kan ikke
leve uden at kende det! Observer Pattern bliver eksempelvis brugt i
TDataSource. Her gives beskeder til alle de visuelle kontroller, når der
sker en ændring i et TDataSet.


/Brian

---

"Brian Andersen (www.europeansoftwarehouse.com)" <x@x.x> skrev i en
meddelelse news:wNHEf.6988$Cl2.135352@news000.worldonline.dk...
> >
> Jeg forstår ik' helt hvad du skriver? Det du skriver sidst i din kode til
> TForm2.button4Click, ser ud til at opdatere din listbox1?
>
Præcis. Og det er det jeg gerne vil slippe for.

> Men, det lyder som om du kan kigge på Observer Design Pattern. Man kan
ikke
> leve uden at kende det! Observer Pattern bliver eksempelvis brugt i
> TDataSource. Her gives beskeder til alle de visuelle kontroller, når der
> sker en ændring i et TDataSet.
>
Det vil jeg så forske lidt i.
Foreløbigt tak for hjælpen.

Nico

---

Hejsa igen,

jeg kan læse hvad du skriver, men din forklaring er for abstrakt til mig.
Jeg er bedre til skærmbilleder, kruseduller på papir, diagrammer,
dokumentation og kode. Min opfattelses evene stiger markant, hvis tekst
suppleres med illustrationer. Hvis du vil have min mening (regner med, at du
vil have andres mening siden du skriver i NG), så offentliggør lidt kode
jeg/vi kan kigge på...

/Brian

---

"Brian Andersen (www.europeansoftwarehouse.com)" <x@x.x> skrev i en
meddelelse news:SaFEf.6978$Cl2.135432@news000.worldonline.dk...
> Hejsa igen,
>
> jeg kan læse hvad du skriver, men din forklaring er for abstrakt til mig.
> >
Jeg var nu egentlig mest ude på at få lidt information om hvor man kan finde
noget relevant stof; jeg er af den type der gerne læse manualer og forsøger
at få det ind den vej rund. Men hvis jeg kan få "anskuelighedsundervisning",
er det jo selvfølgelig også fint
Nico