Problem: Programmende abfangen

[GT43A]

Das Programm wird doch nur ab geschossen und nicht ordnungsgemäß beredet!

 
' Haupt-Fenster öffnen
'
Cls
' Messageschleife ist nötig für jedes Fenster (hier unser Hauptfenster)
'
' Unendliche Schleife starten
'
While 1 
  ' Warten, bis eine Meldung an unser Fenster geschickt wurde
  '
  WaitInput 
  ' Wenn die XProfan-Variable %key gleich 2 war, wurde eine Fenster-Schliessen-Meldung erhalten.
  '
  If %key=2 
    ' 
    ' In dem Fall verlässt das BREAK unsere Schleife sofort
    '
    BREAK 
  EndIf
 ' Unendliche Schleife wieder von vorn beginnen
 '
 EndWhile 

Print "Hallo ich muss noch sichern"
Waitinput
' Programmende
'       
End 'Der Quellcode erzeugt ein noch leeres Fenster. Es liegt

[Andreas Miethe]

Irrtum,

das BREAK verlässt die Schleife und landet bei END.
Das Programm ist ordnungsgemäss beendet.

Wenn Du natürlich noch etwas vor END einbaust....

[Volkmar]

Hier wird doch nichts abgeschossen! Das ist das Standardverhalten und reguläre Ende von XProfan-Programmen. Wenn du selbst die Verwaltung des Systemmenüs übernehmen willst, um noch Aufräumaktionen auszuführen, findest Du in der Hilfe die entsprechenden Windowstyles und Abfragemöglichkeiten.
Zum Beispiel mit dem Stil 256 kannst Du das Beenden mit %Key = 2 abfragen und entsprechende Aktionen ausführen. Und eine elegante Möglichkeit, unabhängig vom Stil hast Du ja mit ~wm_Close schon selbst gefunden.

Gruß Volkmar

[ts-soft]

Zitat von Andreas Miethe

Irrtum,

das BREAK verlässt die Schleife und landet bei END.

Wäre ja schön, wenn es so wäre, %Key = 2 wird niemals erreicht, das
Fenster schließt einfach und evtl. Aufräumcode wird niemals ausgeführt,
deshalb haben ja so viele Profan Programme Memoryleaks.

[GT43A]

Zitat von ts-soft

Wäre ja schön, wenn es so wäre, %Key = 2 wird niemals erreicht, das
Fenster schließt einfach und evtl. Aufräumcode wird niemals ausgeführt,
deshalb haben ja so viele Profan Programme Memoryleaks.

Genau so ist das,
Ok habe mal in der Hilfe nach UserMessage geschaut,
und dort ist es auch gut erklärt warum.
Zitat: Eine sinnvolle Anwendung ist z.B. die Message zum Schließen des Hauptfensters abzufangen, um etwa vor Beenden des Programmes noch etwas zu speicher oder Speicher frei zu geben.

Declare Ende%
UserMessages $10
CLS
WhileNot Ende%
WaitInput
If %UMessage = $10
If @MessageBox("Programm beenden?", "Frage", 36) = 6
Ende% = 1
EndIf 
EndIf
EndWhile
End

Genau dieses wissen fehlt doch dem Einsteiger!
Der sucht sich dann dumm und dämlich und fragt sich „was mach ich falsch“

[ts-soft]

WM_CLOSE sollte in jedem EventLoop erforderlich sein, wenn nicht vorhanden
darf das Loop auch nicht auf das Close reagieren, wie es jetzt der Fall ist.
Außerdem sollten alle Beispiele in der Hilfe daraufhin angepasst werden.

Aber dieses Problem ist so alt wie Profan selbst, inzwischen gibt es wenigstens UserMessages, früher hat man den schließen Button disabled und
das Systemmenü entfernt um MemoryLeaks zu vermeiden .

Aber darüber diskutieren bringt ja nichts.

[GT43A]

