D11 Caption bei TcxTabSheet verschwindet beim kompilieren.

[Kostas]

Hallo Zusammen,

zunächst ein gutes und gesundes neues Jahr an alle.

Das Problem dass Eigenschaften verloren gehen, ist nicht nur TabSheet sondern auch anderen Elementen. Aktuell in einer TFDQuery verschwindet das property LookupDataSet.

Aktueller Fall in einem anderen kleinen Projekt. Auch hier ist DevExpress im Einsatz aber ich glaube das hat damit nichts zu tun!

-Öffne das Projekt, kompiliere, starte, alles ok.
-Öffne die Form in Delphi, auf der Form ist ein TabControl. Wechsle NUR das Tab, kompiliere, starte, Delphi zeigt exception

Code:

"Lookup-Information für Feld 'RollenText' ist unvollständig." Manchmal reciht es auch NUR die Form zu öffnen ohne irgend eine Änderung und das Prop verschwindet.

-schaue im Object Inspektor, prop LookupDataSet ist nicht gesetzt. Öffne das .dfm in Delphi als Text fehlt es hier.
-Beende das Projekt ohne speichern.
-Öffne das .dfm in NotePad++ das Prop ist gesetzt.
-Starte Delphi, öffne diesmal die Form nicht und kompiliere das gesamte Projekt neu, alles ok.

Das macht mir große sorgen wenn ich mich nicht darauf verlassen kann. Was kommt als nächstens.

[Edit]
Jetzt ist mir folgendes aufgefallen:
Das DataSet befindet sich nicht auf der Form sondern auf ein DataModul.
Wenn ich das DataModul zuerst öffne und dann die Form, bleibt das Prop erhalten.
Auf der Form sind jedoch weitere Elemente die auf Elemente des gleichen DataModuls zugreifen die eben nicht verschwinden. Es ist also nicht nachvollziehbar warum genau dieses prop verschwindet!


Gruß Kostas

[Kostas]

Hallo Zusammen,

das Problem ist noch viel gravierender. Jetzt auch bei FDQuery.

Aktuell hatte ich den Fall dass in einer FDQuery aus einem, LookUpField das LookupKeyField rausgeflogen ist.
Ich habe die Form NUR geöffnet, einen Reiter gewechselt und neu kompiliert. Ausführen kommt dann natürlich eine Exception. Ich muss jetzt jede Form über GIT vergleichen was sich genau geändert hat. Das ist wirklich nicht mehr lustig.

Hat sonst niemand dieses Problem?

Gruß Kostas

[himitsu]

Öffne mal das TDM1 im Designer
und dann schau, ob alles da bleibt.

[Kostas]

Wenn ich das TDM1 über den Designer als Text(nicht Form) öffne, fehlen die Eigenschaften. Das .dfm File wird also neu geschrieben und dabei werden Eigenschaften völlig Wild entfernt. Derzeit ist es mir NUR aufgefallen in TabPages und FDQuerys. Wobei ich den FDQuery Fall jetzt neu dazu bekommen habe. Ich muss jetzt viel öfters einchecken damit ich die .dfms kontrollieren kann. Gerade eben schon wieder.

[himitsu]

Ähhhh wie jetzt, DM1 ist die "aktuelle" Form, also jene, in welcher auch die Property verschwinden?
Klang mehr nach einem DatenModul.

[Kostas]

Sorry, beides. Es ist nicht so dass nur der Eigenschaftswert fehlt, es fehlt die Eigenschaft samt Wert aus der .dfm Dabei.

Ich habe das in Forms und auch in Datamoduls. Ich kann kein Muster erkennen unter welchen Umständen das passiert. Es ist auch nicht so dass ich das Control anfassen muss. Ich öffne die Form oder das Datamodul und bei der nächsten Änderung wird die Form gespeichert. Dabei verschwinden die Eigenschaften.

Interessant ist folgendes:
Ich habe das Projekt heute mehrfach kompiliert. Bei einem Kompiliervorgang bei dem ich an der Form im Bild nichts verändert hatte ist mit zur Laufzeit aufgefallen dass das TabPage kein Caption hat. Ich beende die Anwendung und schaue mit den Tab an. Das Caption am Tab ist zu sehen wie im Bild. Dann schaue ich im Objektinspektor und sehe dass das Caption fehlt. Im Designer wechsle ich auf Textmodus, suche das Control und sehe dass die Eigenschaft Caption fehlt. Ich trage im Designer "Details" ein und speichere die Form. Wechsle wieder in Textmodus und die Eigenschaft samt Wert ist da. Ich habe in D11.1 CnPack installiert, ansonsten keine IDE Erweiterungen.

[himitsu]

