---

Jeg tror ikke dine get eller set -metoder helt opfylder normen. Følgende
skulle være det du efterlyser, og det virker helt fint. En
TObject-specialisering med en XProperty, som gemmes i en TList, accesses via
en Items-property på formen. Get og Set metoderne kaldes både når jeg

* indsætter et helt objekt
* henter et helt object
* ændrer XProperty på det enkelte object

TNameObject =class(TObject)
private
FXProperty: string;
procedure SetXProperty(const Value: string);
public
property XProperty:string read FXProperty write SetXProperty;
end;

TForm1 = class(TForm)
Button1: TButton;
procedure FormCreate(Sender: TObject);
private
FList : TList;
function GetItem(index: integer): TNameObject;
procedure SetItem(index: integer; const Value: TNameObject);
public
property items[index:integer]:TNameObject read GetItem write SetItem;
end;

{ TNameObject }

procedure TNameObject.SetXProperty(const Value: string);
begin
FXProperty := Value;
end;

{ TForm1 }
function TForm1.GetItem(index: integer): TNameObject;
begin
if (index>FList.count) then
begin
//rejs exception
end else result:=TNameObject(FList.items[index]);
end;

procedure TForm1.SetItem(index: integer; const Value: TNameObject);
begin
if (index>FList.Count-1) then
begin
//rejs evt exception her
FList.add(value);
end else FList.items[index]:=value;
end;

procedure TForm1.FormCreate(Sender: TObject);
var X:TObject;
count:integer;
begin
FList:=TList.create;

//getset-metoder kaldes her
for count:=0 to 10 do
begin
X:=TObject.create;
items[count]:=TNameObject(X);
end;

//getset-metoder kaldes her
for count:=0 to 10 do
begin
X:=items[count];
end;

//getset-metoder kaldes OGSÅ her
for count:=0 to 10 do
begin
items[count].XProperty:='abc';
end;

end;

Håber det kunne hjælpe. TIP : Det er altid en god at bruge delphi's
højreklik|Complete class at cursor. Tast simpelthen klassen, f.eks

TEksempel =class(TObject)
private
public
property test:integer;
end;

Hvorefter der genereres følgende

TEksempel =class(TObject)
private
Ftest: integer;
procedure Settest(const Value: integer);
public
property test:integer read Ftest write Settest;
end;

{ TEksempel }

procedure TEksempel.Settest(const Value: integer);
begin
Ftest := Value;
end;

---

Hej David

Mange tak for tippet og det glimrende eksempel! :) Jeg kan dog STADIG
ikke få skidtet til at virke..! Her hos mig bliver Set-metoden IKKE
kaldt når jeg opdaterer et objekt i mit array. Det undrer mig meget..

Jeg har taget dit eksempel og puttet det ind i et delphi-project, prøv
det engang:

http://www.regnecentralen.dk/thm/GetSetTest.zip

Jeg har ikke lavet ret meget om på dit eksempel, blot lige smidt tre
knapper på formen, så de enkelte opdateringsmuligheder kan kaldes
enkeltvist.

Det her undrer mig MEGET. Hvordan i alverden kan jeg få lov til at
opdatere en værdi i en privat TList gennem en array-property UDEN at
Set-metoden bliver kaldt? Får du samme fejl? Mystisk! :) Jeg bruger
Delphi 7, mon det er den der er noget galt med?!


--
Mvh.
Thomas Holmgren

---

Hej Thomas,

Når jeg kører dit eksempel virker det ...

in method SetItem
in method SetItem
in method GetItem
in method GetItem
in method GetItem
in method GetItem

(Delphi 6)

---

Hej Nicolaj
Nicolai Hansen wrote:

> Når jeg kører dit eksempel virker det ...
>
> in method SetItem
> in method SetItem
> in method GetItem
> in method GetItem
> in method GetItem
> in method GetItem

Jeg gætter på du har trykket på alle tre knapper, startende med den
øverste? Hvis du har, så får jeg samme resultat som dig - nemlig at når
jeg trykker på den nederste knap får jeg kun linierne

in method GetItem
in method GetItem

...hvor jeg gerne ville have - og ville forvente - at den kalder BÅDE
GetItem OG SetItem.

