Schliessen einer Form
adi paniz
Ich arbeite mit Formset (warum auch immer). Ist in der FormSet nur 1
Formular, kann ich die Form sauber schliessen mit dem X in der Titelleiste
oder mit meinem SchliessenButton. Besitzt die FormSet aber mehr als 1 Form
kann ich diese nur noch mit meinem Button schliessen, mit dem X der
Titelleiste wird das Unload der Form nachweislich nicht durchlaufen, die Form
wird lediglich als Visible = .F. gesetzt. Erst wenn ich die App beende,
schliesst er die noch offenen (und unsichtbaren) Forms. Ich benütze VFP9
Danke für jeden Tipp
Gruss Adi
Olaf Doschke
ich denke die kurze Antwort darauf ist: das wirst Du nicht �ndern k�nnen.
Ich habe eine Weile mit Formsets gearbeitet und kenne diese �rgernisse. z.B.
auch die ZOrder von Formularen im Formset und in anderen Formsets.
Ich erinnere mich an keine L�sung, die ich Dir jetzt sonst ja gerne sagen
w�rde.
Formsets haben eine gemeinsame Datensitzung, was auch auch durchaus ein
Vorteil ist. Eine Idee f�r einen Ansatz w�re, ob nicht evtl. ein Event auf
Formsetebene l�uft, wenn ein Formular geschlossen wird, was Du dann statt
des Unloads nutzen k�nntest.
Ansonsten empfand ich es �berhaupt nicht als schlimm, da� Formulare nur
unsichtbar wurden, man konnte sie dann eben auch wieder sichtbar schalten,
statt neuzustarten.
Heutzutage lasse ich die Finger weg von Formsets und steuere �ber Default
vs. Private Datasession, ob ein Formular seine eigene Datensitzung bekommt,
oder die aktive Datensitzung - typischerweise eines
Parentformulars -mitnutzt. Gerade eine Unterteilung in Listformular und
Detailformular macht so mehr sinn, weil man mehrere Detailformulare
anstarten kann. Hat man die beiden Formulare dagegen in einem Formset, hat
man trotzdem nur ein Detailformular.
Tsch��, Olaf.
Horst Kühn
> Heutzutage lasse ich die Finger weg von Formsets und steuere ï¿œber Default
> oder die aktive Datensitzung - typischerweise eines
> Parentformulars -mitnutzt. Gerade eine Unterteilung in Listformular und
> Detailformular macht so mehr sinn, weil man mehrere Detailformulare
> anstarten kann.
Aber wie kriegst Du das hin?
wenn ich eine Formklasse in eine Form reinbappen will werd ich gefragt
ob ein Formularsatzobjekt erstellt werden soll. Das wï¿œre dann ja ein
Formset oder?
Oder machst Du das mit newobject oder createobject (von eigener
Klasse)?? Da blitzte dann im Programm die Form kurz auf und ward nicht
mehr gesehen.
wahrscheinlich dumm die Frage, aber ich habs neulich dann aus Zeitdruck
sein gelassen.Sollte da genau andersherum sein, das Formular zeigt
Detailangaben an und im Fensterchen dann eine dazugehï¿œrige Liste, aber
das ist ja egal.
Ich habs dann mit einem Container auch hingekriegt
Horst
Olaf Doschke
> Oder machst Du das mit newobject oder createobject (von eigener Klasse)??
> Da blitzte dann im Programm die Form kurz auf und ward nicht mehr gesehen.
Ja, ich hinterlege im Listform z.B., welche Detailformklasse dazugeh�rt und
starte diese per Createobject (eigentlich per factory) an.
Wegen des Aufblitzens: Die Detailform darf nicht in eine lokale Variable im
Click des Parentforms hinein erzeugt werden, denn die Variable wird ja am
Ende des Click gel�scht und damit ist dann auch gleich das Destroy des
Detailforms gelaufen.
Daher auch Factory bzw. Formhandler: die Aufgabe die Form zu erstellen und
die Formreferenz zu halten wird dorthin delegiert und nicht vom Parentform
geleistet.
Damit sich die beiden Forms gegenseitig kennen, kann man z.B. aus dem
Parentform heraus THISFORM als Parameter �bergeben und die Childform kann
dann diese Referenz speichern und umgekehrt �ber diese Referenz wiedderum
THISFORM an eine Methode a la RegisterChildform �bergeben. Man mu� dann nur
beim Schlie�en mit den ganzen Referenzen etwas aufpassen.
Entkoppeln kann man das �ber ein drittes Objekt, z.B. eines, was man
wiederum mitgibt und in das sich beide Formulare eintragen. Was dann
langlebig bleibt und auch z.B. f�r den R�cktransfer eines Resultats des
Childforms sorgen kann.
Tsch��, Olaf.
Horst Kühn
> Click des Parentforms hinein erzeugt werden, denn die Variable wird ja am
> Detailforms gelaufen.
Ahja ..Logisch. Da bin ich nicht drauf gekommen (sowas soll man auch
nicht unter Zeitdruck ï¿œben)
> Daher auch Factory bzw. Formhandler: die Aufgabe die Form zu erstellen und
.
.
.
.
Ja , sehr schï¿œn erklï¿œrt.Gefï¿œllt mir alles sehr gut ! Damit kann man dann
auch eine Kommunikation zwischen beiden sicherstellen (insofern nï¿œtig)
Morgen wird gebastelt..
Danke Dir fï¿œr die Erlï¿œuterungen
Horst
Olaf Doschke
Wenn Du da gerade dran bastelst, schau Dir die Collection an. Sie ist eine
simple Basisklasse zur Verwaltung/Speicherung der Formularinstanzen, denn
eine Collection entfernt automatisch ein Item mit einer Forularreferenzen,
wenn das zugeh�rige Formular per Release()-Methode geschlossen wird (statt
wie normal durch die gespeicherte Referenz in Variablen oder Properties die
Form davon abzuhalten, sich schlie�en zu k�nnen).
Das ist eine Besonderheit der Collection bez�glich Forms, bzw. eine
Besodnerheit der Releasemethode bez�glich Collection-Items. Zitat aus der
Hilfe zur Form.Release()-Methode:
When you have an object reference to a form in a collection, and you call
the form's Release method, the object is removed from the collection without
having to release or remove the form from the collection first.
Folgendes zeigt das:
_Screen.Addobject("oForms","Collection")
* mal abgesehen davon, da� _screens.Forms auch schon eine FormsCollection
bzw. FormsArray ist,
* hilft diese Systemeigene Collection nicht, Formulare am Leben zu halten.
oForm = CreateObject("form")
cHWND = Transform(oForm.hwnd)
_screen.oForms.Add(oForm,Transform(cHWND)
oForm.Caption = 'Test'
? _screen.oForms.item(cHWND).Caption
oForm.Release()
? _screen.oForms.Count
Es w�re auch schlimm, wenn _screen.Forms jeweils Formulare am Unload hindern
w�rde.
Trotzdem erh�lt aber eine in der Collection gespeicherte Referenz das
Formular am Leben,
auch wenn die (z.B. lokale) Variable stirbt, in die es evtl. urspr�nglich
hineininstanziert wurde:
oForm2 = CreateObject("form")
cHWND = Transform(oForm2.hwnd)
_screen.oForms.Add(oForm2,cHWND)
oForm2.Caption = 'Test2'
oForm2.Left = 200
oForm2.Show()
Activate Screen
? _screen.oForms.item(cHWND).Caption
oForm2 = .null.
? _screen.oForms.Count
? _screen.oForms.item(cHWND).Caption && immer noch da.
Und die Collectionklasse l��t sich ja auch ableiten und mit weiterer Logik
um die gespeicherten Referenzen herum anreichern.
Tsch��, Olaf.
Horst Kühn
> Wenn Du da gerade dran bastelst, schau Dir die Collection an. Sie ist eine
jetzt hab ich erstmal aus dem Fenster geschaut ob Du da drï¿œben mit nem
Fernglas stehst.
hatte heute morgen angefangen und dann kam ein Kunde dazwischen..(immer
diese Kunden!) und nu kï¿œmpfe ich mit meiner Disziplin: Programmieren
klar, aber Vergnï¿œgen oder Arbeit....
Und sonst: Du machst Dir eine Mï¿œhe! Klasse ! Vielen Dank , ich werds
gebrauchen und verwerten !
Horst
adi paniz
Danke für die Ausführungen. Ich habe nach langem suchen eine Lösung gefunden:
Im QueryUnload der Form (nicht der FormSet!) habe ich ThisFormSet.release()
geschrieben. Schliesse ich das FormSet ganz normal über mein SchliessButton
(darin steht auch nichts anders als ThisForm.Release() ), wird QueryUnload
nicht durchgeführt, sonder nur wenn ich das FormSet via x-Bt in der
Titelleiste schliesse. Warum auch immer, jetzt hauts hin.
Gruss und nochmals vielen Dank für die schnelle Reaktion
Adi
"Olaf Doschke" wrote:
> Hallo Adi,
>
> ich denke die kurze Antwort darauf ist: das wirst Du nicht ändern können.
> Ich habe eine Weile mit Formsets gearbeitet und kenne diese Ärgernisse. z.B.
> auch die ZOrder von Formularen im Formset und in anderen Formsets.
>
> Ich erinnere mich an keine Lösung, die ich Dir jetzt sonst ja gerne sagen
> würde.
>>
>
> Tschüß, Olaf.
>
>
> .
>
Olaf Doschke
design, das ist so gedacht.
Release() ist also eine Methode, die nicht das QueryUnload()-Event triggert,
sondern nur das Unload(). Oder andersherum: QueryUnload() ist ein Event, was
aber nur von außen angetriggert wird, eben von dem X oben rechts.
Du sprachst aber zuerst vom Unload(), nicht vom QueryUnload(). Das Unload()
wird in jedem Fall durchlaufen.
Tschüß, Olaf.
adi paniz
Vielleicht habe ich mich falsch ausgedrückt:
Ich habe eine FormSet mit mehreren Forms drinnen. Wenn ich auf x oben rechts
klicke, schliesst das FormSet nicht (durchläuft also nicht das Unload)
sondern setzt das FormSet auf Visible = .F.
Ist mir nicht klar warum, aber ist so. Habe dementsprechend lange gebraucht,
bis ichs gemerkt habe, dachte immer die FormSet sei geschlossen. Dafür wird
aber das QueryUnload der Form angestossen. Ich habe nun in diesem Event
einfach ThisFormSet.Release() geschrieben.
Wenn das FormSet nur eine Form enthält, verhält es sich "normal", d.h. mit
klick auf x oben rechts wird das Unload durchlaufen (das QueryUnload wird
nicht angetastet) und die FormSet auch geschlossen.
Wie auch immer, so kann ich leben und meine FormSets werden mit dem X immer
korrekt geschlossen.
Gruss Adi
Olaf Doschke
wozu tut man sich Formsets an, wenn die nur ein Formular enthalten?
Tschüß, Olaf.
adi paniz
Natürlich, da hast Du recht. Es hat sich halt so ergeben, von früher. Und da
nie Probleme entstanden sind (ausser jetzt mit dem X-Click), habe ich es halt
so gelassen. Trotzdem verstehe ich nicht, wieso ein FormSet mit mehreren
Forms nach einem Click auf dem X-Bt nicht schliesst sondern auf visible = .F.
geht. Aber ist jetzt ja auch egal, habe ja eine Lösung gefunden.
Gruss
Adi
"Olaf Doschke" wrote:
> .
>
Olaf Doschke
Auch wenn alle Forms unsichtbar ist, werden sie nicht beendet.
Wenn Du das Formset dadurch bekommen hattest, da� Du
a) ein neues Formular erstellt hast (SCX)
b) ein Form dazugef�gt hast (Formklasse) und dadurch gezwungen wurdest ein
Formset draus zu machen
c) das leere Basisform gel�scht hast
dann kannst Du auch
d) das Formset nun l�schen um wieder eine pure Form zu erhalten:
Formular �ffnen, im Men� "Form" den Punkt "Remove Formset" w�hlen.
Kein Formset => kein Formsetproblem
Tsch��, Olaf.