/ Forside / Teknologi / Udvikling / Delphi/Pascal / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Delphi/Pascal
#NavnPoint
oldwiking 603
jrossing 525
rpje 520
EXTERMINA.. 500
gandalf 460
gubi 270
DJ_Puden 250
PARKENSS 230
technet 210
10  jdjespers.. 200
Event
Fra : Nico de Jong


Dato : 16-02-06 13:00

Hej alle

Jeg sidder med et lille problem.
Lidt simplificeret :
Jeg har to Forms. På begge forms har jeg en listbox, som indeholder de samme
data.. På form1 har jeg mulighed for at tilføje et item til listboxen. Hvad
jeg nu mangler, er at vide hvordan man indenfor Form1 siger at Form2 skal
opdatere sin listbox.
Jeg vil helst slippe for at Form1 snakker _direkte_ med Form2. Jeg er mere
på udkig efter en event e.l. som aktiverer Form2.OnChange

Hvordan gør jeg det ?

Nico



 
 
Brian Andersen \(www~ (16-02-2006)
Kommentar
Fra : Brian Andersen \(www~


Dato : 16-02-06 13:47

Hej Nico,

du kan bruge Observer Design Pattern.

Eller følgende kunne måske også gøre det. Det er skrevet løst i hånden og
utestet. Måske jeg har glemt noget? Så forsøg dig frem.

/Brian

TCommonEvent = class
private
FOperation: Longint;
FData: Pointer;

FOnReceive: TNotifyEvent;
public
procedure Send(AOperation: Longint; AData: Pointer);

property Operation: Longint read FOperation;
property Data: Pointer read FData;

property OnReceive: TObject read FOnReceive write FOnRecieve;
end;

procedure TCommonEvent.Send(AOperation: Longint; AData: Pointer);
begin
FOperation := AOperation;
FData := AData;
if Assigned(FOnReceive) then FOnRecieve(Self);
end;

Fra Form1 skriver du så.

procedure TForm1.ButtonClick1(Sender: TObject)
begin
Form2CommonEvent.Send(0, ListBox1.Items);
end;


Fra Form2 skriver du så:

constructor TForm2.Create(AOwner: TComponent);
begin
inherited;

Form2CommonEvent.OnReceive := ReceiveEvent;
end;

procedure TForm2.ReceiveEvent(Sender: TObject);
begin
ListBox.Items := TStrings(Sender as TCommonEvent));
end;




Nico de Jong (16-02-2006)
Kommentar
Fra : Nico de Jong


Dato : 16-02-06 15:41


"Brian Andersen (www.europeansoftwarehouse.com)" <x@x.x> skrev i en
meddelelse news:ts_If.50$NM5.13@news.get2net.dk...
> Hej Nico,
>
> du kan bruge Observer Design Pattern.
>
Den har jeg lige kigget på, og det ser spændende ud.

Jeg har fundet en anden måde, som jeg godt vil høre din / Jeres mening om.

Som sagt har jeg 2 Forms, med identiske listboxer, og identisk indhold.
"projektet" bruges kun til at afprøve et par teknikker, så det er nemmere at
implementere i produktionsversionen af softwaren.

I Form1 kan jeg modificere listboxen med nye Items hhv fjerne andre. Disse
skal så vises på Form2.

Det jeg nu gjorde, var at jeg på Form2 laver en ny procedure, der kaldes
i.f.m. Eventet Form2.OnShow.
For det tilfælde at begge forms er synlige samtidige, kan man bruge eventet
Form2.OnActivate. Denne event kaldes åbenbart når man klikker på formen
første gang, hvorefter listboxen opdateres. Ikke med indholdet af
Form1.listbox, men med indholdet af et fælles objekt.

Har jeg mon fundet De Vises Sten, eller er der noget der halter ?

MvH

Nico



Harald (16-02-2006)
Kommentar
Fra : Harald


Dato : 16-02-06 16:54

"Nico de Jong" <nico@farumdata.dk> skrev i en meddelelse
news:j40Jf.68$u97.39@news.get2net.dk...
>
> "Brian Andersen (www.europeansoftwarehouse.com)" <x@x.x> skrev i en
> meddelelse news:ts_If.50$NM5.13@news.get2net.dk...
>> Hej Nico,
>>
>> du kan bruge Observer Design Pattern.
>>
> Den har jeg lige kigget på, og det ser spændende ud.
>
> Jeg har fundet en anden måde, som jeg godt vil høre din / Jeres mening om.
>
> Som sagt har jeg 2 Forms, med identiske listboxer, og identisk indhold.
> "projektet" bruges kun til at afprøve et par teknikker, så det er nemmere
> at
> implementere i produktionsversionen af softwaren.
>
> I Form1 kan jeg modificere listboxen med nye Items hhv fjerne andre. Disse
> skal så vises på Form2.
>
> Det jeg nu gjorde, var at jeg på Form2 laver en ny procedure, der kaldes
> i.f.m. Eventet Form2.OnShow.
> For det tilfælde at begge forms er synlige samtidige, kan man bruge
> eventet
> Form2.OnActivate. Denne event kaldes åbenbart når man klikker på formen
> første gang, hvorefter listboxen opdateres. Ikke med indholdet af
> Form1.listbox, men med indholdet af et fælles objekt.
>
> Har jeg mon fundet De Vises Sten, eller er der noget der halter ?

Hvad er problemet egentlig i at kalde en update funktion på Form2 der
opdatere listboxen?

/HK



Nico de Jong (16-02-2006)
Kommentar
Fra : Nico de Jong


Dato : 16-02-06 19:51

"Harald" <nomail@noname.dk> skrev i en meddelelse
news:43f4a005$0$84033$edfadb0f@dtext01.news.tele.dk...
> >
> > Det jeg nu gjorde, var at jeg på Form2 laver en ny procedure, der kaldes
> > i.f.m. Eventet Form2.OnShow.
> > For det tilfælde at begge forms er synlige samtidige, kan man bruge
> > eventet
> > Form2.OnActivate. Denne event kaldes åbenbart når man klikker på formen
> > første gang, hvorefter listboxen opdateres. Ikke med indholdet af
> > Form1.listbox, men med indholdet af et fælles objekt.
> >
> > Har jeg mon fundet De Vises Sten, eller er der noget der halter ?
>
> Hvad er problemet egentlig i at kalde en update funktion på Form2 der
> opdatere listboxen?

Mener du at Update form2 fra form1 af? Det var netop det jeg ville undgå
(forms der snakker direkte sammen)
Hvis du mener at jeg skal skrive Update indenfor Form2: hvordan skal
Update'n vide at den skal genskrive en listbox med nyt indhold, som skal
hentes fra et objekt?

Nico



Harald (16-02-2006)
Kommentar
Fra : Harald


Dato : 16-02-06 19:49

"Nico de Jong" <nico@farumdata.dk> skrev i en meddelelse
news:gL3Jf.115$ne3.108@news.get2net.dk...
> "Harald" <nomail@noname.dk> skrev i en meddelelse
> news:43f4a005$0$84033$edfadb0f@dtext01.news.tele.dk...
>> >
>> > Det jeg nu gjorde, var at jeg på Form2 laver en ny procedure, der
>> > kaldes
>> > i.f.m. Eventet Form2.OnShow.
>> > For det tilfælde at begge forms er synlige samtidige, kan man bruge
>> > eventet
>> > Form2.OnActivate. Denne event kaldes åbenbart når man klikker på formen
>> > første gang, hvorefter listboxen opdateres. Ikke med indholdet af
>> > Form1.listbox, men med indholdet af et fælles objekt.
>> >
>> > Har jeg mon fundet De Vises Sten, eller er der noget der halter ?
>>
>> Hvad er problemet egentlig i at kalde en update funktion på Form2 der
>> opdatere listboxen?
>
> Mener du at Update form2 fra form1 af? Det var netop det jeg ville undgå
> (forms der snakker direkte sammen)
> Hvis du mener at jeg skal skrive Update indenfor Form2: hvordan skal
> Update'n vide at den skal genskrive en listbox med nyt indhold, som skal
> hentes fra et objekt?

Det jeg mener er at når du ændre på listboxen på form1 hvorfor vil du så
undgå direkte at kalde en funktion på form2 så listboxen på form2 også
bliver opdateret?

/HK



Brian Andersen \(www~ (17-02-2006)
Kommentar
Fra : Brian Andersen \(www~


Dato : 17-02-06 09:05

> Det jeg mener er at når du ændre på listboxen på form1 hvorfor vil du så
> undgå direkte at kalde en funktion på form2 så listboxen på form2 også
> bliver opdateret?

Tidligere skrev Nico:

>Jeg vil helst slippe for at Form1 snakker _direkte_ med Form2. Jeg er mere
>på udkig efter en event e.l. som aktiverer Form2.OnChange

Hvis sådan skal tilstræbes, så ser jeg ingen anden udvej end Observer
Pattern'et.

Ellers, så har du jo i og for sig ret i, at det er en banal problematik. På
TForm1.ListBox1OnChange kunne der jo kaldes en
TForm2.UpdateListBox(AStrings: TStrings); metode.


Nico du skriver

>Det jeg nu gjorde, var at jeg på Form2 laver en ny procedure, der kaldes
>i.f.m. Eventet Form2.OnShow.
>For det tilfælde at begge forms er synlige samtidige, kan man bruge eventet
>Form2.OnActivate. Denne event kaldes åbenbart når man klikker på formen
>første gang, hvorefter listboxen opdateres. Ikke med indholdet af
>Form1.listbox, men med indholdet af et fælles objekt.

Jeg går ud fra, at grunden til at dine forms ikke må "snakke" samme er fordi
du får en 'Cirkulær Reference' fejl? Din ide med, at dine forms snakker
gennem et fælles objekt vil jo nok kunne implementeres. Dog synes jeg, at
der er et eller andet galt, når du både er afhængig af OnShow og OnActivate.
Jeg har dog ikke set dit program i sin fulde helhed, så måske der kan være
mening med galskaben *s*?

/Brian



Nico de Jong (17-02-2006)
Kommentar
Fra : Nico de Jong


Dato : 17-02-06 09:51

"Brian Andersen (www.europeansoftwarehouse.com)" <x@x.x> skrev i en
meddelelse news:2qfJf.4321
> Jeg går ud fra, at grunden til at dine forms ikke må "snakke" samme er
fordi
> du får en 'Cirkulær Reference' fejl? Din ide med, at dine forms snakker
> gennem et fælles objekt vil jo nok kunne implementeres. Dog synes jeg, at
> der er et eller andet galt, når du både er afhængig af OnShow og
OnActivate.
> Jeg har dog ikke set dit program i sin fulde helhed, så måske der kan være
> mening med galskaben *s*?
Nej, der er ikke nogen circulair reference fejl. Fælles procedurer og
functions har jeg landsforvist til specielle units.
Problemet ligger i at jeg har en application med 25 Forms, som stort set
allesammen refererer til 1 bestemt form, indeholdende mine parametre. Af de
´øvrige 24 er der omkring 10 der også snakker sammen.
Det jeg roder med i de 2 forms der er tale om, er kun at betragte som
udviklingsværktøj, så det er nemmere at overskue. Det bagvedliggende problem
er at jeg vil undgå vedligholdelsesproblemer på specielt de 10 forms der
snakker sammen på kryds og tværs.

Nico



Brian Andersen \(www~ (17-02-2006)
Kommentar
Fra : Brian Andersen \(www~


Dato : 17-02-06 11:33

I øjeblikket sidder jeg med et projekt, hvor der også er en hullens masse
indstillinger til en hullens masse forskellige moduler. Det jeg gør er, at
jeg har et "Settings Object" til hver indstillingsmulighed. Nogle af disse
"Settings Objekter" bliver så oprettet ligeså snart programmet starter.
Andre, når der er behov for dem: F.eks. ved udskrifter, kopiering af data,
osv. Álle disse værdier gemmes i en database, så indstillingerne huskes og
kan genindlæses de specifikke "Settings Objecter"..

Hvis der så skal ændres på en bestemt indstilling, så aktiverer brugeren det
givne "Settings skærmbillede" til det givne "Settings object". Skærmbillede
har så en Ok knap til at gemme ændringerne og en Annuller knap til at
fortryde ændringerne.

Du kunne gøre lidt ligesom jeg har gjort ved at oprette et CommonData modul.
I dit CommonData modul kan du så have forskellige Aggregerede
Indstillingsobjekter allokeret. Princippet i designet er, at der ikke
behøves at være allokeret nogle skærmbilleder for at aflæse en specifik
indstilling. Dette sparer GUI Ressourcer i Windows, samt så holdes
skærmbilleder og data adskildt.

Nu tror jeg, at jeg har forstået lidt af det du skriver. Måske et Observer
Pattern her er lidt overkill *s*? Dog bruger jeg det til at sammenkoble et
beregningsmodul, med forskellige skærmkomponenter som skal opdateres.
Observeren sender så en besked ud, at nu har brugeren foretaget en handling
og en ny beregning er klar. De forskellige skærmkomponenter lytter så om
beskeden er til dem. Og, er det til dem, så refresh'er de så sig selv.
F.eks. et diagram opdateres, beregninger opdateres på skærmen så brugeren
kan se resultatet af sine handlinger, osv.

Se nedenstående kode, som jeg tror kan løse dine problemer...

type
TUTMItemSettings = class;

TCommonData = class(TDataModule)
private
FUTMItemSettings: TUTMItemSettings;
public
constructor Create(AOwner: TComponent); override;
destructor Destroy; override;

property UTMItemSettings: TUTMItemSettings read FUTMItemSettings;
end;

TUTMItemSettings = class(TPersistent)
private
FItems: TStrings;
procedure SetItems(const Value: TStrings);
publc
constructor Create;
destructor Destroy; override;

property Items: TStrings read FItems write SetItems;
end;

implementation

{ TCommonData }
constructor TCommonData.Create(AOwner: TComponent);
begin
inherited;
FUTMItemSettings := TUTMItemSettings.Create;
end;

destructor TCommonData.Destroy;
begin
FUTMItemSettings.Free;
inherited;
end;


{ TUTMItemSettings }
constructor TUTMItemSettingsCreate;
begin
inheirted;
FItems := TStringList.Create;
end;

destructor TUTMItemSettingsDestroy; override;
begin
FItems.Free;
inherited;
end;

procedure TUTMItemSettingsSetItems(const Value: TStrings);
begin
FItems.Assign(Value);
end;


Fra dine TForm1.OnDeactivet eller TForm1.ListBox.OnChange kunne du så skrive
følgende:

begin
CommonData.UTMItemSettings.Items := ListBox1.Items;
end;

Fra din TForm2.OnActivate kunne du så skrive

begin
ListBox2.Items := CommonData.UTMItemSettings.Items;
end;

Jeg håber at du kan se ideen/anvende princippet. Ps. Alt er skrevet i løs
hånd, med risiko for syntaks fejl, osv. *s*.

Hvis jeg havde anvendt en Observer Pattern her, så ville TForm2 automatisk
få besked om, at nu var CommonData.UTMItemSettings.Items objektet blevet
ændret, så opdatering ville være nødvendig. Dette bevirker, at uanset hvad
der måtte ændre CommonData.UTMItemSettings.Items objektet, så ville TForm2
få besked om at Refresh'e. Du skulle altså ikke manuelt sørge for, at
opdatere din TForm2, eller alle andre steder det er påkrævet at være
uptodate med din TForm1.ListBox1.

/Brian



Nico de Jong (17-02-2006)
Kommentar
Fra : Nico de Jong


Dato : 17-02-06 13:29


"Brian Andersen (www.europeansoftwarehouse.com)" <x@x.x> skrev i en
meddelelse news:dBhJf.4346$Ss.659@news.get2net.dk...
> I øjeblikket sidder jeg med et projekt, hvor der også er en hullens masse
> indstillinger til en hullens masse forskellige moduler. Det jeg gør er, at
> jeg har et "Settings Object" til hver indstillingsmulighed. Nogle af disse
> "Settings Objekter" bliver så oprettet ligeså snart programmet starter.
> Andre, når der er behov for dem: F.eks. ved udskrifter, kopiering af data,
> osv. Álle disse værdier gemmes i en database, så indstillingerne huskes og
> kan genindlæses de specifikke "Settings Objecter"..

Tak for den lange mail, som jeg har gemt til nærmere analyse.
Min "fattigmandsløsning" er, at alt ligger i en .INI fil, som læses ind i
starten, og så initierer skærmen med parametrene.
Det er tanken at der evtl skal sættes en lås på det billede, da forkerte
parametre (læs : klummerrøve der piller i noget de ikke har forstand på) kan
afstedkomme en del (lad os sige) uhensigtsmæssigheder.
Det kan dog også godt være, at enkelte af parametrene er så "uskadelige" at
almindelige brugere godt kan få lov at rette dem. I det tilfælde vil jeg
sikkert vælge en løsning i stil med den du har skitseret.
Jeg har ialt 7 grupper parametre :
- ATP45 (kommunikation indenfor NATO)
- e-mail
- Directories
- Sprog
- Fil tællere
- autostart af div. ting
- Tidszone
Der kunne det være relevant at lave 1 skærmbillede til hver gruppe, og så
beskytte enkelte af dem med password e.l.

Du skal ihvertfald have tak for hjælpen, og til Jer andre kan jeg sige at
mit objekt nu virker. Det eneste der ikke er helt "rent" i kanten, er at
øvrige forms kun får genskrevet listboksen når der kommer en form.onshow
eller form.onactivate, men det kan jeg leve med

Nico



Ukendt (18-02-2006)
Kommentar
Fra : Ukendt


Dato : 18-02-06 06:36


"Nico de Jong" <nico@farumdata.dk> wrote in message
news:RJZIf.42$G35.27@news.get2net.dk...
> Hej alle
>
> Jeg sidder med et lille problem.
> Lidt simplificeret :
> Jeg har to Forms. På begge forms har jeg en listbox, som indeholder de
samme
> data.. På form1 har jeg mulighed for at tilføje et item til listboxen.
Hvad
> jeg nu mangler, er at vide hvordan man indenfor Form1 siger at Form2 skal
> opdatere sin listbox.
> Jeg vil helst slippe for at Form1 snakker _direkte_ med Form2. Jeg er mere
> på udkig efter en event e.l. som aktiverer Form2.OnChange
>
> Hvordan gør jeg det ?

Nu har jeg løseligt fulgt tråden, og set, at du tilsyneladende har en
løsning.
Men har du undersøgt muligheden for at bruge user defined messages?

--

Med venlig hilsen/Best regards
Stig Johansen




Nico de Jong (19-02-2006)
Kommentar
Fra : Nico de Jong


Dato : 19-02-06 16:18


"Stig Johansen" <stig_johansen_it_at_hotmail.com> skrev i en meddelelse
news:43f6b20c$0$15788
> Nu har jeg løseligt fulgt tråden, og set, at du tilsyneladende har en
> løsning.
> Men har du undersøgt muligheden for at bruge user defined messages?
>
Nej, det har jeg ikke hørt om. Jeg kigger på det i ugens løb. Tak for tipset

Nico



Ukendt (20-02-2006)
Kommentar
Fra : Ukendt


Dato : 20-02-06 06:44

"Nico de Jong" <nico@farumdata.dk> wrote in message
news:kV%Jf.80$aN7.25@news.get2net.dk...
>
> "Stig Johansen" <stig_johansen_it_at_hotmail.com> skrev i en meddelelse
> news:43f6b20c$0$15788
> > Nu har jeg løseligt fulgt tråden, og set, at du tilsyneladende har en
> > løsning.
> > Men har du undersøgt muligheden for at bruge user defined messages?
> >
> Nej, det har jeg ikke hørt om. Jeg kigger på det i ugens løb. Tak for
tipset

Hvis du har tid, synes jeg du skal undersøge det.
Jeg sidder desværre med adskillige ødelagte IBM deskstar diske, så jeg kan
p.t. ikke komme med et eksempel.
Men jeg *ved*, at jeg engang lavede nogle komponenter, hvor jeg hookede
windows messagehandler.

Så vidt jeg har forstået på din problemstilling, kan løsningen være, at du
laver et nedarvet komponent(fra TListBox), der responderer på en
prædefineret message, der trigger en opdatering.

Da jeg p.t. kører på 'nødblus' angående mine maskiner, bliver du indtil
videre nødt til selv at forske.

--

Med venlig hilsen/Best regards
Stig Johansen




Søg
Reklame
Statistik
Spørgsmål : 177435
Tips : 31962
Nyheder : 719565
Indlæg : 6408016
Brugere : 218879

Månedens bedste
Årets bedste
Sidste års bedste