Ab wann hat ein Fenster ein Handle?

[Alaitoc]

Naja wozu sollst du ein Handle erstellen, wenn dir das Formular eines bereit stellt?
Und ich will dir nicht meine Meinung aufzwingen, jedoch halte "ich" das halt für sinnvoller und gebe es nur kund ;)

Also hier mal deine Möglichkeiten die ich dir hier nun biete:

1. Im Public Teil deines Formulars einfügen:

Delphi-Quellcode:

    
  procedure AfterConstruction; override;

Und dort die Anweisungen ausführen, die du sonst im Konstruktor ausgeführt hättest.
Da ab dann das Handle erstellt sein sollte.

2. HandleNeeded im Konstruktor ausführen und danach deine Anweisungen ausführen. HandleNeeded überprüft halt
ob das Handle erstellt ist und wenn nicht wird es erstellt.

3. HandleNeeded im Getter des Handels implementieren, also den Getter überschreiben und das Handle dann zurückgeben.
( siehe Beispiel von Himitsu ). Also jedes Mal wenn du auf das Handle-Property zugreifst, wird überprüft ob das Handle existiert.
( per HandleNeeded )

Edit: Achja wichtig ist beim AfterConstruction das du dort inherited; aufrufst, da laut DelphiHilfe dort ein Flag gesetzt wird.

MfG Alaitoc

[R2009]

OK,
AfterConstruction ist eine Methode von tobject, hatte ich übersehen.

Danke Alaitoc!

Grüsse
Rainer

[MarioM.]

Zitat:

Zitat von R2009

Zum Hintergrund:
Wir hatten die Sprachabhängigen Texte usw immer im onactivate des entsprechenden Fensters geladen.
Das ganze wurde aus Performancegründen so gemacht. Unsere Fenster sind all modal.

Wolltet Ihr die Performance verschlechtern? ;)

Nee, mal im Ernst. Wo ist der Vorteil von 'Ich lade alles x-Mal' zu 'ich lade alles einmal'?
Das interessiert mich wirklich.

[R2009]

Hi Mario,

Delphi-Quellcode:

Nee, mal im Ernst. Wo ist der Vorteil von 'Ich lade alles x-Mal' zu 'ich lade alles einmal'?

Unsere Tools sind so von anderen Dingen belastet, dass es unbedingt nötig ist Zeit zu sparen.
Sei es wo es wolle. So müssen, z.B. in Echtzeit (sofern das Windoof zulässt), Statusdaten aus den Zählern und Empfängern geholt werden. Ich kann es mir einfach nicht leisten Zeit durch unnötiges laden von Sprachinformationen zu vertrödeln. Alle Daten sind mit Zeitstempeln versehen (werden im PC hinzugefügt).
Der Kunde meckert schon wenn wir 200ms hinter seinem Protokoll hinterhinken. Aus diesem Grunde wird an jeder Ecke Zeit gespart. Das ist auch der Grund für die zentral gesteuerte Botschaftsverarbeitung (uuuh was für ein Wort) die wir einführen wollen. Ob das was bringt ist eine andere Sache.
Mehr muss ich dazu wohl nicht sagen.

Grüsse
Rainer

[MarioM.]

Hallo Rainer,

danke für die Info.

Das Thema hört sich sehr interessant an. Darf ich fragen, in welcher Branche Du arbeitest? Schreibt Ihr Software für Hardware (Zähler)? Wenn ja, um was für Zähler handelt es sich da?

Gruß
Mario

[R2009]

Hi Mario,
ich arbeite bei der Elster GmbH. Wir stellen Gas, Wasser und Stromzähler her.
Ausserdem sind wir im Bereich der Rundsteuertechnik tätig.
Ich persönlich arbeite in der Entwicklungsabteilung für Stromzähler und Rundsteuertechnik.
Wir beschäftigen uns im wesentlichen mit Hitec Zählern für die Industrie und den
Haushalt. Wir sind im Moment dabei, Sichwort "Smart metering", uns mit Zählerfernauslesung zu profilieren.

Meine Tools: Lcrset, Rtsset, LTSset, TTSset, RCRset usw.
Alles Tools mit einem Sourcecode zwischen 300000 und 400000 Zeilen.
Ich arbeite bevorzugt mit D7 und RAD Studio 2007 aber auch mit den ATmel Tools für ATmega88 usw.
Dort habe ich z.B. eine Dali Schnittstelle für einen Runststeuerempfänger realisiert. (hard und Software)

Wenn du dich weiter informieren willst:
http://www.elstermesstechnik.com/

Grüsse
Rainer Unger

[himitsu]

Wenn es so zeitkritisch ist, dann würde ich nicht alles an eine Stelle verlagern,
wo es sich eventuell noch gegenseitig behindern kann.

Das Empfangen und mit Zeitstempel versehen in einen eigenständigen Thread auslagern (notfalls auch noch mit höherer Priorität)
und sobald der Zeitstempel erstmal dran ist, ist der Rest dann doch nicht mehr ganz so zeitkritisch?