[Delphi] Evalueren van velden

[Verwijderd]

Ik zit een beetje in de knoop met het evalueren van velden in delphi.

ik wil een functie maken die een veld (edit field of een combo veld etc. dat moet dus niet uitmaken) controleert op meegegeven waarde.

Dus zo moet de aanroep van de functie luiden:

Checkfield (editUsername, '');

Waar de eerste value de naam van het veld is.. en de tweede de behorende waarde, in dit geval een lege waarde, is. Snap jullie em?

Hoe kan ik de functie zo maken dat ik er een 'universele' checker van maak? Moet ik dan een var declareren van het type TObject?

Thx voor je hulp alvast

[MaxxRide]

Ik denk dat dit erg moeilijk gaat worden, het probleem is dat de waarde van een TRadioButton als index wordt gegeven maar de waarde van een TEdit bijvoorbeeld met Text.

Je zou volgens mij een CASE moeten maken om te kijken van welk type het meegegeven TComponent van is.

[Verwijderd]

idd.. dank je. dat is een goede. Alleen hoe kun je daar achter komen?

[Verwijderd]

Zo:

code:

procedure CheckField(AControl: TControl);
begin
  if AControl is TEdit then 
  begin
    { Doe iets }
  end else if AControl is TRadioButton then
  begin
    { Doe iets }
  end
  [..]
end;

[Verwijderd]

Thankx difool

[curry684]

Kun je in Delphi niet gewoon overloaden?

Dus iets in de richting van (de C++ way):

code:

CheckField(TCustomEdit* p_Control, const AnsiString &p_Value);
CheckField(TCustomComboBox* p_Control, const AnsiString &p_Value);
etc.

Tevens wordt de Text property als protected geintroduceerd in TControl, en je kunt dus ook gewoon 1 CheckField functie maken die een TControl slikt, moet je 'm alleen binnen de functie even vies-casten naar een TEdit of ander control waarin Text public is.

* curry684 kent geen Object Pascal en weet dus niet in hoeverre deze 2 mogelijkheden toepasbaar zijn...

[whoami]

Je kunt in dit geval gebruik maken van RTTI. Run Time Type Information.

Je maakt in uw functie een parameter van het type TObject en dan kun je gaan checken welk type control het is.

Edit: Zoals DiFool dus eigenlijk al eerder vermeldde...

[whoami]

Op zaterdag 26 januari 2002 16:57 schreef curry684 het volgende:
Kun je in Delphi niet gewoon overloaden?

Dus iets in de richting van (de C++ way):

code:

CheckField(TCustomEdit* p_Control, const AnsiString &p_Value);
CheckField(TCustomComboBox* p_Control, const AnsiString &p_Value);
etc.

Tevens wordt de Text property als protected geintroduceerd in TControl, en je kunt dus ook gewoon 1 CheckField functie maken die een TControl slikt, moet je 'm alleen binnen de functie even vies-casten naar een TEdit of ander control waarin Text public is.

* curry684 kent geen Object Pascal en weet dus niet in hoeverre deze 2 mogelijkheden toepasbaar zijn...

Dit is ook een mogelijkheid, maar ik geef toch de voorkeur aan die RTTI-versie.

[curry684]

Op zaterdag 26 januari 2002 20:58 schreef whoami het volgende:
Je maakt in uw functie een parameter van het type TObject en dan kun je gaan checken welk type control het is.

Fatsoenlijke type-safety vereist dan sowieso dat je een TControl als parameter vereist daar dit de base-class is voor alle visual controls.

Om deze reden wees ik ook op het feit dat 'Text' protected is in TControl: de oplossing om 'm vervolgens richting public te casten is dan wel gruwelijk vies, maar ook 100% veilig en generiek, terwijl je met de RTTI oplossing niet voorbereid bent op nieuwe en/of externe controls.

[addition]
Schoot me net wat te binnen en heb ff geverifieerd: als je die vies-cast niet wil doen kun je ook GetTextBuf en GetTextLen gebruiken, deze zijn wel public in TControl.

Dus iets in de richting van (C++ again):

code:

void CheckField(TControl* p_Control, const AnsiString &p_Value)
{
AnsiString   l_Text;

// Set the string buffer to correct length and retrieve contents
l_Text.SetLength(p_Control->GetTextLen());
p_Control->GetTextBuf(l_Text.c_str(), l_Text.Length());

// Do whatever you want here
}

[whoami]

Op zaterdag 26 januari 2002 22:33 schreef curry684 het volgende:

Fatsoenlijke type-safety vereist dan sowieso dat je een TControl als parameter vereist daar dit de base-class is voor alle visual controls.