Hvorfor bliver SetItem ikke kaldt når man opdaterer et element i det
skide array? For pokker da også! :)


--
Mvh.
Thomas Holmgren

---

"Thomas Holmgren" <thm@regnecentralen.dk> wrote in message
news:c2mk7o$2tom$1@news.cybercity.dk...

> ..hvor jeg gerne ville have - og ville forvente - at den kalder BÅDE
> GetItem OG SetItem.
>
> Hvorfor bliver SetItem ikke kaldt når man opdaterer et element i det
> skide array? For pokker da også! :)

Helt ærligt - en datalog som dig burde da kunne løse dette problem selv

Anyway - det er en helt specifik funktionalitet du er ude efter, som
OOP-konceptet ikke honorerer. Du Set'er jo ikke array-objectet, men det
object, som via GET hentes ud af array-objectet, hvorfor FXProperty'ens
SetMetode kaldes. Husk på, at det er *objekter* vi har med at gøre!

Løsningen er dog rørende enkel - jeg har flere gange selv haft brug for
noget lignende, i større hiearkier. Du ændrer slet og ret dit/mit eksempel
til følgende

TNameObject = class(TObject)
private
FOwner: TControl;
FXProperty:string;
procedure SetXProperty(const Value: string);
public
constructor create(AOwner:TControl);reintroduce;virtual;
property XProperty:string read FXProperty write SetXProperty;
end;
....
constructor TNameObject.create(AOwner: TControl);
begin
inherited create;
FOwner:=AOwner;
end;

procedure TNameObject.SetXProperty(const Value: string);
begin
FXProperty:=value;
if assigned(FOwner) then
begin
(FOwner as DinObjectListeType).KaldRelevantUpdateMetode;
end;
end;

Pointen er, at property-klassen kalder sin ejer når det opdateres - hvad den
skal kalde eksakt og hvordan kan du selv definere - det kunne f.eks være en
"procedure UpdateNeeded" eller en "property UpdateFlag:boolean" - min egen
foretrukne metode er at sende en særlig message til ownerklassen, som den så
modtager som alle andre messages og behandler - det kræver dog også noget
forarbejde med registrering af messages...Du kan oven i købet "protecte" den
metode der skal kaldes, eller det flag der skal sættes, hvis både
property-klasserne og din object-liste ligger i samme unit.

---

Hej David

David Konrad wrote:

> Helt ærligt - en datalog som dig burde da kunne løse dette problem selv

Hehe, ja, den sved ;) Nogen Delphi-ekspert må jeg nok tilstå at jeg
bestemt ikke er, her er jeg ganske grøn. Flere ting ved Delphi undrer
mig - også stadigvæk dette lille "problem". Når min delphi-bog kækt
proklamerer at "access to private class members are protected by the
property's get- and set methods and can only be accessed through these
methods" så ville jeg da REGNE med at tilgang (på referenceniveau) til
private instansvariable KUN kunne ske gennem disse metoder?! Jeg synes
indtil videre at Delphi er vældig "lækkert" at have med at gøre; der er
meget "kort vej til succes", men tilgængæld også en pokkers masse rod
som virker ulogisk iflg. alm. tankegang - ting som man bare SKAL vide
på forhånd. Lidt ligesom at lære et (tale)sprog med mange uregelmæssige
verber. :)

Men jo, problemet kan naturligvis løses på andre måder, og det bliver
jeg jo så nød til. Mange tak for dit glimrende forslag, jeg finder helt
sikkert på et eller andet.


--
Mvh.
Thomas Holmgren

---

"Thomas Holmgren" <thm@regnecentralen.dk> wrote in message
news:c2phq3$uq3$1@news.cybercity.dk...

> Hehe, ja, den sved ;)

Det *var* en joke

> Nogen Delphi-ekspert må jeg nok tilstå at jeg
> bestemt ikke er, her er jeg ganske grøn. Flere ting ved Delphi undrer
> mig - også stadigvæk dette lille "problem". Når min delphi-bog kækt
> proklamerer at "access to private class members are protected by the
> property's get- and set methods and can only be accessed through these
> methods" så ville jeg da REGNE med at tilgang (på referenceniveau) til
> private instansvariable KUN kunne ske gennem disse metoder?!

