[Delphi] Caption Form elementen aanpassen in andere Unit

[Pieth]

Voor een Delphi projectje maak ik gebruik van een .ini bestand waar wat language instellingen in staan. Door het selecteren van een taal in het menu worden de Captions van verschillende Form elementen (Labels, Groupboxes, etc) aangepast. Zolang ik de code hiervoor gewoon in mijn mainunit hou is er niks aan de hand en werkt het perfect.

Echter, ik wil een aparte Unit voor alle I/O code dus ook om de taal instellingen te wijzigen.
Ik dacht, gewoon een procedure in de nieuwe Unit aanmaken en deze procedure in mijn mainunit aanroepen met een pointer naar mijn Form. Maar helaas dat werkt dus niet.

Even wat code ter verduidelijking:

Uit mainunit:

code:

LoadLanguageFile(Form1: TForm);

Uit IO.pas:

Delphi:

unit IO;

interface

uses  inifiles, Forms, Classes, SysUtils, StdCtrls;

implementation

procedure LoadLanguageFile(Form1: TForm);
var
  IniFile : TIniFile;
  LastLang : String;
begin
  IniFile := TIniFile.Create(extractfilepath (application.ExeName) + 'language.ini');
  
  // Get the language
  LastLang := IniFile.ReadString('Language','Last','NL');
  
  Form1.GroupBox1.Caption := IniFile.ReadString(LastLang,'Box1','Oplosser');

  // Set Labels, Radiobuttons, Checkboxes and Buttons to correct language
  Form1.Label1.Caption := IniFile.ReadString(LastLang,'Label1','Taal bestand niet gevonden.');

  IniFile.Free;
end;

end.

Errors:
[Error] IO.pas(19): Undeclared identifier: 'GroupBox1'
[Error] IO.pas(22): Undeclared identifier: 'Label1'

Maak vast en zeker ergens een achterlijke fout, maar zie het zelf niet.

[ Voor 0% gewijzigd door een moderator op 30-10-2007 22:19 . Reden: code tags aangepast. sytax highlighting ftw \0/ ]

[RobIII]

edit:
anders ben ik even te lang uit Delphi

[ Voor 110% gewijzigd door RobIII op 30-10-2007 22:20 ]

[Creepy]

Een TForm is de superclass van je daadwerkelijke form, die bevat geen andere elementen. Je echte Form1 is zeer waarschijnlijk van het type TForm1, en dat type moet je dan ook meegeven als je direct items op het meegegeven form wilt kunnen benaderen.

[Pieth]

Je hebt gelijk:

Delphi:

type
  TForm1 = class(TForm)
    GroupBox1: TGroupBox;
    Label1: TLabel;
end;

var
  Form1: TForm1;

procedure TForm1.FormCreate(Sender: TObject);
begin
  LoadLanguageFile(Form1: TForm1 );
end;

Maar als ik hem zoals hierboven meegeef, dan geeft hij aan dat hij TForm1 niet kent (wat vrij logisch is).

[ Voor 0% gewijzigd door een moderator op 30-10-2007 22:19 . Reden: code tags aangepast. sytax highlighting ftw \0/ ]

[Reptile209]

Pieth schreef op dinsdag 30 oktober 2007 @ 22:09:
Je hebt gelijk:

Delphi:

type
  TForm1 = class(TForm)
    GroupBox1: TGroupBox;
    Label1: TLabel;
end;

var
  Form1: TForm1;

procedure TForm1.FormCreate(Sender: TObject);
begin
  LoadLanguageFile(Form1: TForm1 );
end;

Maar als ik hem zoals hierboven meegeef, dan geeft hij aan dat hij TForm1 niet kent (wat vrij logisch is).

Delphi:

begin
  LoadLanguageFile(Form1);  // Zonder ": TForm1" dus
end;

Of geeft hij de fout in een andere regel

[Pieth]

Mja, was misschien wel handig geweest om te zeggen waar:

[Error] IO.pas(7): Undeclared identifier: 'TForm1'

Dat is dus in mijn tweede unit, bij de declaratie van de procedure:

Delphi:

unit IO;

interface

uses  inifiles, Forms, Classes, SysUtils, StdCtrls;

procedure LoadLanguageFile(Form2: TForm1);

implementation

procedure LoadLanguageFile(Form2: TForm1);
var
  IniFile : TIniFile;
  LastLang : String;
