Liebe Gäste des Forums
Danke, dass ihr euch hier auf dem inoffiziellen Windev-Forum umschaut. Hier werden Tipps und Hinweise zu der von PC-Soft angebotenen Software Windev besprochen.
Windev ist eine leistungsstarke, sehr umfangreiche Entwicklersoftware für Webseiten, Handys und Rechner verschiedener Betriebssysteme. Mehr unter http://www.windev.com

Reihenfolge der Initialisierung ...

Wie ich gerade feststellen musste, reagieren Upper() und Lower() anders als erwartet (aus xBase Sicht) ... hierfür gibt es eine andere Funktion. Hier sollen solche allgemeinen Themen behandelt werden.
Antworten
Benutzeravatar
BRANDELH
Site Admin
Beiträge: 199
Registriert: 30. Juni 2010, 14:31
Wohnort: Germersheim
Kontaktdaten:

Reihenfolge der Initialisierung ...

Beitrag von BRANDELH » 19. Juli 2011, 07:53

Hallo,

ich habe wie von Xbase++ gewöhnt, in der Initialisierung des Hauptfensters meine globalen Variablen und Vorgaben erledigt.
Die Variablen für das ganze Programm, waren hier schon mal falsch, dafür gibt es das "P"rojekt als solches.
Also "P Name des Projekts" ...

Hierbei fülle ich ein Array, das Infos für eine/mehrere Comboboxen enthält und wundere mich, dass die leer bleiben ...
Mit TRACE() habe ich nun herausgefunden, dass die Initialisierung nicht wie erwartet zuerst das Fenster initialisiert, sondern so vorgeht:

1. "P Name von Projekt" == Initialisierung von der Anwendung, zuerst alle Globalen Infos für das gesamte Programm. OK.
2. "Globals von Win_Main" == Globale Variablen dieses Fenster definieren, OK ...
3. "INI von Combobox" ... :exclamation: die anderen Controls irgendwo dazwischen ...
4. "INI von EDT_Controls" ... :exclamation:
5. "INI von Win_Main" ... :exclamation: das hatte ich vorher erwartet, muss man sich merken !!!

Herbert
Site Admin
Beiträge: 386
Registriert: 23. Februar 2010, 08:06
Wohnort: Langenthal, Schweiz
Kontaktdaten:

Re: Reihenfolge der Initialisierung ...

Beitrag von Herbert » 19. Juli 2011, 12:54

Dass das ini des Mainfensters zuletzt kommt, hat seinen Sinn. Jedes Element, z.B. Listboxen, können innerhalb der eigenen Definition mit Informationen gefüllt werden.
Von da her gesehen ist das einzig Sinnvolle, zuerst die Elemente initialisieren zu lassen, um anschliessend im Initalisiserungsteil irgendwelchen Code auszuführen, welcher u.a. höchstwahrscheinlich mit dem Inhalt der Elemente auskommen muss.
Zu den globalen Variablen gehören auch die Uebergabeparameter. Daher müssen diese vor allen anderen Definitionen der Elemente erscheinen. Auch hier, um die Definition und Eigenschaften in deren Abhängigkeit bringen zu können.

Du triffst hier eine der Unklarheiten aus Xbase, welche einerseits als Vorteil erscheinen aber andererseits zu Chaos führen können und der Transparenz des Codes zuwider laufen.

Benutzeravatar
BRANDELH
Site Admin
Beiträge: 199
Registriert: 30. Juni 2010, 14:31
Wohnort: Germersheim
Kontaktdaten:

Re: Reihenfolge der Initialisierung ...

Beitrag von BRANDELH » 19. Juli 2011, 13:12

Herbert hat geschrieben:Dass das ini des Mainfensters zuletzt kommt, hat seinen Sinn...
ich wollte nicht sagen, dass dies "unsinnig" ist, es ist halt nur "anders" und man muss es wissen ;-)
Herbert hat geschrieben:Du triffst hier eine der Unklarheiten aus Xbase, welche einerseits als Vorteil erscheinen aber andererseits zu Chaos führen können und der Transparenz des Codes zuwider laufen.
Also UNKLAR ist die Xbase++ Regelung nicht, dort ist - wie hier auch - die Reihenfolge genau festgelegt, allerdings sind die Bezeichnungen anders.

Herbert
Site Admin
Beiträge: 386
Registriert: 23. Februar 2010, 08:06
Wohnort: Langenthal, Schweiz
Kontaktdaten:

Re: Reihenfolge der Initialisierung ...

Beitrag von Herbert » 20. Juli 2011, 19:42

BRANDELH hat geschrieben:Also UNKLAR ist die Xbase++ Regelung nicht, dort ist - wie hier auch - die Reihenfolge genau festgelegt, allerdings sind die Bezeichnungen anders.
Nun, ich war etwas unklar. Du kannst in XBase prozedural (was ich oft sehe) oder in Klassen programmieren.
Prozedural musst du zuerst die Variablen definieren aber dann ist dir freigestellt, wann du innerhalb des Codes die Elemente und deren Eigenschaften definierst. Und dies ist Chaos.
Als Klasse (ich rede einfach von GUI-Fenstern) musst du immerhin zuerst das Init (mit der Vergabe der Controls und deren Eigenschaften) und anschliessend das Create definieren. Im Create setzt du ev. aufgrund von Parametern Bedingungen und Anzeigeeigenschaften. Die Methoden und Variablen der Klasse letztendlich umrahmen die Eigenschaften beim späteren Einsatz.

In Windev sehe ich den grossen Vorteil, dass überall dieselbe Struktur vorgegeben ist - mit den stets gleichen Regeln, die - mit bestem Dank für den Hinweis von dir - wichtig sind, dass deren Reihenfolge bekannt ist.
Und ja, die Benennung der Dinge ist manchmal verwirrlich.

Antworten