Hallo!

Wenn ich Unit2 über das Menü "Zuletzt verwendet" oder über die Liste beim Öffnen-Button öffnen will, erhalte ich seit ein paar Minuten (nach dem ich den Fokus auf eine Komponente in Unit1 gesetzt habe, also nichts Besonderes) die Meldung:

Zitat:

Modul 'C:\[...]\Unit2.pas' besitzt geöffnete abgeleitete Klassen oder verknüpfte Module. Schließen nicht möglich.

Das Öffnen über den Button "Öffnen" hingegen klappt. In Unit2.pas oder Unit2.dfm ist nichts geändert worden! Das Projekt lässt sich kompilieren.
Neustart von Delphi nützt nichts.

Was bedeutet das? Und warum Schliessen, wenn ich öffnen möchte?

//Edit: Jetzt funktioniert es wieder...

//Edit: Und jetzt wieder nicht.


Moderiert von Narses: Topic aus Sonstiges (Delphi) verschoben am Mi 18.09.2024 um 06:54

Verwendest du Datenmodule oder Imagelisten, die du über Unitgrenzen hinweg nutzt?

Das passiert auch wenn man Dialoge/Fenster vererbt. Dann kann man die Basisklasse nicht zumachen wenn man Ableitungen offen hat.

jaenicke hat folgendes geschrieben :

Verwendest du Datenmodule oder Imagelisten, die du über Unitgrenzen hinweg nutzt?

Sinspin hat folgendes geschrieben :

Das passiert auch wenn man Dialoge/Fenster vererbt. Dann kann man die Basisklasse nicht zumachen wenn man Ableitungen offen hat.

In Unit2 habe ich gar nichts geändert, und in Unit1 lediglich einige .SetFocus verändert. Plötzlich trat das auf. Aber ich werde Unit1.pas nochmal durchgehen.
Antwort für beide Posts: Datenmodule und Dialoge: nein, Imagelisten und Fenster: weiss ich jetzt gar nicht... Fenster eventuell...
Werd's mir ansehen!

Ich glaube wir haben uns zu kryptisch ausgedrückt.
Die Ursache für die Meldungen kannst Du nur in den DFM Dateien sehen/suchen.
Und zwar wenn Du in einem deiner Formulare/Fenster eine Komponente hast die von einer anderen Komponente in einem anderen Fenster verwendet/referenziert wird.
Das kommt häufiger bei Datenbank Komponenten zum Einsatz. Oder bei einer Imagelist die man nur einmal anlegen will aber in mehr als einem Fenster verwendet.

Oder eben, wenn man für seine Fenster ein eigenes Basisfenster hat. Ist das offen, bekommt man manchmal einfach nicht wieder zu.

Sinspin hat folgendes geschrieben :

Ich glaube wir haben uns zu kryptisch ausgedrückt. Die Ursache für die Meldungen kannst Du nur in den DFM Dateien sehen/suchen. Und zwar wenn Du in einem deiner Formulare/Fenster eine Komponente hast die von einer anderen Komponente in einem anderen Fenster verwendet/referenziert wird.

Ich wüsste nicht, was da sein könnte, muss es mir ansehen.

Sinspin hat folgendes geschrieben :

Oder bei einer Imagelist die man nur einmal anlegen will aber in mehr als einem Fenster verwendet.

Auch hier: Nichts, was irgendwie besonders wäre.

Sinspin hat folgendes geschrieben :

Oder eben, wenn man für seine Fenster ein eigenes Basisfenster hat. Ist das offen, bekommt man manchmal einfach nicht wieder zu.

Da wird's interessant: Ich habe eine Form, von der ich zur Laufzeit weitere, theoretisch beliebig viele weitere Fenster ableite: aForm := TForm27.Create(...)
Das kommt aber nicht in Unit2 vor, sondern in Unit1. Und welche Auswirkung kann das denn zur Entwurfszeit haben?

Noch etwas ist mir gestern aufgefallen: Wenn Unit1 nicht geöffnet ist, kann ich Unit2 über die "Zuletzt geöffnet-Liste" öffnen, andernfalls nicht.

Laufzeit ist Wurst. Das was da bei dir passiert hat nur mit dem Form Designer zu tuen.
Der ist zu blöd einfach vertrauen in den Entwickler zu haben und bestehende links zu anderen Formularen als gegeben anzusehen, auch wenn diese gerade nicht offen sind.
Das ist aber nix neues und auch nix zu verschwinden scheint. Ich kenne das über alle Delphi Versionen (bis zumindest 11.1) hinweg.

Sinspin hat folgendes geschrieben :

Laufzeit ist Wurst. Das was da bei dir passiert hat nur mit dem Form Designer zu tuen. Der ist zu blöd einfach vertrauen in den Entwickler zu haben und bestehende links zu anderen Formularen als gegeben anzusehen, auch wenn diese gerade nicht offen sind.

