ICH HASSE CLX !!!!!!!!!!!!!!!!!!!!!!!!!!
Jeden Tag entdecke ich einen neuen Bug !

Ich arbeite gerade an einem ziemlich umfangreichen Projekt und habe
schon verdammt viel Zeit investiert!

Ich hatte die Schnaps-Idee das Ding unter CLX zu entwickeln und
suche jetzt nach einem möglichst einfachen Weg, wie ich
Sourcen und Formen wieder auf VCL bekomme, ohne alles
neu zu schreiben !!
Hätte ich's doch nur gleich unter VCL entwickelt!
(*Heul-Schrei-Brüll-HaareAusreiß*)

Gibt es irgendein Tool, daß sowas automatisch kann ?

HILFEEEEE !!!

Welche Bugs hast du denn entdeckt. Vielleicht gibt es dafür einen Bugfix. Oder das Verhalten der CLX weicht einfach per Definition von dem der VCL ab.

Hallo,

ich würde mir ersteinmal eine Kopie des Projrktes machen auf der du arbeiten kannst.

Hier erzeugst du ein neues, leeres VCL Projekt und fügst alle *.PAS Dateien deines alten hinzu,
In diesen entfernst in allen USES Klauseln das Q vor den Unitnamen die eben mit einen Q beginnen.
Danach heißt es dann Kompilieren und jeden Fehler einzeln bearbeiten.

Bei neuen Produkten sind Kinderkrankheiten leider üblich und CLX ist noch immer recht neu.

Ich schätze auch, das Borland momentan alle Hände voll zu tun hat. Die müssen allein drei Teams zur Komponentenentwicklung haben, VCL, CLX und .NET. Irgendwas sagt mir, das das .NET Team auf kosten von VCL und CLX die meisten Mitarbeiter hat .

Also ich bin zwar auch schon über so manche kuriosität (Bug) gestolpert, erwarte aber auch nicht soviel Perfektion wie bei der VCL (obwohl da einige neue Komponenten wie z.B. die Action Menüs auch stark zu wünschen lassen). Deshalb läuft jedes meiner CLX Projekte unter der Rubrik "Experimentell" und in der Firma habe ich alle bemühungen die drauf drängten Projekte auschließlich als CLX zu realisieren gebremmst.
Mitlerweile bin ich aber bereit da zwei ausnahmen zu machen, bei denen ich meine, das das Risiko vertretbar ist und die Erfolgsaussichten groß sind.

Gruß
Klabautermann

Das klappt so nicht !
Das hab ich schon probiert
Wenn ich eine CLX-Unit hinzufüge und im Uses-Teil die "Q" entferne
und kompiliere, fügt er am Ende der USES Klausel alle "Q"-Units wieder hinzu und ich habe sowohl die VCL als auch die CLX Pendants drin stehen!
Halt! Ich merke gerade, ich brauch es gar nicht kompilieren, wenn ich im Editor auf eine andere Unit umblättere fügt er es schon wieder ein!
-> Wahrscheinlich ist das in den Formen hinterlegt!
-> aber die sind ja auch im Text-Format und ich kann da nichts auffälliges
finden !

Ich hab auch schon versucht, die dcu's alle zu löschen und vor dem Reinladen in den PAS-Dateien die "Q" zu entfernen! -> dann fügt
er die "Q" trotzdem beim kompilieren wieder ein !
-> kann man das Verhalten in der IDE vielleicht abschalten ?

Thanx & CU

Hy Andy,
Ich habe mich inzwischen bei Borland-Quality-Central angemeldet.
Da gibt es ein Frontend um die ganzen Postings zu durchsuchen.

-> Ich habe ALLE Bugs, die ich für Bugs gehalten haben gefunden!!
und nur für eine Handvoll gab es Work-Arounds.
In der Regel empfehlen die, die Koponente selbst neu zu entwickeln !
Das finde ich traurig!
Ich war schon zu Turbo-Pascal Zeiten ein Borland-Fan und immer zufrieden.
Es gab immer schon ein paar Bugs in Delphi (diverse OnClick oder OnEnter Ereignisse, die unter Delphi 4 bis zu 4-fach abgefeuert wurden -> wahrscheinlich wegen der Analogie zur Versionsnummer (*kicher*) etc.)
Hat mich nie groß gestört, weil man da leicht einen Workaround finden kann.

!!!!!!!!!!!!!Aber die CLX halte ich schlicht nicht für marktreif.!!!!!!!!!!!!!!!!!!


(Es gibt schon über 120(!!!) dokumentierte BUGS in der DELPHI7!!!)
-> Das sind ja Methoden wie bei Microsoft
DER KUNDE WIRD ZUM BETA-TESTER GEMACHT !!
Dann sollen die wenigstens dazuschreiben, daß unter CLX mit Problemen zu rechnen ist, dann versucht auch keiner, wichtige Applikationen mit was anderem als VCL zu entwickeln !

PS: Sorry, ist nichts gegen Dich, aber ich muß einen Abgabetermin einhalten und meine Nerven liegen gerade blank !

Neben dem entfernen der "Q"'s musst du auch alle *.frm's öffnen und die entspr. Komponentennamen anpassen, dann werden die CLX verweise auch nicht mehr hinzugefügt... So habe ich es jedenfalls auch schon einmal wieder hinbiegen können.

Du darfst auch nicht vergessen {*.clx} gegen {*.vcl} zu tauschen, sonst sind alle anderen Änderungen wirkungslos.

