Inoffizielles deutsches Xbase-Forum

Liebe XBase-Gurus!

Nachdem bei mir von AppSys() ein Applikationsfenster bereit
gestellt worden ist, öffne ich im Hauptprogramm (Main())
eine Log-Datei LogFile.dbf:

1. AppSys()
Applikationsfenster

2. Main()
Öffnen von Logfile.dbf für Eintrfag Login

3. oDlg mit Anzeige von einem MLE
Anschliessend baue ich einen Dialog auf, der zum Anzeigen eines
MLEs dient.
Der Dialog hat beinhaltet ausser der Anzeige des MLEs auch zwei
Pushbuttons.

4. Schliessen von oDlg.
Nach der Anzeige des MLs soll diese nach Betätigung eines
Pushbuttons durch den Benutzer geschlossen werden:

oDlg:destroy()

Anlässlich von oDlg:destroy() ist allerdings dann auch die Datei
Logfile.dbf geschlossen und steht für einen Eintrag eines Logouts
nicht mehr zur Verfügung.

Wie kann ich das korrekt handhaben?

Falls Ihr helfen könnt: lieben Dank und winke winke aus
der Schweiz
GrillenHirni

"oDlg:Destroy()" schließt ganz sicher keine Tabellen, es sei denn, die Destroy-Methode ist überlagert und enthält entsprechenden Code.

Hallo, GrillenHirni -


öffnest Du den Dialog (und die Datei) in einem eigenen Thread? Wenn der geschlossen wird, dann werden auch alle in dem Thread geöffneten Dateien geschlossen.

Hallo Georg-Spezial-Programmier-Gott!

Das könnte das Problem sein - ich behandle in meiner Anwendung
keine Threads - der betreffende Dialog mit dem MLE ist nicht in
einem separaten Thread... Wird die Logdatei deshalb gleich mit
dem Dialog geschlossen?

Und wo ist die Eiffel? Ich kenn mich ziemlich gut aus Ballungsgebiet
Nordreinwestfahlen (Köln, Düsseldorf), dann Schwarzwald (Freiburg)
und Allgäu... Eiffel frag ich mich schon lang, wo das ist?

Danke für Deinen Tipp!! Falls ich nichts mehr lese von Dir, guck ich
mal im Handbuch, wie das geht mit diesen Threads - danke für den
Ansatz!
GrillenHirni

Wenn Du nichts mit Threads machst, wird (kann) das auch nicht die Ursache sein. Außerdem wäre in diesem Fall die Tabelle schon beim Erzeugen des Dialogs nicht sichtbar, da sie ja in Main() geöffnet wird.

... etwas Code könnte helfen. Vielleicht machst Du da ja aus Versehen etwas, das Du selber überliest. Oder anders verstehst als das was es macht.

Jan

@Jan: Eben. Das kann tausend Ursachen haben. Vielleicht war die Tabelle nie wirklich offen. Oder wurde geschlossen, weil eine andere Tabelle versehentlich in der selben Workarea geöffnet wurde. Oder irgendeine Funktion, die irgendwo aufgerufen wird, enthält ein CLOSE (DATA(BASES)). Oder, oder, oder. Nur "oDlg:Destroy()" ist es ganz sicher nicht.

Tom,
Du lehnst Dich aber ganz schön weit aus dem Fenster
Nutzt er nämlich z.B. XClass++ und hat die Klasse dsDataDialog oder dsDialog in Benutzung und eine DBF mit der Methode :use() mit dem Dialogfenster verknüpft, dann würde die beim Schließen des Fensters automatisch mit geschlossen werden!
Ähnlich wird es sicherlich bei anderen Add-Ons sein.
Ich weiß zwar, dass Du weiter oben die Einschränkung schriebst: "..., es sei denn, die Destroy-Methode ist überlagert und enthält entsprechenden Code." (und genau dies ist bei XClass++ der Fall), es hier aber nicht erneut erwähnt hast.

Viele Grüße,
Martin

Jahu, Martin.

Er schrieb aber, dass die Tabelle in der Main geöffnet wird. Es kann also nicht so sein wie von Dir skizziert.

Wenn die Datei nach dem Fenster geschlossen ist, fallen mir nur zwei Gründe ein.
Entweder ein globaler CLOSE Befehl oder ein Zugriff im falschen Selectbereich.