Ich weiss nur nicht, was hier offen oder abgeleitet sein soll. Da ist nichts abgeleitet, keine Klassen, Komponenten oder sonstwas - nichts. Da liegen einfach Komponenten auf dem Form rum. Das ist doch nur eine ganz normale Unit!
Und was sind "verknüpfte Module"?

Es wird immer lustiger:

Zitat:

[dcc32 Fataler Fehler] Unit5.pas(1105): F2063 Verwendete Unit 'Unit27.pas' kann nicht compiliert werden

Diese Meldung erhalte ich seit kurzem manchmal, wenn ich im Code von Unit1.pas etwas ändere, ohne gleich zu speichern, und dann kompilieren will. Da öffnet Delphi Unit5 und hängt selbsttätig(!) in Unit5.pas ganz unten zwei Leerzeilen an (die ich natürlich nicht brauche), und das Beste: Nirgendwo in Unit5 kommt Unit27 vor!
Zeile 1105 ist übrigens eine der von Delphi angefügten Leerzeilen.
Einmal kam diese Meldung, wobei Delphi aber einen "fatalen Fehler" in Unit13.pas fand, diesmal ohne angehängte Leerzeilen.

Irgendwo ist doch da der Wurm drin! Dennoch: Öffnen kann ich alle Dateien, und kompilieren lässt sich das Projekt auch.

Nicht Wurm. Eigenleben.
Das wird noch besser wenn endlich alles von KI erledigt wird. Unrasiert bekommt man dann nichtmal mehr seinen Quellcode formatiert. Vom Kaffee will ich erst garnicht reden

Mach mal Delphi zu, lösch die *.dsk Datei und probier es dann nochmal.
Eventuell auch mal die *.dproj löschen, falls das wieder alles einstellen nicht zuviel Arbeit macht.

Sinspin hat folgendes geschrieben :

Nicht Wurm. Eigenleben.

Ja, scheint ein Bug der IDE bzw. des Form Designers zu sein.

Sinspin hat folgendes geschrieben :

Eventuell auch mal die *.dproj löschen, falls das wieder alles einstellen nicht zuviel Arbeit macht.

Nützt nichts, auch das löschen der .stat, .identcache und .local bewirkt nichts.

Solange es keine größeren Probleme gibt, kann man das ja akzeptieren!

Vielleicht findet Delphi irgendwo gleichnamige Units. Als erstes würde ich den Units mal eindeutige Namen geben.

jaenicke hat folgendes geschrieben :

Vielleicht findet Delphi irgendwo gleichnamige Units. Als erstes würde ich den Units mal eindeutige Namen geben.

Unit1.pas ... Unit27.pas, Unit1.dfm ... Unit27.dfm - ist doch eindeutig.
Zugegeben, selbsterklärende Namen sind gerade bei größeren Projekten besser, aber eindeutig sind diese Vorgabenamen ja auch.

In dem Projekt mögen die eindeutig sein. Aber wie sieht es mit anderen Projekten aus?
Da ist alles wieder genauso nur nummeriert?
Wenn Du dann Suchpfade hast die auf andere Verzeichnisse zeigen wo wieder Units mit gleichen Namen sind kann das schon verwirren....

Es reicht ja auch schon, wenn die kompilierten dcu-Dateien irgendwo noch liegen.

Egal welches Projekt, man sollte schon grundsätzlich beim Speichern auch einen echten Unitnamen eingeben, der nicht in anderen Projekten auch verwendet wurde. Die Standardnamen zu belassen, ist immer eine schlechte Idee.

Wenn du diese ordentlich benennst, weißt du zumindest, dass es damit nichts zu tun haben kann. Oder es funktioniert.

jaenicke hat folgendes geschrieben :

Es reicht ja auch schon, wenn die kompilierten dcu-Dateien irgendwo noch liegen.

Die sind immer in einem Ordner Win32, dieses wiederum ist im selben Ordner, in dem auch die .pas, .dfm, .dproj usw sind. Das Löschen des Ordners Win32 (und damit der in Win32\Debug und Win32\Release vorhandenen .dcu's) nützt nichts. Beide Phänomene (das mit dem Öffnen von Unit2 und das mit den Leerzeilen in Unit5) bleiben. An beiden Units ist, wie gesagt, nichts Besonderes.

Es liegt vielleicht an der IDE. Ein Bug?

galagher hat folgendes geschrieben :

Es liegt vielleicht an der IDE. Ein Bug?

Das kann schon sein. Wenn das auch in der aktuellen Version reproduzierbar wäre, könnte man es melden.

jaenicke hat folgendes geschrieben :

galagher hat folgendes geschrieben : Es liegt vielleicht an der IDE. Ein Bug? Das kann schon sein. Wenn das auch in der aktuellen Version reproduzierbar wäre, könnte man es melden.

Da es ja nichts Gravierendes ist, und es bei mir bisher noch nie auftrat, kann man es auf sich beruhen lassen.
Hätte ja sein können, dass jemand von euch das kennt.

Seit gestern tritt das "Problem" mit dem Öffnen über die Zuletzt geöffnet-Listen auch bei Unit1 auf!