Bei unseren Datenmodulen sind die auch nochmal als DesigntimePackage geladen (um damit auch im Designer eine Datenverbindung zu haben)

Da gab es früher auch öfters Probleme, wenn der Name nicht aufgelöst werden konnte.
Daher hatten Viele dann immer das/die Datenmodule geöffnet (wobei auch das nicht immer zu 100% half)

Inzwischen hab ich mich in die Namensauflösung reingehängt und wenn der ModulName kommt, dann gebe ich explizit das interne Datenmodul, anstatt aus der eventuell geöffneten Unit.
Das Datenmodul kann man dann auch in Ruhe bearbeiten und die Unit auch schließen (wenn dort eine offene Form am Datenmodul oder eine FormAbleitung dran hängt, bekommt man diese Units nicht mehr geschlossen)

Im Designer ist es nicht ganz Spaßig, aber man kann sich notfalls auch via Event über ein DesignTimePackage oder mit dem Debugger (die IDE debuggen) in den TReader, bzw. hier den TWriter reinhängen und schauen was der macht.

[Kostas]

:-) Ich habe nicht alles verstanden was du geschrieben hast, aber derart gravierende Probleme hatte ich bisher noch nie. Es ist absolut gefährlich wenn man sich nicht darauf verlassen kann was man zur Designzeit eingestellt hat. Ich trau mich kaum eine Form zu ändern. Das kann es doch nicht sein. Für mich ist das ein absolutes Alarmzeichen. Dieses Projekt hat über 300 Forms. Ich kann unmöglich anzweifeln ob die Eigenschaften die zur Designzeit gesetzt wurden, noch gesetzt sind, und auf keinen Fall ist es tolerierbar wenn Eigenschaften in FDQuerys verloren gehen. Bisher hatte ich nur einen Fall. Wenn ich mir vorstelle, eine Master-Detail Beziehung würde verloren gehen, das merkst man halt nicht beim Kompilieren sondern erst im produktiven Umfeld beim Kunden. All die Jahre habe ich mit Delphi in einer VMWare-Workstation gearbeitet mit Desktop OS. Seit Delphi 10 haben wir umgestellt auf VMWare Esxi und in den VMs laufen Windows 2019 Datacenter Server. Das Projekt wurde vor etwa zwei Jahre auf den Server verschoben und lief unter Delphi 10 problemfrei. Auch zu Anfangs lief es unter Delphi 11 problemfrei. Seit wann genau die Probleme da sind konnte ich nicht ausmachen. Ich mache mir wirklich große sorgen. An die Server kann es fast nicht liegen und Anwenderfehler können es fast auch nicht sein da wie gesagt NICHT der Eigenschaftswert fehlt sondern die gesamte Eigenschaft samt Wert. Wenn die Server ein Problem hätten, dann würde vielleicht eine Änderung nicht gespeichert werden. Aber was kann die Ursache sein dass Eigenschaften verschwinden? Aus meiner Sicht nur die IDE.

[himitsu]

Zitat:

Es ist absolut gefährlich wenn man sich nicht darauf verlassen kann was man zur Designzeit eingestellt hat. Ich trau mich kaum eine Form zu ändern.

Dafür/Dagegen gibt es ja Versionierungstools (Git und Co.).

Wenn Property praktisch immer gesetzt sein müsen, dann kann man beim / nach dem Laden auch eine Prüfung in die Komponente einbauen.

Eine mögliche Ursache : wenn Namen/Komponenten nicht aufgelöst/ausgelesen/gefunden werden können und dann beim Speichern der Name praktisch leer ist.
Wobei ich vom XE noch kenne, dass Namen beim Speichern OK sind, ebenso manchmal beim Editieren im PropertyEditor, aber wenn der Fokus nicht im Property liegt, dann sieht es leer aus ... auch bissl blöd, wenn man ständig denkt es könnte leer sein und muß dann immer erstmal genauer reingucken

[Sinspin]

Hey,

sowas wie Caption hat ja keine Referenz zu einem Datenmodul.
Verwendest du ein Übersetzungstool?
Ich hatte den gleichen Fehler als ich in unserem Übersetzungtools die automatisch aktive Sprache neu eingestellt habe.
Anstatt, wie zu erwarten wäre, in Fällen in denen die aktive Sprache leer ist, weiter die default Sprache zu verwenden, hat es einfach die Captions/Texte/Listen alle ausgekippt.
Delphi ist dann so nett die Größe der DFM zu optimieren und schmeißt die leeren Properties ganz aus der DFM.

Deswegen, niemals ohne Versionsveraltung programmiern! Es gibt schon genug andere Gründe sich die Haare auszureißen.