begin
  IniFile := TIniFile.Create(extractfilepath (application.ExeName) + 'language.ini');

  // Get the language
  LastLang := IniFile.ReadString('Language','Last','NL');

  Form2.GroupBox1.Caption := IniFile.ReadString(LastLang,'Box1','Oplosser');

  // Set Labels, Radiobuttons, Checkboxes and Buttons to correct language
  Form2.Label1.Caption := IniFile.ReadString(LastLang,'Label1','Taal bestand niet gevonden.');

  IniFile.Free;
end;

end.

[Bergen]

Delphi:

procedure LoadLanguageFile(Form1: TForm);

Hmm, geef je op die manier wel een echte pointer mee? Dit zou wel moeten werken denk ik:

Delphi:

unit IO;

interface

uses  inifiles, Forms, Classes, SysUtils, StdCtrls;

type
  PForm = ^TForm; // Pointer naar een TForm

implementation

procedure LoadLanguageFile(Form1: PForm); // PForm ipv een TForm
(etcetera)

En dan bij de aanroep een pointer meegeven:

Delphi:

procedure TForm1.FormCreate(Sender: TObject);
begin
  LoadLanguageFile(@Form1); // Let op de @
end;

[edit]
Hmm even getest maar dat werkt natuurlijk niet. De reference wel maar het is een pointer naar het type TForm en daar zitten niet die objecten in die jij wilt gebruiken... Een oplossing zou iig zijn om een pointer naar die specifieke GroupBox en Label mee te geven en dan in IO.pas een PGroupBox en PLabel aan te maken. Dat werkt sowieso, maarja stel dat je 20 objecten zou willen aanspreken dan is 't niet echt handig.

In dat geval zou je de declaratie van TForm1 in een aparte unit moeten stoppen, inclusief een PForm1 = ^TForm1 en dan vanuit Unit1.pas en IO.pas die unit bij de uses moeten zetten. Dan kennen zowel Unit1.pas als IO.pas die TForm1 en kun je alles aanspreken. Zo zou ik het denk ik oplossen.

[edit2]
Ohja, Form1 is al een pointer natuurlijk. Er hoeft helemaal geen PForm aangemaakt te worden, dat wordt een dubbele pointer. Never mind. Oh well.

[edit3]
Ook even getest: de hele TForm1 declaratie in een losse unit zetten en in Unit1.pas alleen uses Unit2; maar dat wil niet echt werken: "Error in module Unit1: Declaration of class TForm1 is missing or incorrect." Waarom moet de declaratie van een formulier in dezelfde unit staan? Als je de class in een andere unit definieert en in de uses-clause zet zou dat toch ook moeten werken? Wat een prutser voel ik me op deze woensdagochtend...

[ Voor 57% gewijzigd door Bergen op 31-10-2007 08:05 ]

[Creepy]

Een object variabele in Delphi is altijd een pointer. Dus een TForm1 als type voor je parameter kan prima, je geeft dan echt een pointer mee.

In de unit waar je de TForm1 wilt gebruiken moet je de unit waar je TForm1 staat gedeclareerd opnemen d.m.v. een uses form1.pas o.i.d. Lijkt me niet zo moeilijk en dat mist in elk geval in de laatste voorbeeld code.

Pieth: no offence maar kennnis over classes en het gebruik van uses is redelijke basis kennis van Delphi wat in een beetje Delphi boek wordt uitgelegd. Daarnaast is het hier egenlijk de bedoeling dat je meer doet dan alleen een foutmelding geven en je code te dumpen zoals je in je laatste post doet. Ook dan verwachten we dat je (net als in een topic start) minstens aangeeft wat je zelf hebt geprobeerd.

[ Voor 19% gewijzigd door Creepy op 31-10-2007 08:56 ]

[Bergen]

Creepy schreef op woensdag 31 oktober 2007 @ 08:51:
In de unit waar je de TForm1 wilt gebruiken moet je de unit waar je TForm1 staat gedeclareerd opnemen d.m.v. een uses form1.pas o.i.d. Lijkt me niet zo moeilijk en dat mist in elk geval in de laatste voorbeeld code.

Maar dan heb je een circular reference toch?

[Pieth]

Creepy schreef op woensdag 31 oktober 2007 @ 08:51:
Pieth: no offence maar kennnis over classes en het gebruik van uses is redelijke basis kennis van Delphi wat in een beetje Delphi boek wordt uitgelegd. Daarnaast is het hier egenlijk de bedoeling dat je meer doet dan alleen een foutmelding geven en je code te dumpen zoals je in je laatste post doet. Ook dan verwachten we dat je (net als in een topic start) minstens aangeeft wat je zelf hebt geprobeerd.

I know, maar was zo druk bezig met klooien dat ik nog geen tijd heb gehad om mijn probeersellen neer te planten.