Ja, my mistake.

[MaxxRide]

Ik denk dat het niet verstandig is om met de Text property gaat werken. Als je dit doet bij een checkbox dan gaat dit volgens mij goed mis.

[curry684]

Op zondag 27 januari 2002 13:36 schreef Pinda het volgende:
Ik denk dat het niet verstandig is om met de Text property gaat werken. Als je dit doet bij een checkbox dan gaat dit volgens mij goed mis.

Geen idee, ik gebruik zelf meestal ingekochte controls van DevExpress die netjes 'True' en 'False' in Text geven voor checkboxes e.d. Geen idee eigenlijk of standaard VCL-checkboxes dat ook doen.

Niet dat ik er rekening mee had gehouden: in zijn originele vraag helemaal bovenin is de 2e parameter van CheckField namelijk toch een AnsiString, dus dan zou dat sowieso niet opgaan, en zou je toch moeten overloaden

[MaxxRide]

Of je cast in je CASE de boel dan naar een integer
if itemindex = intToStr(Stringetje).

Trouwens als ik kijk in de Delphi help dan zie ik bij
TComponent geen Text prop staan.

[Verwijderd]

Bedankt mensen!!! ik ga voor de case.. het is maar een simpele app.

T

[MaxxRide]

Graag gedaan

[curry684]

Op zondag 27 januari 2002 15:09 schreef Pinda het volgende:
Of je cast in je CASE de boel dan naar een integer
if itemindex = intToStr(Stringetje).

Da's a) geen cast en b) verkeerd om

Trouwens als ik kijk in de Delphi help dan zie ik bij
TComponent geen Text prop staan.

Daarom zei ik ook TControl en niet TComponent... TComponent is de base class voor alle componenten die binnen een form gebruikt kunnen worden en dus (vooral) een Owner property introduceert. TTimer is bijvoorbeeld direct van TComponent afgeleid.

TControl is afgeleid van TComponent en introduceert de properties voor actieve form-elementen: Left, Top, Handle, Text, OnClick, OnMouseOver etc. etc. etc.

[MaxxRide]

Kun je in Delphi niet gewoon overloaden?

Dit kan in Delphi zeker wel, met de overload en reintroduce directive dacht ik. (Late reactie ik weet het, maar ik dacht dit moet toch maar even.)

Da's a) geen cast en b) verkeerd om

a) je hebt gelijk, maar hoe zou je het dan willen noemen, je cast mbv een functie toch het ene type in het andere type?
b) je hebt (alweer) gelijk

En ik las zomaar over TControl heen

Verder kan deze text property de label of de text omvatten aan de hand van het type control... Bijvoorbeeld bij een TLabel is Text gelijk aan Caption (de protected text is met de property Caption te benaderen). Bij een edit is dit echter de editable text.

Wat ik nog niet begrijp is hoe je de propetected variabele naar een public variabele wil omzetten??? Hiervoor moet je dus overerven?? (Dit is trouwens ook geen casten )

edit:

kwooten ging niet goed

[Verwijderd]

protected -> public

code:

type
  THack = class(TControl);
begin
  ShowMessage(THack(AControl).Text);
end;

[MaxxRide]

Ik zie nog steeds niet helemaal wat je hier bedoeld. Een protected is alleen vanuit de class zelf of een overervende class te benaderen...

Is de functie/procedure die je laat zien in THack ofzo?
Je cast nu toch AControl naar THack, maar volgens mij kun je dan nog steeds niet vanbuiten het text attribuut benaderen.

Het text attribuut is trouwens dus standaard via Delphi te benaderen via de property Label of TExt afhankelijk van het component.

Text heeft dus zoiezo geen zin (maar daar waren we al uit). Ik ben nu alleen nog benieuwd hoe je die protected naar een public cast....

of maak je een nieuw text attribuut aan in THack, dan kan het denk ik wel.

[Verwijderd]

Op maandag 28 januari 2002 15:25 schreef Pinda het volgende:
Ik zie nog steeds niet helemaal wat je hier bedoeld. Een protected is alleen vanuit de class zelf of een overervende class te benaderen...

Effe knippen en plakken:

A protected member is visible anywhere in the module where its class is declared and from any descendant class, regardless of the module where the descendant class appears.

Dus de protected properties van THack = TControl zijn bereikbaar in de unit waarin THack wordt gedefinieerd.

Dit is een vrij gebruikelijke truc, het type wordt meestal THack genoemd; staat stoer

[MaxxRide]

Dat is wel een erg smerige truc. Ga ik zelf dus ook niet gebruiken denk ik..... Maar ik ga ehm wel een keer testen