Entweder - wie Tom schon erwähnt hat wird ein CLOSE DATABASES oder CLOSE ALL oder aber ein CLOSE oder USE im Selectbereich der LOG Datei ausgeführt.
Dabei fällt mir ein, wie öffnest du denn die Daten DBF im Fenster ?

USE xyz ... würde nämlich schon beim Start die LOG Datei aus der MAIN schließen ...

USE (cDatenDbf) NEW ist angesagt, das sucht sich nämlich einen freien Selectbereich !

@ Martin,

man kann nicht alle zusätzlichen Bibliotheken bei der Antwort berücksichtigen, der Fragesteller sollte sowas angeben

Um zu verifizieren, ob es tatsächlich am "oDlg:Destroy()" liegt, wobei ich mehrere lebenswichtige Körperteile dafür ins Feuer legen würde, dass dem nicht so ist, würde genügen, folgenden Code um das oDlg:Destroy() herumzulegen:
Es wird beide Male .F. oder beide Male .T. angezeigt, da bin ich sicher. Geschlossen wir die Tabelle anderswo.

Liebe Gurus...

Ich lade den Code gerne hier rein... Die Funktion ist aber in eine
Library eingebettet und die ganze Library kann ich hier nicht
rein laden...

Vielleicht ergibt sich trotzdem ein Ansatz...

Was den Code betrifft, bitte ich um mildernde Umstände. Weil
ich war natürlich, bevor ich mich hier ans Forum gewendet hab,
übel am debuggen, um den Fehler selbst zu finden... Darum bin
ich insbesondere an der Event-Schlaufe grandios am basteln und
tracen, um den Fehler zu finden - ich scheme mich jetzt schon...

Das Debuggen hat ergeben, dass die Datei Logfile.dbf in der
Zeile 407: oDlg:destroy() geschlossen wird.

Könnte es sein, das im Objekt oXbpMLE der Selectbereich 1
(mit dem Alias LOG) von der Textdatei "überschrieben" wird?

Ich danke Euch, für Eure Hilfe - es sind schon ein paar wertvolle
Tipps dabei...
GrillenHirni

Ui Tom...

Jetz zittere ich aber um ein paar von Deinen lebenswichtigen Körperteilen -
hoffentlich kommt das gut...!!

Wie kann ich denn den Code hier ins Forum in den Artikel laden?

GrillenHirni

wieso, du hast doch mdemo.prg hochgeladen (Zitieren im Text macht man besser nur bei kurzen Sachen )

zunächst ...