Anyways, TForm1 is gedeclareerd in de mainunit en in die mainunit wordt IO 'geused'. Op het moment dat ik mijn mainunit weer in de uses van IO zet krijg ik een error m.b.t. circular unit reference. Heb ook al gelezen over het usen in de implementation, maar daar heeft mijn declaratie van de procedure niks aan.

Normaal werk ik trouwens in C/ C++ waar je wel een hoop 'vieze' trucs uit mag halen m.b.t. pointers. Het is dat dit project in Delphi gemaakt moest worden, anders was ik er niet aan begonnen

[Creepy]

Bergen schreef op woensdag 31 oktober 2007 @ 09:10:
[...]
Maar dan heb je een circular reference toch?

Ik zat al op deze opmerking te wachten

Nee, want mocht je iets in form1.pas nodig hebben van die andere unit dan zet je de uses in je implementation en niet in je interface. Alles wat in je interface deel staat is publiekelijk beschikbaar en alles wat in je implementation staat is dat niet. Je kan dus prima in unitA unitB usen en tegelijk ook andersom zolang het in minstens 1 geval maar in de implementation gebeurd en niet in de interface.

Dit is helaas een veel gemaakte fout omdat de Delphi IDE zelf altijd alles in de interface deel zet.

Pieth: haal dan die IO uit de unit waar je de error krijgt omdat je die unit al meekrijgt via een andere unit. Overigens is dit soort kennis in C++ vergelijkbaar dus ik snap je opmerking over het gebruik van C++ niet helemaal. Simpel gezegd kan je het interface deel van je unit zien als een header file en het implementation deel als je .c of .cpp file. In C++ kan je ook rare zaken krijgen als je twee keer dezelfde header file include, tenzij je #IFDEF guards gebruikt.

[ Voor 37% gewijzigd door Creepy op 31-10-2007 09:18 ]

[Pieth]

Creepy schreef op woensdag 31 oktober 2007 @ 09:14:
Ik zat al op deze opmerking te wachten

Nee, want mocht je iets in form1.pas nodig hebben van die andere unit dan zet je de uses in je implementation en niet in je interface. Alles wat in je interface deel staat is publiekelijk beschikbaar en alles wat in je implementation staat is dat niet. Je kan dus prima in unitA unitB uses en tegelijk ook andersom zolang het in minstens 1 geval maar in de implementation gebeurd en niet in de interface.

Dit is helaas een veel gemaakte fout omdat de Delphi IDE zelf altijd alles in de interface deel zet.

Uiteraard... ik maar proberen om mainunit in de implementation van IO te usen. Waarom heb ik er niet aan gedacht om IO te usen in de implentation van de mainunit...

[Bergen]

Aha, ik had me al eens afgevraagd wat het verschil was. Dank voor deze verduidelijking.

[Pieth]

Creepy schreef op woensdag 31 oktober 2007 @ 09:14:
[...]
Pieth: haal dan die IO uit de unit waar je de error krijgt omdat je die unit al meekrijgt via een andere unit. Overigens is dit soort kennis in C++ vergelijkbaar dus ik snap je opmerking over het gebruik van C++ niet helemaal. Simpel gezegd kan je het interface deel van je unit zien als een header file en het implementation deel als je .c of .cpp file. In C++ kan je ook rare zaken krijgen als je twee keer dezelfde header file include, tenzij je #IFDEF guards gebruikt.

Kwestie van door de bomen het bos niet meer zien. Te vaak de code bekeken om de simpele dingen niet meer te zien. Denk dat ik nu maar eens ga slapen...

/slotje en bedankt

[SysRq]

Heb je verder wel in de gaten dat je op deze manier niet echt goed aan het programmeren bent?

Wat denk je dat er gebeurt als je het taal bestand nog in een ander form wilt gebruiken? Je bent dan direct verplicht om ook op dat form een groupbox1 en label1 te gebruiken. Probeer dat te voorkomen.

Ik zou in dit geval gebruik maken van de volgende code:

Delphi:

type
  TForm1 = class(TForm)
    GroupBox1: TGroupBox;
    Label1: TLabel;
  private
    procedure LoadLanguage();
end;

implementation;

uses io;

var
  Form1: TForm1;

procedure TForm1.FormCreate(Sender: TObject);
begin
  LoadLanguage();
end;

procedure TForm1.LoadLanguage;
begin
  GroupBox1.Caption := io.GetTranslation('box1');
  Label1.caption := io.GetTranslation('label');  
end;

In de IO unit kun je dan bijvoorbeeld een singleton implementatie maken, zodat je maar één keer het ini bestand hoeft in te lezen.

[Paul]