Ja - men det kan omgåes indenfor samme unit.

>Jeg synes
> indtil videre at Delphi er vældig "lækkert" at have med at gøre;

Det er ganske enkelt genialt. Nu er det årevis siden jeg selv har brugt
Delphi professionelt, men fra set VisualAge for Java som mulig konkurrent,
kender jeg intet bedre udviklingsmiljø. Dog synes jeg 7 er lige lovlig
"tung".

>der er
> meget "kort vej til succes", men tilgængæld også en pokkers masse rod
> som virker ulogisk iflg. alm. tankegang - ting som man bare SKAL vide
> på forhånd. Lidt ligesom at lære et (tale)sprog med mange uregelmæssige
> verber. :)

Tænker du på noget konkret?

> Men jo, problemet kan naturligvis løses på andre måder, og det bliver
> jeg jo så nød til. Mange tak for dit glimrende forslag, jeg finder helt
> sikkert på et eller andet.

Det er imho relativt elegant, og hvis du implementerer teknikkken i en
generel "TPropertyClass" eller lignende, med tilhørende registrering af
"notify"-messages, som altid er ancestor til dine property-classes, har du
et fikts og færdigt system du kan genbruge i alle dine komponenter/klasser
fremover.

---

Hej David
David Konrad wrote:

>>Hehe, ja, den sved ;)
> Det *var* en joke

Det er GAS, jeg ka ta' det! ;)

>>Lidt ligesom at lære et (tale)sprog med mange uregelmæssige verber. :)
> Tænker du på noget konkret?

Njaah, jeg synes der har været flere småting hvor man lige har tænkt
"det var da mystisk, det stammer helt sikkert fra det gode gamle
Pascal". :) F.eks. at strenge indexeres fra 1 og ikke 0 glemmer jeg ret
ofte. Eller i det hele taget at strenge (og andre sammensatte typer),
opfattes som simple typer og pr. default overføres som værdiparametre,
modsat objekter, der altid overføres som referenceparametre, uanset om
man angiver parametren som variabelparameter eller ej. I denne
sammenhæng: Skabes objekter altid på heapen når jeg instantierer dem med
Create (som hvis jeg brugte new i java/C++)? Kan man ikke skabe et
objekt i den lokale stackframe hvis det kun skal bruges i en enkelt
metode (som hvis jeg IKKE bruger new i java/C++)? Der har været andre
tilsvarende småting undervejs, jeg kan ikke lige komme på dem nu. Men
hva, det er jo de små forskelle der gør det morsomt at lære et nyt sprog
OG så irriterer det mig lidt - nu hvor jeg lige kommer fra C++ - at
der ikke findes multipel nedarvning i delphi!

MEN som sagt synes jeg man har en "god fornemmelse" når man sidder og
laver et eller andet i delphi. Man får hurtigt fornemmelsen af at "det
virker sgu" - uden at man - som f.eks. i C++ - skal sidde og bruge en
masse krudt og kodelinier på at allokere hukommelse, kontrollere
pointere, sikre sig mod overflow af ditten og datten, håndtere et hav af
lavniveausignaler fra OS osv. osv. osv.

Man kan i delphi vældig hurtigt lave noget som fungerer glimrende og som
ikke fylder ret mange linier. Det er samtidig grunden til at jeg spørger
om så mange ting herinde - det er let at lave noget der virker, men
laver man det "rigtigt" set med delphi-øjne? Der er ikke meget ved et
nyt sprog, hvis man ikke får lært de helt specifikke, smarte ting, og i
stedet bare sidder og implementerer tingene på samme måde som man plejer
at gøre i de (andre) sprog man kender.

Måske mangler jeg bare en god delphi-bog? Den eneste jeg har er "Delphi
in a nutshell", og den er edderbankemig elendig!


--
Mvh.
Thomas Holmgren

---

Thomas Holmgren wrote:

> Hej David
> David Konrad wrote:
>
> >>Hehe, ja, den sved ;)
> > Det *var* en joke
>
> Det er GAS, jeg ka ta' det! ;)
>
>>>Lidt ligesom at lære et (tale)sprog med mange uregelmæssige verber. :)
>> Tænker du på noget konkret?
>
> Njaah, jeg synes der har været flere småting hvor man lige har tænkt
> "det var da mystisk, det stammer helt sikkert fra det gode gamle
> Pascal". :)

