GEOS-InfoBase-Forum

Hallo Leute,

hier mal einen Bericht zu einem Problem, dass einem schon mal den Panikschweiß ausbrechen lassen kann. Schaut euch mal das angehängte Bild an. Den Fehler hatte ich bei meine Mega-Projekten jetzt schon dreimal.
Beim ersten Mal, in meinem Abiturprogramm, habe ich noch dem Hinweis, die Resourcenanzahl zu verringer, geglaubt. Also UI und auch Code Resourcen zusammen gelegt. Bringt aber nichts. Nach vielem Rumprobieren und auslagern von Code und UI in eine Library ging es dann irgendwann. Das Programm hat mir dann viele Jahre gute Dienste geleistet.


Bei nächsten Mal, jetzt in R-BASIC, war die Sache einfacher. Ich hatte gerade neue UI-Objkete hinzugefügt, als der Fehler auftrat. Glue hatte letztlich das Problem, dass er zu viele Objekte verlinken musste. Geholfen hat hier, einen Teil der Objekte in eine andere UI-Datei auszulagern. Da glue Objkete nicht über Dateigrenzen verlinken kann war ihm geholfen, aber man muss den ausgelagerten Tree dann in der MSG_GEN_PROCESS_OPEN_APPLICATION an seinen Tree ankoppeln. Beachten muss man dabei, dass so etwas wie GTI_destination = @RBasApp; natürlich auch nicht mehr geht, wenn @RBasApp nicht in der gleich GOC-Datei liegt, wie der Trigger. Man muss in der OPEN_APPLICATION dann @call AddUserNotesTrigger::MSG_GEN_TRIGGER_SET_DESTINATION(@RBasApp); machen.Dieses Mal, wieder in R-BASIC, hatte ich nicht am UI-Tree gebaut. Daran konnte es also nicht liegen. Ich hatte einfach eine paar neue Routinen geschrieben. Wenn ich die wieder rausgenommen habe, ging es wieder. Das Verschieben der Routinen in eine andere Resource (GOC-Datei) brachte nichts. Es lag diesmal als an der Anzahl der Routinen insgesamt. So ein Mist.
Allerdings konnte ich das Problem auch beseitigen, indem ich ein paar UI-Objekte auskommentiert habe. Glue scheint also nicht zwischen beiden Problemen unterscheiden.

Jetzt suche ich eine dauerhafte Lösung, mal sehen was mir da einfällt. Vielleicht läuft es darauf hinaus Code und eventuell auch UI in eine Library zu verschieben. UI in einer Library ist aber immer aufwändig, da man wahrscheinlich nicht auf die Objekte selber, sonder nur auf Duplikate zugreifen kann (siehe die Threads mit Wilfried). Aber mal sehen ...

So, wenn ihr also über den beschrieben Fehler stolpert, vielleicht erinnert ihr euch an diesen Post und findet schneller einen Lösungsansatz als ich.

Gruß
Rainer

Nachtrag:

Das Verschieben von teilen des Objekttrees in eine andere GOC-Datei hat diesmal nichts mehr gebracht. Fazit:

1. Die Größe von GEO-Dateien hat echte Grenzen. Bei mir etwas mehr als 500 kB
2. Glue liefert eine Fehlermeldung, die einen reagieren lässt und schmiert nicht ohne Kommentar ab. Ein Lob an die Macher von Glue.

Ich schiebe jetzt als Code in eine Library. Was kompliziert ist, weil ich keine Objekte verschieben will. Zum Glück darf man den optr eines Chunks direkt aus einer Library an das Programm übergeben. Also verschiebe ich erstmal Datenchunks und den zugehörigen Code.


Gruß
Rainer

Hallo Wilfried,

Zitat von »Wilfried«

Was genau macht dein Abiturprogramm?

Es druckt die Abiturzeugnisse. Dazu erfasst es die Halbjahresleistungen in der Abiturstufe sowie aller anderen relevanten Daten, die Prüfungsergebnisse und berechnet den Abiturschnitt. Anfangs gab es kein kommerzielles Programm, das das komfortabel konnte.