das sind dann PRIVATE Variablen, die unter Clipper hochmodern hier aber nur noch für wirkliche Spezialfälle sinnvoll sind.
Dazu gibt es eine Menge Diskussionen (wie auch zu Public), ich kann nur raten nimm LOCAL Variablen !
ich sehe in der MAIN übrigens KEINEN Befehl der eine Datei öffnet.
Ich sehe aber einen oDlg:=DataDialog():new(oOwner:DrawingArea,,;...
Es kann sein, dass dieser davon ausgeht, eine LEERE Workarea zu erhalten und mal soeben die Dateien in der aktiven öffnet, das wäre ein Grund für das Ende deiner DBF.

SELECT 0 schaltet in einen freien Selectbereich
USE ... NEW öffnet eine DBF in einem freien Selectbereich ...

Als ich noch mit Selectbereichen gearbeitet habe (heute nutze ich nur noch die Automatic und MERKE mir den verwendeten Selectbereich),
habe ich Sonderdateien immer in einem über 10 geöffnet und immer nach 1 zurückgeschaltet. Diesen habe ich immer frei gelassen ...
"

Lieber Hubert

Es hätte mich trotzdem "Wunder" genommen, wie man im Artikel
Code zitieren kann...

Das mit den PRIVATE-Variabeln nehme ich dankend entgegen - hatte
ich mir auch schon gedacht...

Danke besonders für den Hinweis betreffend oDlg:=DataDialog():new(oOwner:DrawingArea...

Wie könnte ich denn die Funktion so verwenden, dass sie mir nicht gleich die
Logdatei (Logfile.dbf) schliesst?

Inzwischen hab ich die ganze Library von mir raus geschrieben und hab jetzt
eine Datei, welche ich compilieren kann und folgend hochlade...

Ich muss jeweils die Bibliotheken XBTBase1.Lib und XBTBase2.Lib dazu linken.

Das war gar nicht einfach, so fünfundzwanzig Jahre Entwicklung raus zu basteln...
Es ist halt nicht mehr der pure Luxus mit Fehlermeldungen und sonstiger Umgebung...

Die LogDatei Logfile.dbf (ALIAS LOG) wird in der Zeile

394 oDlg:destroy() geschlossen

und steht dann in Zeile

608 SELECT LOG

nicht mehr zur Verfügung. Hier würde in der Anwendung der Eintrag eines LogOuts
erfolgen.

Und LIEBER TOM! Ich bin zur Zeit noch recht fit und gesund - kann ich anstatt
Deiner versprochenen Organspende - oder was immer Du meintest mit lebenswichtigen
Körperteilen - auch ein neues Auto haben?

Danke herzlich für die wertvollen Tipps!
GrillenHirni

Die Anwendung verlangt eine Datei ReadMe.Txt mit
irgendeinem Inhalt.

Ich lade hier aber lieber noch die Project-Datei hoch,
mit der ich das Teil MemoDemo.Prg compiliere.

Grilli

Und LIEBER TOM! Ich bin zur Zeit noch recht fit und gesund - kann ich anstatt Deiner versprochenen Organspende - oder was immer Du meintest mit lebenswichtigen Körperteilen - auch ein neues Auto haben?

W.l.k.i.k.i.V.

Ich schrub davon, dass das Destroy nicht die Ursache sein kann, wenn es nicht überlagert ist. Offensichtlich aber verwendest Du den DataDialog aus der Doku bzw. eine abgewandelte Form davon. Und dort ist dann wahrscheinlich das Destroy überlagert.

GrillenHirni hat geschrieben:Lieber Hubert

Es hätte mich trotzdem "Wunder" genommen, wie man im Artikel
Code zitieren kann...

ich lese das als Frage, wie man CODE als CODE kennzeichnet ...
Über dem Eingabefeld gibt es eine Zeile "Tipp ..." und darüber die Befehlsflächen.
das erste steht für Bold (Fettdruck), das 4. "Quote" Zitiert und das 5. markiert "CODE" ...
falls man zuvor Text markiert hatte, wird der dann von den Steuerzeichen umrahmt ... ich schreibe mal hier BLANKS zwischen die Klammern, damit es als BEFEHL lesbar wird.

Procedure MAIN() ... als normaler Text eingegeben, markiert und "CODE" getippt wird
[ CODE ]Procedure MAIN()[ /CODE ], ähnlich wie aus [ B ] Bold [ /B ] Bold wird, wird dann aus dem CODE ... PS: ich hoffe man merkt nicht zu sehr, wie genervt ich noch von meiner 5 Stunden dauernden Renovierarbeit bin.
Nicht dass es nur anstrengend war, ich habe auch noch eine Signalleitung der neuen Haustür erwischt und musste an nahezu unzugänglicher Stelle 3 winzige Leitungen wieder zusammensuchen und löten. Meine Schuld ich hätte wissen müssen, dass da im Bauschaum sowas wartet

Hallo Ihr Lieben!

Jetzt hab ich es hoffentlich auch gecheckt...?

In der Zuweisung DataDialog():new wird eine
Instanz von einem Dialog erzeugt. DataDialog()
hab ich aus dem Beispiel MDIDemo von Alaska
und dort wird die Methode :destroy() überschrieben -
unter anderem mit einer Anweisung, welche
die aktuelle WorkArea dicht macht.

Der Tom hats ja von Anfang an geschrubt...
War wohl nix, mit dem neuen Auto...

Danke auch dem Hubert wegen dem Hinweis,
wie man hier Code darstellen kann! Das PostScriptum
mit dem Bauschaum habe ich allerdings nicht mehr
begriffen - ich dachte bisher, ich sei der Einzige,
gegen den sich verschiedene ausserirdische Galaxien
verschworen haben, aber anscheinend ist der
Hubert ein Leidensgenosse und ich hoffe, das
hat noch geklappt mit diesen dünnen Lötleitungen...

Danke, danke, danke...!
GrillenHirni

Der Tom hats ja von Anfang an geschrubt...