Det gør det oftest, ja.

> F.eks. at strenge indexeres fra 1 og ikke 0 glemmer jeg ret
> ofte.

Man lærer det hurtigt :)

> Eller i det hele taget at strenge (og andre sammensatte typer),
> opfattes som simple typer og pr. default overføres som værdiparametre,
> modsat objekter, der altid overføres som referenceparametre, uanset om
> man angiver parametren som variabelparameter eller ej. I denne
> sammenhæng: Skabes objekter altid på heapen når jeg instantierer dem med
> Create (som hvis jeg brugte new i java/C++)?

Ja.

> Kan man ikke skabe et
> objekt i den lokale stackframe hvis det kun skal bruges i en enkelt
> metode (som hvis jeg IKKE bruger new i java/C++)?

Ikke så vidt jeg ved. Til gengæld kan du bruge følgende hvis du ønsker at
bruge et object uden tilhørende variabel - dét kan man ikke i C++, svjv :)

With TFileStream.Create('fil.dat', fmOpenWrite OR fmShareDenyNone) Do
Begin
Read(data...);
Write(data...);
Free;
End;

Det er imho bedst til hurtigt at teste noget, men det virker.

> Der har været andre tilsvarende småting undervejs, jeg kan ikke lige komme
> på dem nu.

Bare spørg her i gruppen :)

> Men hva, det er jo de små forskelle der gør det morsomt at lære
> et nyt sprog OG så irriterer det mig lidt - nu hvor jeg lige kommer
> fra C++ - at der ikke findes multipel nedarvning i delphi!

Du har ikke multipel nedarvning, nej, men man har en renere objektmodel :)

Til gengæld kan du lave multipel implementation ifb interfaces, altså:

Type
TMyClass = Class(TInterfacedObject, IMyInterface1, IMyInterface2);
// Interface1-metoder
// Interface2-metoder
End;

> MEN som sagt synes jeg man har en "god fornemmelse" når man sidder og
> laver et eller andet i delphi. Man får hurtigt fornemmelsen af at "det
> virker sgu" - uden at man - som f.eks. i C++ - skal sidde og bruge en
> masse krudt og kodelinier på at allokere hukommelse, kontrollere
> pointere, sikre sig mod overflow af ditten og datten, håndtere et hav af
> lavniveausignaler fra OS osv. osv. osv.

There you go :)

Det er netop én af de rare ting ved Delphi - det virker bare! Hvis du fx
skulle have lyst til manuel allokering af strenge kan det også lade sig
gøre (string vs. pchar).

Man skal selvfølgelig stadig passe på ikke at lave fejl, men der er færre
ting der kan gå galt, specielt med tanke på strenge.

> Man kan i delphi vældig hurtigt lave noget som fungerer glimrende og som
> ikke fylder ret mange linier. Det er samtidig grunden til at jeg spørger
> om så mange ting herinde - det er let at lave noget der virker, men
> laver man det "rigtigt" set med delphi-øjne?

Ikke nødvendigvis, men sådan er det med alle sprog :)

> Der er ikke meget ved et nyt sprog, hvis man ikke får lært de helt
> specifikke, smarte ting, og i stedet bare sidder og implementerer tingene
> på samme måde som man plejer at gøre i de (andre) sprog man kender.
>
> Måske mangler jeg bare en god delphi-bog? Den eneste jeg har er "Delphi
> in a nutshell", og den er edderbankemig elendig!

Jeg kender den ikke, men det skulle ikke undre mig. Hvis du skal lære pascal
(hvilket ville være en god start) kan jeg anbefale "Turbo Pascal 7.0" af
Per Amdahl Steffensen og Leif Pehrsson.

--
M.V.H
Christian Iversen

---

"Thomas Holmgren" <thm@regnecentralen.dk> wrote in message
news:c36iap$1pg4$1@news.cybercity.dk...

> Njaah, jeg synes der har været flere småting hvor man lige har tænkt
> "det var da mystisk, det stammer helt sikkert fra det gode gamle
> Pascal". :) F.eks. at strenge indexeres fra 1 og ikke 0 glemmer jeg ret
> ofte.