[Verwijderd]

Mwah, smerig; wordt ook in de VCL source gebruikt

Kijk maar in bv VCLCom:

code:

type
  TComponentProtectedAccess = class(TComponent);

Ze noemen het alleen wat anders...

[MaxxRide]

Goh zouden er daarom van die discussies zijn of Delphi wel Object georienteerd is???

MAar jij vind dat omdat Borland het doet jij het zelf ook kan doen?

[curry684]

Op maandag 28 januari 2002 15:25 schreef Pinda het volgende:
Ik zie nog steeds niet helemaal wat je hier bedoeld. Een protected is alleen vanuit de class zelf of een overervende class te benaderen...

De grap zit 'm erin dat de property Text in TControl protected wordt geintroduceerd, maar bijvoorbeeld in TEdit tot public wordt 'gepromote'. Dus als je dan een TControl cast naar een TEdit kun je spontaan (omdat je plots een TEdit aanspreekt) wel bij de variabele. Dit is veilig omdat de vtable feitelijk wel vanaf TControl de goede posities bevat, maar alleen de visibility beperkt is.

Ennuh, met een functie van type A naar type B gaan is 'converteren', niet 'casten'. Casten houdt in dat je de compiler tijdelijk opdraagt een variabele van type A als type B te beschouwen, er vindt geen feitelijke conversie plaats tenzij er een impliciete mogelijkheid is.

[Verwijderd]

Pinda:
Dat is wel een erg smerige truc.

Ok, nu echt smerig werk:

code:

type
  THack = class(TStrings)
  public
    FList: PStringItemList;
    FCount: Integer;
    FCapacity: Integer;
  end;

procedure TForm1.Button1Click(Sender: TObject);
var
  List1, List2: TStringList;
  L1, L2: THack;
begin
  List1 := TStringList.Create;
  List2 := TStringList.Create;
  try
    List1.Add('Hoi');
    List1.Add('Hoi2');
    L1 := THack(List1);
    L2 := THack(List2);
    L2.FList := L1.FList;
    L2.FCount := L1.FCount;
    L2.FCapacity := L1.FCapacity;
    L1.FList := nil;
    L1.FCount := 0;
    L1.FCapacity := 0;
    ShowMessage(List2[0]);
    ShowMessage(List2[1]);
  finally
    List1.Free;
    List2.Free;
  end;
end;

Accessing private methods

[MaxxRide]

Ik had in de delphi help al gezien dat het ook met privates kon YEGH....
Tijd voor een brief naar Borland

[curry684]

Op dinsdag 29 januari 2002 13:48 schreef Pinda het volgende:
Ik had in de delphi help al gezien dat het ook met privates kon YEGH....
Tijd voor een brief naar Borland

Als je bij een C++ lib in de headers alle private-markers vervangt door public heb je hetzelfde resultaat hoor, en werkt de lib nog perfect. Meer een zaak van 'goed vertrouwen' dan een bug in Delphi of C++.

[MaxxRide]

In dat geval maak je een attribuut echt public. Zet je ze in het private gedeelte dan doe je dit meestal met een goede reden. Ik denk hier voornamelijk aan Data-Shielding.

[Verwijderd]

Door het toestaan van unchecked typecasts kun je dus overal bij.

Borland had alleen checked typecasts dmv 'as' kunnen laten toestaan, maar dan had je mbv pointers denk ik nog wel wat kunnen verzinnen om dat te omzeilen.

Daarbij zal er ook nog wel een performance verschil zijn tussen checked en unchecked typecasts.

En tenslotte kan ik me niet echt een nuttige toepassing voor het benaderen van private vars voorstellen; als dat nodig is dan zit de class gewoon niet goed in elkaar.

[MaxxRide]

en dat laatste geldt natuurlijk net zo goed voor protected vars.

Maar met pointers of evt een smerig stukje assembler kom je overal...

[curry684]

Op dinsdag 29 januari 2002 22:31 schreef Pinda het volgende:
In dat geval maak je een attribuut echt public. Zet je ze in het private gedeelte dan doe je dit meestal met een goede reden. Ik denk hier voornamelijk aan Data-Shielding.

Ik doelde vooral op ingekochte en/of externe libraries, en dan niet zozeer als nuttige toepassing maar als illustratie dat C++ op dit punt net zo lek is als Delphi.

Het zou pas veilig zijn als public/protected/private state meegemangled zou worden in de functienaam in een lib.

[MaxxRide]

MAar is dit alleen bij Borland C++ het geval of ook bij bijvoorbeeld bij GCC???


Maar ik begrijp je punt....