Da sich die Regeln dazu mehrmals geändert haben, und es mittlerweile auch gute Programme gibt haben wir irgendwann beschlossen ein kommerzielles Programm einzusetzen.

Zitat von »Wilfried«

Stimmt. Ui-Resourcen lassen sich nur in derselben ui-Datei mehrmals öffnen und schließen.

Ja, aber das ist nicht der Punkt, sondern dass glue keine Verlinkung herstellen kann wenn GI_comp auf ein Objekt in einer anderen GOC-Datei verweist.

Zitat von »Wilfried«

Code-Resourcen lassen sich dagegen aucu auf verschiedene GOC-Dateien aufteilen.

Ist das in ESP so? IN GOC erzeugt jede GOC-Datei genau eine Code-Resource.

Zitat von »Wilfried«

<<UI in einer Library ist aber immer aufwändig, da man wahrscheinlich
nicht auf die Objekte selber, sonder nur auf Duplikate zugreifen kann>

Wenn es sich um UI-Objekte eines Controllers handelt, scheint es zu gehen: Es gibt eine Datenstruktur namens GenControlUpdateUIParams, in der u.a. das Global Handle der zum Controller gehörenden "Kinder" abgelegt wird ("Childblock, where the children live"), wenn sie leben, gemeint ist also wohl das Duplikat. Es gibt eine proc (Ruler: uiControlCommon.asm: GetChildBlock), die sich dieses Handle holt, um dann eine Message an ein UI-Objekt zu schicken). Genau ist mir der Mechanismus noch nicht klar .

</ui>

Ich denke mal, der Controller macht nichts anderes als man sonst auch manuell machen muss: Er erzeugt für jedes Programm, dass den Controller benutzt eine Kopie einer Template-Reosurce, die dann dem Programm exklusiv gehört. So kann z.B. GeoWrite die Farbe Blau und GeoDraw die Farbe Grün für Linien eingestellt haben, ohne dass es zu Wechselwirkungen kommt.
Die Chunkhandles sind in beiden Controllern (Draw und Write) gleich, aber die MemHandles unterschieden sich. Um den Controller (oder ein Objekt des Controllers) anzusprechen musst du also immer den korrekten optr konstruieren.
So hab eich den Mechanismus verstanden. Und ich glaube, das habe ich beim Suchen und Ersetzen Controller in R-BASIC benutzt.
Weiterhin glaube ich, dass folgendes gilt: Wenn ich in einer Library Objekte bereitstellen will muss ich eine Template-Resource machen und zur Benutzung jeweils eine Kopie bereitstellen. So können verschieden Programme die Objekte der Library benutzen. In meinem konkreten Fall will ich aber auch Code, der auf die Objkete zugreift, in eine Library packen. Dann wird es "aufwändig" weil ich mir irgendwo das Memhande der (korrekten) Kopie merken muss, und bei jedem zugriff den richtigen optr konstruieren muss. Aus einem einfachen

@send MyObj:MSG_SONSTWAS()
wird dann
@send MakeMyOptr(korrektGlobalHanlde, ChunkOf(@MyObj))::MSG_SONSTWAS().
Wenn ich das vergesse compilert er, aber es geht dann nicht. Und da ich dass an vielen Stellen habe wird es aufwändig und fehleranfällig.
Was ich nicht weis, ist, wenn ich die Library definitiv nur von genau einem Programm benutze, ob ich mir dann das Duplizieren der Resource sparen kann und wieder mit den Objekten direkt arbeiten darf.
Mit Datenchunks darf ich das, weil (wenn) die Programm die Chunks nicht ändern. Dann kann ich mehreren Programmen den gleichen optr übergeben. Ich muss die Ressource nur als "shared" deklarieren. Deswegen lagere ich erst einmal alle Datenchunks aus.

Soweit meine Überlegungen / mein Kenntnisstand.
Gruß
Rainer