Hallöchen,

hatte jemand diesen Fehler schon einmal beim Öffnen des Hauptformulars in der BDE ?

D5 SP1, XP Prof. (Fehler exitierte auch in NT 4.0 SP6)

Ist ein ziemlich großes Hauptformular mit etlichen Frames die ihrerseits wieder Frames enthalten, gesteuert über ein TabSheet.

Der Fehler kommt nicht bei kleineren Hauptformularen der Projektgruppe, nur bei den großen. Danach hängt sich Delphi auf und ist nur noch über den Taskmanager zu knicken. Recherchiere seit vier Tagen, habe auch einige Sachen gefunden (Tamarack ja, Borland -> nichts), wurden aber entweder nicht ernsthaft beantwortet oder basierten auf einem anderen Problem.

Ich vermute entweder einen Handle-Überlauf oder irgendwie ein Frame-Limitierung ( per Bug ).

Bin für jeden Tipp dankbar, ich komme einfach nicht weiter.

Danke und Gruß

Sven

Moin Sven,

also nach allem, was ich bislang zu Frames gelesen habe, kann ich mich nur glücklich schätzen noch nie welche verwendet zu haben.
Die sollen doch ziemlich fehlerbehaftet sein.

Möglicher Weise gibt's einen Ersatz für die Frames:

Ein Formular erzeugen, dass den Inhalt des Frames hat.
Dieses bekommt dann den BorderStyle bsNone.
Im OnCreate Event wird jetzt jetzt als Parent das entsprechende Formular eingetragen, und zusätzlich muss noch die Eigenschaft IsControl auf true gesetzt werden.

Im OnShow des Parent Formulares wird das Unterformular jetzt mit Show angezeigt.

Die Positionierung müsstest Du dann wohl noch anpassen.

Soweit ich das ausprobieren konnte funktioniert diese Methode.

Sollte dieses Vorgehen etwas für Dich sein, gebührt der Dank allerdings Hagen Reddmann, aus dem EF. Von dem stammt diese interessante Idee.

Hi Chris,

vielen Dank für Deinen Tipp.

Ich persönliche hörte, bzw. las noch nicht über diese Probleme mit Frames. Zu welcher Version gehören Deine Infos. Hat sich evtl. in D6, bzw. D7 da etwas getan.

Hat folgenden Grund:
Ich habe mich dieses Jahr ausschließlich (hauptberuflich) damit befasst, dass Prog auf Frames und danach auf ein C/S-DBS umzustellen. Es ist ein sehr großes Prog (über 30 einzelne Projekte) und es wäre definitiv preiswerter, D7 zu kaufen, als den ganzen Mist rückgängig zu machen.

Falls Du irgendwelche Quellen über Frames haben solltest, würdest Du mir einen riesen Gefallen tun, mir sie zu schreiben.

Komplett neuer Umbau -> ein lieber kleiner netter Softwareanbieter auf dem deutschen Markt weniger

Danke nochmal

Gruß

Sven

Moin Sven,

Quellen hab' ich nicht direkt.
Such mal im Entwickler-Forum nach "Reddmann Frames". Da solltest Du einige Fundstellen haben.

Zu D6 hab' ich allerdings auch nichts gelesen, was mich überzeugt hätte (z.B. hat sich der eine oder andere dazu entschlossen lieber mit D5 weiterzuarbeiten, nachdem er sich D6 installiert hatte).
Und zu D7 gibt's wohl noch nicht so die Erfahrungswerte.

Wie gesagt, hab' ich mit Frames bislang nichts gemacht, hatte aber den Eindruck als wäre die Variante mit einem Form als Control doch sehr ähnlich, auch in der Handhabung, so dass ein entsprechender Umbau nicht zwingend sehr aufwändig ausfallen muss.
Wenn man statt Frames einfach Forms nimmt, die dann eben nicht via Projektdatei erzeugt werden, wird die Ähnlichkeit wohl noch grösser.
Wenn ich mir mal die Deklaration von TCustomFrame so ansehe ist mir auch nicht so recht klar, wo wohl die Fehler herkommen, denn so sonderlich aufwändig sieht's wirklich nicht aus.
Ein TCustomForm ist da schon sehr sehr viel umfangreicher, wird allerdings von der gleichen Klasse abgeleitet wie die Frames.

Hallo Chris,

ich bin heute mal systematisch vorgegangen und denke, das Problem näher
eingegrenzt zu haben.

Zuerst zu Deinem Vorschlag - Danke.

Ich habe das mit dem Wechsel auf TForm probiert. Theoretisch auch ganz
einfach, da alles auf einem TBasisFrameCHS (TFrame) basiert. Hörte sich
gut an, Dein Vorschlag.