Nu er strenge jo også en lidt speciel pascal-opfindelse...?

>Eller i det hele taget at strenge (og andre sammensatte typer),
> opfattes som simple typer og pr. default overføres som værdiparametre,
> modsat objekter, der altid overføres som referenceparametre, uanset om
> man angiver parametren som variabelparameter eller ej.

Jeg kan ikke se problemet. Det er ikke mange år siden, der overhovedet ikke
var noget der hed objekter, så for mange (måske de fleste?) gik tilvænningen
jo rent faktisk den anden vej.

Hvis jeg skal kritisere Delphi/Pascal er det faktisk, at man i modsætning
til andre sprog ikke bare kan oprette variable on-the-fly. Man går generelt
både med livrem og seler og Delphi.

> I denne
> sammenhæng: Skabes objekter altid på heapen når jeg instantierer dem med
> Create (som hvis jeg brugte new i java/C++)?

Ja! Men det er ikke "create" du danner objekter med, det er konstruktøren,
og den allokerer en pointer-reference på heapen, og kun denne
pointerreference.

>Kan man ikke skabe et
> objekt i den lokale stackframe hvis det kun skal bruges i en enkelt
> metode (som hvis jeg IKKE bruger new i java/C++)?

Du har i Delphi ækvivalenten class-methods, i stedet for de statiske metoder
du hentyder til i java/c. Delphis compiler gør meget ud af at reducere
brugen af stack frames, men det går uden for min rækkevidde at beskrive
dette i detaljer. Hvis du vil overstyre den slags, må du ty til
inline-assembler i koden - der findes adskillige artikler om den slags på
nettet. Jeg kan dog ikke begribe, at det overhovedet skulle være et problem


>Der har været andre
> tilsvarende småting undervejs, jeg kan ikke lige komme på dem nu. Men
> hva, det er jo de små forskelle der gør det morsomt at lære et nyt sprog
>

Har man lært ét sprog synes jeg man har lært alle, det er blot at vænne sig
til jargonen - som at flytte til Jylland, f.eks.

>OG så irriterer det mig lidt - nu hvor jeg lige kommer fra C++ - at
> der ikke findes multipel nedarvning i delphi!

Det gør der nu også, via interfaces. Men fortæl mig hvad problemet er, og
jeg kan sikkert vise dig en simpel løsning der ikke bruger multipel
nedarvning. Jeg har aldrig set et problem, hvor multipel nedarvning var
eneste og bedste løsning - ikke at de sikkert ikke findes, men det skal godt
nok være specielt

> MEN som sagt synes jeg man har en "god fornemmelse" når man sidder og
> laver et eller andet i delphi. Man får hurtigt fornemmelsen af at "det
> virker sgu" - uden at man - som f.eks. i C++ - skal sidde og bruge en
> masse krudt og kodelinier på at allokere hukommelse, kontrollere
> pointere, sikre sig mod overflow af ditten og datten, håndtere et hav af
> lavniveausignaler fra OS osv. osv. osv.

SÅ slemt synes jeg nu heller ikke C er. C er også rart, og jeg synes man med
C kan lave virkelig smarte ting, som ikke helt er så nemme at lave i Delphi.

> Man kan i delphi vældig hurtigt lave noget som fungerer glimrende og som
> ikke fylder ret mange linier. Det er samtidig grunden til at jeg spørger
> om så mange ting herinde - det er let at lave noget der virker, men
> laver man det "rigtigt" set med delphi-øjne?

Det der virker, og som andre kan forstå, og som man er i stand til at ændre
i også et halvt år efter må være rigtigt. Der findes imho ingen "rigtig"
Delphi-programmeringsteknik, måske bortset fra
navnetildelingskonventionerne.

> Der er ikke meget ved et
> nyt sprog, hvis man ikke får lært de helt specifikke, smarte ting, og i
> stedet bare sidder og implementerer tingene på samme måde som man plejer
> at gøre i de (andre) sprog man kender.
>
> Måske mangler jeg bare en god delphi-bog? Den eneste jeg har er "Delphi
> in a nutshell", og den er edderbankemig elendig!

"Mastering Delphi" er imho et kig værd.

---