Hallo ich noch mal,
bei allen Dialog Fenstern (auch @Create("Window"…) wird %key auf 2 gesetzt, wie in der Hilfe beschrieben.
Zitat: Es wurde in einer Dialogbox bzw. einem Dialogfenster auf das Systemmenü doppelgeklickt, bzw. "Schließen" ausgewählt
Richtig?
Und beim %Hwnd nicht!
Richtig?
wenn JA dann kann ich mein Programm dementsprechend aufbauen.

[GT43A]

OK da mir dieses keiner bestätigen kann
werde ich %key beim Fenster schlissen mal 1000 m Tief ein graben.

und nur noch folgende Abfrage benutzen!

'-Begin-----------------------------------------------------------------
$H messages.ph
'-Hauptprogramm-------------------------------------------------------
Proc Ein_Dialog
  var Zeit_DLG& = @Create("Window",%Hwnd,"Test",500,40,200,200)
  var Dialog_Schleife% = 0
  WhileNot Dialog_Schleife%
    waitinput
    If %Umessage = ~wm_close
      Dialog_Schleife% = 1
    Endif
  Endwhile
  @DestroyWindow(Zeit_DLG&)
Endproc
'-Erzeuge Fenster mit----------------------------------------
WindowStyle 10
Window 40, 40 - 400, 400
Usermessages ~wm_close
While 1
  waitinput
  If (%Umessage = ~wm_close) & (&uWnd = %hWnd)
    BREAK
    Else
      Ein_Dialog
  Endif
Endwhile
Print "Schnell noch was vor'm Beenden tun"
Waitinput
'-End-------------------------------------------------------------------
End

[Volkmar]

Wie ich oben schon geschrieben habe, mit dem Windowstyle 512 (und ich sehe gerade, da habe ich 256 geschrieben ) wird auch beim Hauptfenster %Key=2 gesetzt. Mit 256 kannst Du das Systemmenü mittels MenuItem abfragen und entsprechend reagieren. Aber leider klappt dann der Schließbutton nicht! Die Lösung mittels ~wm_Close ist auf jeden Fall vorzuziehen.

Gruß Volkmar

[GT43A]

Hallo Volkmar,

Zitat: Wie ich oben schon geschrieben habe, mit dem Windowstyle 512..

Zitat: Von ts-soft aber dieses Problem ist so alt wie Profan selbst, inzwischen gibt es wenigstens UserMessages, früher hat man den schließen Button disabled und das Systemmenü entfernt um MemoryLeaks zu vermeiden!

Volkmar heute doch nicht mehr, wir haben 2012

Diese elementare Fehlinformation mit %key sollte doch schnellst möglichst behoben werden, in welcher Form auch immer.

[Volkmar]

Zitat von GT43A

Volkmar heute doch nicht mehr, wir haben 2012

Diese elementare Fehlinformation mit %key sollte doch schnellst möglichst behoben werden, in welcher Form auch immer.

Eben. 2012 geschrieben und funktioniert definitiv, wie Du Dich selbst überzeugen kannst

WindowStyle 512 + 8
' zur 512 eine 8 hinzu, damit überhaupt ein Systemmenü zum Schließen vorhanden ist
CLS

While 1
  WaitInput
  If %key = 2
    Break
  EndIf
EndWhile

Print "Das wird nach Verlassen der Schleife ausgeführt"
Print "Damit Du das auch lesen kannst, folgt noch ein WaitInput"
Print "Bitte nochmal klicken zum Beenden"
WaitInput

Zum Vergleich bitte mal die Hilfe zu WindowStyle lesen und dann würde mich interessieren, wo da im Jahre 2012 oder wann auch immer eine Fehlinformation zu beseitigen wäre.
Würde es heißen, daß im (von mir zuerst fälschlicherweise angegebenen) Stil 256 was nicht klappt, dann geben ich Dir recht. Da wird wirklich der Schließbutton nicht berücksichtigt, der schließt das Fenster kommentarlos in jedem Falle ohen den Teil hinter der Schliefe auszuführen. Und dort genau liegt das Problem, was den guten Testern der Version X2 auch mal wieder durch die Lappen gegangen ist, weil das schon seit Erscheinen der ersten 32-Bit-Version so war. Und deshalb wohl jeder, der sich schon länger mit XProfan beschäftigt, sein eigenes Süppchen kocht und das Problem gar nicht mehr sieht.

Gruß Volkmar

[GT43A]

Hallo Volkmar,
ubs ich wollte keinen zu nahe treten.

Es wird mehrfach in der Hilfe drauf hingewiesen z.B.
Vor dem Beenden des Programmes muss das Handle mit DeleteObject wieder freigegeben werden, da ansonsten der von der Bitmap belegte Speicherplatz nicht wieder an das System zurückgegeben wird.

Und wenn ich dann am Programm Ende diesen befehle aufrufe und er wird nicht ausgeführt sehe ich als Neuling meinen PC schon in Flammen aufgehen.

Gut zu wissen das Rolland es im Visier hat.

Und dank eurer Infos und Hilfestellung ist der Feuerlöscher wieder in der Garage.

MfG

[Volkmar]

Kein Problem. Das geschriebene Wort sieht manchmal anders aus als wenn wir Angesicht von Angesicht reden würden. Deshalb nehme ich das auch nicht alles so ernst. Und mich selbst auch nicht auch wenn ich manchmal etwas ironisch schreibe. ist dann auch nicht böse gemeint.
Und daß der Rechner in Flammen aufgeht, da mußt Du dir keine Sorgen machen. Es wird dann nur etwas Speicher nicht wieder frei gegeben. Und abhängig davon, was nicht korrekt freigegeben werden konnte, verhalten sich andere Programme dann mitunter etwas seltsam. Solche hartnäckigen Reste können dann in aller Regel nur durch Neustarten des Rechners beseitigt werden.
Und wenn in künftigen Versionen dann eine etwas bessere Methode drin ist, dann hat das Thema hier doch was gebracht

Gruß Volkmar

[Frabbing]

Ab Windows XP gibt jeder Prozess beim Beenden automatisch allen Speicher und Handles usw. frei, die er besetzt gehalten hatte. Es muss sich also heutzutage niemand einen großen Kopf machen, wenn bei Programmende mal was nicht freigegeben wird. Das oft zu unrecht gescholtene Windows macht das eh ganz automatisch!

[AHT]

Stimmt nicht ganz.
Ob alles freigegeben wird, hängt davon ab, ob es sich um globale oder lokale Handles auf das Objekt handelt. Lokale Handles sind zum Beispiel Kernelhandels - bei denen kann beim Beenden eigentlich nichts zurückbleiben. Bei globalen Handles dürfte zumindestens ein geringer Speicherbereich weiterhin in Verwendung sein.