Leider, Frames werden automatisch erstellt, Forms nicht.
Jedes einzelne Projekt hat im Grunde genommen nur ein Formular, das Hauptformular. Alles andere basiert auf Frames, die dort eingebunden sind. Allerdings teilweise über 20 Ebenen (Nachfahre mit zusätzlichen Komponenten-Frames). Also müßte ich in jeder Ebene für jeden Frame die Erzeugung, Freigabe etc. einbauen.
Falls Du noch die Delphi 3 Objekt-Hirachie kennst (das A2-Blatt), so
mußt du Dir das ungefähr vorstellen, nur 5 x so groß.

Ich habe weitergsucht und folgendes herausgefunden:

Speicherbedarf lt. Taskmanager:

Delphi Start im Grundprojekt 29 MB

Kleines Modul nach Öffnen MainForm: 53 MB
Funktionierendes mittleres Modul: 88 MB
Nicht funktionierendes großes Modul: zwischen 81 und 83 MB säuft die IDE ab

Während des Compilierens mittleres Modul geht es hoch bis 113 MB

Habe eine FallBack-Position im großes mittleres Modul.
Eingebundener Frame TBasisKunden. Basiert auf 10 Vorfahren bis zum TFrame. Steuerung über ein TTabSheet. Je Nachfahre wird der Frame um ein oder mehrere TabSheet-Seiten erweitert, deren Komponenten ihrerseites Nachfahren von TFrames sind und enthalten.

Sobald ich TKunden (von TBasisKunden) um eine TabSheet-Seite von 11 auf 12 erweitere und einen beliebigen meiner Frames einfüge, kommt das Phänomen. Manchmal schon während des Einfügen, manchmal kann ich erst compilieren, speichern, ausführen etc. und beim nächsten Öffnen von MainForm, nachdem ich bereits aus Delphi raus war, Rechner neu gestartet habe, kommt der Fehler.

Und zwar immer mit "Unbekannter Softwarefehler (0x0eedfade) an Stelle
0x77e53887" ( immer die gleiche Adresse)

Noch eine neue Entdeckung:

Habe nacheinander alle "kleinen" Hauptformulare der Projektgruppe
geöffnet. Beim vierten soff die IDE ab mit:

"Fehler beim Erzeugen von Formular: Win32 Fehler. Code 14.
Für diesen Vorgang ist nicht genügend Speicher verfügbar"

Ist ein 1600er mit 512 MB, deutet für mich also alles auf einen Überlauf in Delphi, bzw. IDE hin.

Tausend Dank erst mal für Deine Bemühungen. Habe eben den Bronze-Support von Borland geordert, mal sehen, was die sagen.

Probiere weiter und sobald ich etwas weiß, poste ich ne Info.

Danke

Sven

Moin Sven,

also die Adresse deutet auf die Kernel32.DLL hin. Wenn ich nicht sehr irre liegt in diesem Adressbereich.

Was mir noch einfällt: Tritt der Fehler nur beim Start aus der IDE auf oder auch Standalone?

BTW: Ich hatte schon mal (testeshalber) ein Programm erstellt, dass mal eben so 500MB Realspeicher geschluckt hat
Dabei gab's beim Start aus der IDE (D5 SP1 / W2K SP1) keine Probleme.
Ausser Speicher hat das Programm sonst allerdings auch wenig Resourcen belegt.

Fehler 14 ist ja nun schlicht und ergreifend OUT OF MEMORY.
Was ja aber auch heissen kann, dass gewisse Systembereiche voll sind. Da kannst Du dann ja Speicher haben bis der Arzt kommt, es nutzt nichts.
Vielleicht ist die automatische Erzeugung der Frames ja das Problem. Werden die nicht entsprechend wieder vollständig freigegben, sind irgendwann einmal die (Fenster)Handles am Ende, was ja nun auch ausgesprochen gut zu der Fehlermeldung passen würde.

Halli hallo.

Keine Probleme mit Ausführung, Compilierung etc.