Kun je niet veel beter iets als het volgende doen:

Delphi:

unit Language;

interface

type
  TInternationalization = class
  private
    data: TList; // Of net waar je het in opslaat en een beetje performt met zoeken
  public
    constructor Create;  // als ik het goed heb moeten hier nog wat
    destructor Destroy; // keywords achter om de compiler tevreden te houden
    function GetLanguageString(Resource: String): String;
  end;

var Internationalization: TInternationalization;

implementation

constructor TInternationalization.Create()
begin
  // instantieer je data-gedoe
  // Bepaal welke taal je weer wilt geven
  // vul je data-dinges
  inherited;
end;
  
destructor Destroy()
begin
  // Geef je data weer vrij
end;

function GetLanguageString(Resource: String): String;
begin
  Result := Data.Find(Resource);
end;

end.

Delphi:

program Project1;

uses
  Language in "Language.pas";

begin
  Internationalization := TInternationalization.Create;
  try
    ...
    ...
  finally
    Internationalization.Free;
  end;
end;

end.

Delphi:

unit Form1;

uses Language;

interface

implementation
 
procedure TForm1.FormCreate(Sender: TObject);
begin
  CheckBox1.Caption := Internationalization.GetLanguageString("Form1_CheckBox1");
  Label1.Caption := Internationalization.GetLanguageString("Form1_Label1");
end;

Op die manier hoeft je Internationalization-class (jouw IO) geen weet te hebben van de rest van het programma, en dus geen honderden forms in zijn uses te hebben etc.

Edit: Wat mijn bovenbuurman dus ook zegt

[SysRq]

Paul Nieuwkamp \o/

En een singleton implementatie ziet er dan zo uit:

Delphi:

unit Language;

interface

type
  TInternationalization = class
  private
    data: TList; // Of net waar je het in opslaat en een beetje performt met zoeken
  public
    constructor Create;  // als ik het goed heb moeten hier nog wat
    destructor Destroy; // keywords achter om de compiler tevreden te houden
    function GetLanguageString(Resource: String): String;
  end;

implementation

var
  internalInternationalization: TInternationalization

constructor TInternationalization.Create()
begin
  // instantieer je data-gedoe
  // Bepaal welke taal je weer wilt geven
  // vul je data-dinges
  inherited;
end;
  
destructor Destroy()
begin
  // Geef je data weer vrij
end;

function GetLanguageString(Resource: String): String;
begin
  if not (assigned(internalInternationalization)) then
  begin
    internalInternationalization := TInternationalization.create();
    // zet eventuele properties
  end;
  Result := internalInternationalization.Data.Find(Resource);
end;

finalization

if assigned(internalInternationalization) then
  internalInternationalization.free

end.

En nog een

[Paul]

SysRq schreef op woensdag 31 oktober 2007 @ 09:39:
En nog een

Mis je daar niet nog een stuk?

Volgens mij compiled dit ook niet clean: data is private en TInternationalization.GetLanguageString wordt nergens ingevuld

[SysRq]

Hmm, daar had ik inderdaad wel wat tekst neergezet.

Er moeten natuurlijk nog een aantal aanpassingen gemaakt worden. Je kunt inderdaad niet bij data (volgens de codingguidelines moet dat eigenlijk fData heten ) maar daarvoor zou je een getData functie kunnen hebben. GetLanguageString moet dan een losse functie worden, niet ingebed in de TInternationalization classe.

[GabberKooij]

Ik gebruik in mijn prive projecten vaak gnugettext voor Delphi. Dat werkt zo ongeveer op de hier eerder beschreven manier.

GNU gettext for Delphi

is wel wat ingewikkelder om op te zetten, dus voor een klein projectje kan ik me voorstellen dat je het liever zelf implementeerd.

[LordLarry]

Delphi zelf heeft ook ingebouwde ondersteuning voor i18n. Multilizer is ook een goed product die hetzelfde effect bereikt.

[Verwijderd]

Wij doen het met 2 componenten.
(we hebben eigen tool gemaakt voor vertalingen).

Een hoofd component (1x per applicatie).
Een form component (1x per form).

Hoofdcomponent gooi je op bv een datamodule of je mainform. Werkt idd via singleton.
Form component gooi je op iedere form, en registereert zich via de aanwezige singleton, bij het hoofdcomponent.

Zodra je hje taal veranderd instelling in hoofdcomponent, wordt de interne messagelist vertaald en alle gekoppelde forms krijgen een signaal van hey, je moet gaan vertalen.

Met messages bedoel ik zaken die niet als standaard component property beschikbaar zin,dus losse strings etc.