> Njaah, jeg synes der har været flere småting hvor man lige har tænkt
> "det var da mystisk, det stammer helt sikkert fra det gode gamle
> Pascal". :) F.eks. at strenge indexeres fra 1 og ikke 0 glemmer jeg ret
> ofte.

Ja, i Pascal er streng[0] længden af strengen. Dette er så vidt jeg
husker dog IKKE en del af Standard Pascal, men vist af Extended
Pascal.

> Eller i det hele taget at strenge (og andre sammensatte typer),
> opfattes som simple typer og pr. default overføres som værdiparametre,
> modsat objekter, der altid overføres som referenceparametre, uanset om
> man angiver parametren som variabelparameter eller ej.

Uha, Delphi's strenge overføres som reference parametre. En Delphi
streng er en ret avanceret ting, som ikke altid er lige heldig ;)

> I denne
> sammenhæng: Skabes objekter altid på heapen når jeg instantierer dem med
> Create (som hvis jeg brugte new i java/C++)? Kan man ikke skabe et
> objekt i den lokale stackframe hvis det kun skal bruges i en enkelt
> metode (som hvis jeg IKKE bruger new i java/C++)?

Nej - Pascal bruger generelt ikke stack'en til alle de ting C elsker
at bruge den til.
Ligeledes findes forskellen mellem "Object obj" og "Object *obj" ikke
i Delphi - dette er en ting jeg tit selv savner.

> Der har været andre
> tilsvarende småting undervejs, jeg kan ikke lige komme på dem nu. Men
> hva, det er jo de små forskelle der gør det morsomt at lære et nyt sprog
> OG så irriterer det mig lidt - nu hvor jeg lige kommer fra C++ - at
> der ikke findes multipel nedarvning i delphi!

Multipel nedarvning er en ting (omgås ved at bruge COM++
objekter/interfaces), personligt synes jeg at den manglende mulighed
for det som vist kaldes generisk programmering (templates i C++) er et
større savn.

> MEN som sagt synes jeg man har en "god fornemmelse" når man sidder og
> laver et eller andet i delphi. Man får hurtigt fornemmelsen af at "det
> virker sgu" - uden at man - som f.eks. i C++ - skal sidde og bruge en
> masse krudt og kodelinier på at allokere hukommelse, kontrollere
> pointere, sikre sig mod overflow af ditten og datten, håndtere et hav af
> lavniveausignaler fra OS osv. osv. osv.

Borland's C++ Builder virker ret meget som Delphi mht den slags ting.
Her slipper du også for at håndtere Window's beskeder og den slags.

> Man kan i delphi vældig hurtigt lave noget som fungerer glimrende og som
> ikke fylder ret mange linier. Det er samtidig grunden til at jeg spørger
> om så mange ting herinde - det er let at lave noget der virker, men
> laver man det "rigtigt" set med delphi-øjne? Der er ikke meget ved et
> nyt sprog, hvis man ikke får lært de helt specifikke, smarte ting, og i
> stedet bare sidder og implementerer tingene på samme måde som man plejer
> at gøre i de (andre) sprog man kender.

Du laver det overordnede design ens i Delphi og C++. Den lidt lavere
implementation af tingene er dog ofte ret forskellig (C(++) giver dig
en masse mulgiheder som Delphi ikke giver dig. Dette er ikke
nødvændigvis godt)

> Måske mangler jeg bare en god delphi-bog? Den eneste jeg har er "Delphi
> in a nutshell", og den er edderbankemig elendig!

Den bedste reference er Delphi's help fil hvis du spørger mig. Den
kræver blot at man kan forstå Borlandsk...

---

"Nicolai Hansen" <nic@aub.dk> wrote in message
news:d96764ff.0403161058.2876eaba@posting.google.com...
> > Njaah, jeg synes der har været flere småting hvor man lige har tænkt
> > "det var da mystisk, det stammer helt sikkert fra det gode gamle
> > Pascal". :) F.eks. at strenge indexeres fra 1 og ikke 0 glemmer jeg ret
> > ofte.
>
> Ja, i Pascal er streng[0] længden af strengen. Dette er så vidt jeg
> husker dog IKKE en del af Standard Pascal, men vist af Extended
> Pascal.

Det mener jeg også det var (uden at have slået det efter)