Es gibt nur ein paar Fehler beim anschliessenden Öffnen des Projektes, da div. Propertys und Events anders sind...

Was meinst Du mit
"Du darfst auch nicht vergessen {*.clx} gegen {*.vcl} zu tauschen, sonst sind alle anderen Änderungen wirkungslos. "????????

Außerdem noch eine Frage:
Heißen die Formen jetzt standardmäßig *.XFM oder unterscheiden sich darin die CLX/VCL Formen???

Man kann ja eigentlich die Formen konvertieren, indem man einfach im Explorer auf die *.xfm Doppel-Klickt und bei "Speichern Unter" den Typ *.DFM angibt!
-> Er speichert es aber TROTZDEM als *.XFM !!!!!

Die vcl-Forms heissen *.frm, clx -> *.frx ...das hätte ich beinahe vergessen, du musst natürlich auch die frx nach frm umbenennen, bevor du de Direktive ersetzt...

He Sorry, aber bei mir heißen die Dinger *.XFM und *.DFM
und bei einem einfachen Umbennen erklärt mir Delphi, daß die Form-Dateien nicht gefunden werden !
Ich arbeite mit Delphi7, hast du zufällig eine ältere Version, wo die noch
anders hießen ?

Und dann noch meine andere Frage von oben:
was meinst du mit
"Du darfst auch nicht vergessen {*.clx} gegen {*.vcl} zu tauschen, sonst sind alle anderen Änderungen wirkungslos. "????????

die Dateien gibt es bei mir nämlich auch nicht !!????

Thanx im Voraus

Solange in den *.pas Dateien der Forms noch {$R *.xfm} steht, versucht Delphi die *.xfm's zu öffnen. Du musst {$R *.xfm} gegen {$R *.dfm} ersetzen, dann öffnet Delphi auch die *.dfm Dateien.

Hallo,

ich stehe auch vor dem Problem, einige Projekte, die ich naiverweise als clx-Projekte anegfangen habe, zu vcl zu konvertieren. Ich habe getan:

- alle .xfm-Dateien in .dfm umbenannt
- die entsprechenden hinweises in den units {$R *.dfm} geändert
- das "uses QForms" in project1.dpr in "uses Forms" geändert

aber das Programm lässt sich nicht compilieren, die Fehlermeldung ist "Unsupported 16bit resource in File Uni1.dfm". Hilfe.. weiss jemand Rat?

Grüße
Jan

Hallo,

erstmal hoffe ich das du auf einer Kopie arbeitest.
Wenn ja, dann versuche mal die *.res Dateien zu löschen. Die müsste Delphi dir wieder ertstellen, wahrscheinlich musst du ein paar Bilder wieder einfügen. Aber vielleicht ist das ja die lösung (nur geraten).

Gruß
Klabautermann

danke aber hat leider nicht geholfen.. ich hasse clx mittlerweile auch ganz kräftig. ausserdem finde ich, das kylix unter linux eh viel zu laaaangsam ist um wirklich vernünftige Anwendungen damit schreiben zu können.. der gesamte Oberflächenaufbau sowohl von Kylix als auch von den Programmen selber ist viel zu langsam und verzögert, also wenn man das z.b. mit c++/motif vergleicht..

Jan

irgendwie gings dann auf einmal doch (aber keine ahnung, warum auf einmal), aber dann kam auf einmal beim versuch, das programm laufen zu lassen, eine exception, und zwar mit der meldung, die property <meine Form>.TextWidth existiere nicht. Nun hat eine TForm keine property TextWidth, und auch das zu der Form gehörende .dfm-File enthält keine solche, und überhaupt taucht im gesamten Projektverzeichnis nirgendwo "textwidth" auf. ARGH.. weiss irgendjemand rat? auch der hinweis, das niemand rat weiss und das es einfach nicht geht, würde mir schon helfen, dann breche ich das frustriert ab..

Jan

ich habs hingekriegt.. will jemand wissen, wie?

Ja

ok.. also als erstes die "bekannten" schritten, xfm in dfm umbenennen, die Q's entfernen.

Dann erschein bei quasi jeder Unit die Fehlermeldung "Die Eigenschaft TextWidth exisitert nicht". Dies liess sich seltsamerweise dadurch beheben, das ich in das dazugehörige dfm-File unter eine Stelle, an der TextHeight=... stand, die "fehlende" TextWidth hineingeschrieben habe, z.B. TextWidth=10. Danach kam immer noch die Fehlermeldung, aber wenn man die eben gerade hinzugefügte TextWidth-Zeile wieder aus dem dfm-File entfernt, dann geht's seltsamerweise (war bei mir zumindest so).

Das zweite Problem sind die hin und wieder auftretenden "Unsupported 16bit resource in file..."-Meldungen, diese basieren wohl tatsächlich auf einem Bug in RLink32 und verschwinden, wenn man mit rechts auf die Form klickt und den Haken bei "Text-DFM" entfernt. Teilweise lässt sich die TextWidth-Zeile zwischendurch auch nicht mehr entfernen, weil das Projekt sich wegen dieser Fehlermeldung gar nicht mehr sinnvoll öffnen/anzeigen lässt, dann kann man einfach das dfm-File "von aussen" (wordpad etc.) öffnen und die Zeile hinzufügen/entfernen.

Naja, und nadchdem alle Units so "behandelt" worden sind, gings dann.. wenn man von dem kaputten Form-Layout (Grösse, Farbe) absieht.

Grüße
Jan