Stelle es Dir so vor. Du Startest Delphi, Projektverwaltung, Projekt per + aufklappen, Du kann jede beliebige(s) Unit / Formular öffnen (habe sie gerade mal gezählt, in dem BÖSEN Projekt 109 Units (ohne DFMs), außer das Hauptformular.

Du kannst auch reingehen, Projekt aufklappen und nur das Hauptformular öffne, der gleiche Fehler.

Compilieren und Ausführen innerhalb der IDE - no problem, als exe - no problem, ich bekommen nur mein Hauptformular nicht geöffnet, egal ob ich das DFM oder die pas anklicke.

Resourcen sind natürlich ne Menge verbraten, ich schätze das Hauptformular beinhaltet inkl. der Frames ~ > 500 Komponenten.

Ich weiß es nicht mehr, ich hoffe auf Borland.

Selbst Chris Ueberall, der ja wirklich in den Delphi-Groups richtig mitmischt ist ratlos.

Ich hoffe, ich kann mich mal wirklich für Deine Mühen revanchieren.
Ooops, schweres Wort

Gruß

Sven

Moin Sven,

zwei Dinge hätte ich da noch. Zum einen eine Verständnisfrage:

Zitat:

Leider, Frames werden automatisch erstellt, Forms nicht.

Zur Laufzeit, oder zur Entwurfszeit? In letzterem Falle könnte die Objektablage als Workaround dienen (die ja von den Frames abgelöst werden sollte).

Zum anderen:
Ob es eventuell an D5 liegt könntest Du vielleicht mittels D6PE oder D7 Architect Trial ermitteln. Die gibts ja bei Borland zum kostenlosen Download.

Chris,

bei der CHS arbeitet ein Hanburger Kollege, der is nur leider nich da, sonst könnte ich ein paar Sprüche aus der Heimt loswerden.

Was sagt eigentlich Deine Frau, wenn so armen abgeschmierten Proggis hilfst ? Oder designed sie gerade Webseiten ?

Also meine habe ich zum Elternsprechtag geschickt

Zu Deiner suggestion:

Objektablage habe ich am Anfang genutzt (D3), - und dann kamen die Frames, war für mich der Himmel. Grundsätzlich habe ich nichts dagegen, mit der Objektablage zu arbeiten, ich befüchte nur, das Ding ist dafür zu groß geworden.

Ich denke meine Haupthoffnung ist, "kleiner Schalter" und schon läuft wieder alles, deswegen sträube ich mich wohl, im großen Stil umzubauen.

Ich sitze jetzt seit vier Jahren an dem Ding, ist fast fertig und nun dies. In den vier Jahren habe ich das Teil im Grunde genommen drei Mal geschrieben, weil ich immer wieder auf so einen Klops gestoßen bin und alles noch mal aufgebaut habe.

Bitte verzeihe mir den fehlenden Repekt momentan, aber alles in meinem geschundenen Körper wehrt sich dagegen, das Frame-System zu kippen, ich habe da arbeitsmäßig echt Befüchtungen, wieder damit "Gott weiß was" auszulösen.

Der Mist muß doch zu finden sein, das gibt es doch nicht

Gruß, auch an die sympathische Designerin.

Sven

Moin Sven,

danke, ich hab' Den Gruss dann mal unbekannter Weise ausgerichtet

Wenn die Hausgenossen mit K Katzen und nicht Kinder sind, hat sich das mit dem Elternsprechtag allerdings erledigt
(da wir aber beide liebend gerne vor der "Kiste" sitzen stellt das kein Problem dar)

Das man irgendwie keine Lust hat ein Projekt, gerade von dieser Grösse ein weiteres Mal einer grösseren Änderung zu unterziehen ist verständlich.
Was ich mir gerade vorgenommen hab' (ich muss ja (leider) nicht, wenn ich nicht will), hab' ich auch vor kurzem das dritte Mal fast von Anfang an neu gemacht (bzw. angefangen). (und bin gerade auf einen blöden, selbstgemachten, Fehler aufgelaufen ).
Und das Teil dürfte, wenn's fertig ist, nicht mal halb so gross werden wie das was Du da gerade in der Mache hast (werden wohl nicht mal 10% davon)

Ich kann Dir ja nur wünschen, dass es sich das Problem mit einer Kleinigkeit beheben lässt, fürchte allerdings, dass dem nicht so ist. (nicht hauen *duck* aber ich denke eher mal an einen Bug in Delphi, und wenn ich den Zeitpunkt an dem der Fehler aufgetreten ist jetzt richtig verstanden hab' wohl im Designer)
Wie gesagt, probier doch mal die Trial von D7. Schlimmer als das es damit auch nicht geht, kann's ja auch nicht werden. Problematisch wird's natürlich, wenn Du Kompo's verwendest, die's dann nicht unter D7 tun (auch ein Grund warum ich möglichst Fremdkompos vermeide).
Wenn's denn mit D7 geht, kann man wohl von einem Bug in D5 ausgehen, wenn nicht ist dann entweder der Bug mitgewandert, oder doch im Programm zu suchen.
Durch dieses ständige Compilieren im Hintergrund, hatte ich auch schon mal einen Fehler, der die Weiterbearbeitung einer Unit komplett unterbunden hat. Kaum war die geladen stieg die IDE mit einem Fehler aus. Ursache war dann ein zuviel gesetztes Komma zwischem dem letzten Eintrag in einem Aufzählungstyp und der abschliessenden Klammer. Liess sich nur durch Verwendung eines anderen Editors korrigieren. (vom Finden dieses Fehlers mal ganz zu schweigen )
Das war im zweiten Anlauf meines inzwischen zum dritten Mal begonnenen Projektes. (knapp ein Jahr dauerts auch schon )

Da ich Frames ja nur vom "Weghören" kenne, kann ich leider auch den Aufwand der Anpassung nicht beurteilen. Für mich sah's nur, nach der "Verframeung" ( ) eines Forms recht ähnlich aus.

Was mir gerade noch an Prüfmöglichkeit einfällt:
Lässt sich das Projekt (bzw. die Projekte) mit dem Kommandozeilencompiler, also ohne IDE, lauffähig kompilieren?