Italia
Foro

Merkwürdigkeit bei DestroyWindow

 
- Page 1 -



Dietmar
Horn
Ciao,
ich bin circa folgende Merkwürdigkeit gestolpert.

Dieser Code funktioniert:
KompilierenMarkierenSeparieren
declare tmp$
cls
tmp$ = upper$(Par$(0))
run tmp$
end
/pre>

Bei dem folgenden Code erfolgt kein Neustart des Programmi im Interpretermodus (es müßte meiner Meinung nach jedoch wenigstens der Interpreter aufgerufen werden):
KompilierenMarkierenSeparieren
declare tmp$
cls
tmp$ = upper$(Par$(0))
DestroyWindow(%HWnd)
run tmp$
en

Eigentlich habe ich doch den nullten Parameter (also den Dateinamen des eigenen Programmi) mit der Stringvariablen gerettet, oder beeinhaltet DestroyWindow bereits ein end?

Als Compilat funktionieren komischerweise beide Varianten.

Gibt es dafür eine logische Erklärung?

Ich habe XProfan 10.

Saluto
Dietmar
 
Multimedia für Jugendliche und junge Erwachsene - MMJ Hoyerswerda e.V.  [...] 

Windows 95 bis Windows 7
Profan² 6.6 bis XProfan X2 mit XPSE

Das große XProfan-Lehrbuch:  [...] 
05.07.2007  
 



 
- Page 2 -



Frank
Abbing

Es wäre allerdings zu überlegen, ob man dieses Feature durch eine Set-Unterfunktion abstellbar machen sollte. Das wäre dann ein Vorschlag per künftige XProfan-Versionen.



Ab damit auf deine ToDo-Liste...
 
05.07.2007  
 



Dieses Set gibt es schon es è usermessage 2
KompilierenMarkierenSeparieren
05.07.2007  
 




Frank
Abbing
Hehe, ja, oder so.
 
05.07.2007  
 



Drum meine ich ja es ist ein Bug - weil wäre es kein Bug dann würde Rolands obige Aussage ja auch hier zutreffen müssen. Aber wahrscheinlich bin ich zu doof um das trotz täglich mehrstündiger XProfanerfahrung seit Jahren einschätzen zu dürfen.
 
05.07.2007  
 



Gleich kommt bestimmt ein WindowStyle 512 Argument. Hey aber darum gehts doch garnicht! Ich verstehe ja naturalmente was Roland meint und will! WM_Close wertet er inner wproc aus um das Programm auch dann zu beenden wenn es in einer Schleife ist. Das ist ok so! Der Bug ist das destroywindow(hwnd) das auch tut! Natürlich sendet dieses destroywindow die selbe Message aber dann muss Roland eben genau hierfür eine Ausnahme setzen. Ein if in destroywindow meinetwegen was aufpasst das wenn der param hwnd ist das ebend nicht das programm terminiert wird. Wer hingegen mit der api ein wm_close sendet der kann damit meinetwegen gerne auf die Nase fallen. Aber hier gehts um das XProfansche Destroywindow das nunmal einfach nicht die Anwendung beenden darf. Noch nichteinmal zur Diskussion potrebbe das stehen denn destroywindow ist nicht end und darf nicht end und auch nicht fast wirken wie end und auch nicht machmal wirken wie end und auch nicht mal hier mal da wirken wie end! Hey und wenn Profan²/XProfan das schon immer so tut - dann tut es das eben schon immer falsch - so einfach ist das nunmal.

The End.
 
05.07.2007  
 




RGH
iF
Dieses Set gibt es schon es è usermessage 2


Ganz so einfach geht es nicht. Dein Programm stürzt ab, wenn Du das zweite Fenster schließen willst.

... und jetzt muß ich in die Waagrechte. Was nutzt die schönste Gleitzeit in der Firma, wenn die Tochter um 7:30 in die Schule gefahren werden muß. ;)

Saluto
Roland

Und noch einmal: Es ist von Anfang an gewollt, daß das Schließen des Hauptfensters (egal, warum, es geschlossen wird) das Programm beendet. Basta!
 
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4
06.07.2007  
 



RGH

iF
Dieses Set gibt es schon es è usermessage 2


Ganz so einfach geht es nicht. Dein Programm stürzt ab, wenn Du das zweite Fenster schließen willst.


Dann haben wir halt gleich noch einen zweiten Bug gefunden.

Denn es gibt kaum eine verständliche und einfache Erklärung weshalb nun grade dieser einfache Source:
KompilierenMarkierenSeparieren
06.07.2007  
 




RGH
Naja, wenn Du eine wichtige Windows-Message zum Verstummen bringst, dann darfst Du Dich nicht wundern, wenn es mit der Kommunikation nicht mehr klappt!

Gute Nacht!
 
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4
06.07.2007  
 



Da steht nix vom verstummen. Neinnein - Usermessage sollte niemals aussagen das man eine Message verstummen lässt - lediglich das diese durch XProfan anders behandelt wird. Gibts zu das ist ein Bug - nicht weils ein Bug ist - sondern weil XProfan eben etwas mehr tun müsste als es jetzt der Fall ist. Nämlich die Destroywindow-Unterscheidung. Hey Roland mal ehrlich der o.G. Source sollte durchlaufen wie ein Bienchen.

Hilfedatei
Es gibt in Profan ab Version 7 anwenderdefinierte Usermessages. Das sind Messages, bei denen WAITINPUT auf alle Fälle verlassen wird und die dann nicht durch die sonstigen XProfan- und Windowseigenen Messagehandler behandelt werden.


Und genau das - und nur das soll auch passieren. Von Absturz ist da keine Rede. ;D

Du hast bisher immer die Linie gehalten Wenn einer Apis nutzt isser selbst zuständig - aber Wenn einer reine XProfanbefehle nutzt sollte alles klappen. Diese Linie ist perfekt und muss aber konsequent gehalten werden.
 
06.07.2007  
 



RGH

Und noch einmal: Es ist von Anfang an gewollt, daß das Schließen des Hauptfensters (egal, warum, es geschlossen wird) das Programm beendet. Basta!


Ha! Das glaub ich Dir nicht. Schließen wenn einer [X] klickt - das wolltest Du sicher und das halte ich ebenso per Sinnvoll im Falle das Windowstyle 512 nicht gesetzt ist (oder usermessage 2) aber das DestroyWindow hwnd das Programm auch beenden sollte das ist geschwindelt. Das hattest Du einfach übersehen gibs zu.
 
06.07.2007  
 




RGH
iF

RGH

Und noch einmal: Es ist von Anfang an gewollt, daß das Schließen des Hauptfensters (egal, warum, es geschlossen wird) das Programm beendet. Basta!


Ha! Das glaub ich Dir nicht. Schließen wenn einer [X] klickt - das wolltest Du sicher und das halte ich ebenso per Sinnvoll im Falle das Windowstyle 512 nicht gesetzt ist (oder usermessage 2) aber das DestroyWindow hwnd das Programm auch beenden sollte das ist geschwindelt. Das hattest Du einfach übersehen gibs zu.


Nein, das hängt programmtechnisch zusammen. Allerdings hatte ich mal eingeplant, das DestroyWindow eine Fehlermeldung ausgibt oder zumindest nicht reagiert, wenn das zu zerstörende Fenster das Hauptfenster ist. Aber dann habe ich es nach einigen Diskussionen doch gelassen.

Saluto
Roland
 
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4
06.07.2007  
 




RGH
iF
Da steht nix vom verstummen. Neinnein - Usermessage sollte niemals aussagen das man eine Message verstummen lässt - lediglich das diese durch XProfan anders behandelt wird.


Eine Usermessage wird von XProfan einfach gar nicht mehr behandelt! Das muß dann im XProfan-Programm selbst geschehen.
Das funktioniert in der Fensterprozedur ungefähr so:
- Eine Message kommt an
- Ist die Message im Array mit den Usermessages?
-- Wenn ja, dann setze die entsprechenden Systemvariablen und sorgen per ein Verlassewn des Waitinput
-- Wenn nein, dann soll sich Windows drum kümmern

Mit anderen Worten: Wenn das Programm nichts sinnvolles damit anfängt, verhallt die Message ungehört in den Weiten des Rams ... oder wo auch immer.

Saluto
Roland
 
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4
06.07.2007  
 




Answer


Topictitle, max. 100 characters.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Posting  Font  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Topic-Options

7.037 Views

Untitledvor 0 min.
Ju10.03.2017
Andreas Koch25.01.2012
Alexander Zur Hoerst18.01.2012

Themeninformationen



Admins  |  AGB  |  Applications  |  Autori  |  Chat  |  Informativa sulla privacy  |  Download  |  Entrance  |  Aiuto  |  Merchantportal  |  Impronta  |  Mart  |  Interfaces  |  SDK  |  Services  |  Giochi  |  Cerca  |  Support

Ein Projekt aller XProfaner, die es gibt!


Il mio XProfan
Private Notizie
Eigenes Ablageforum
Argomenti-Merkliste
Eigene Beiträge
Eigene Argomenti
Zwischenablage
Annullare
 Deutsch English Français Español Italia
Traduzioni

Informativa sulla privacy


Wir verwenden Cookies nur als Session-Cookies wegen der technischen Notwendigkeit und bei uns gibt es keine Cookies von Drittanbietern.

Wenn du hier auf unsere Webseite klickst oder navigierst, stimmst du unserer Erfassung von Informationen in unseren Cookies auf XProfan.Net zu.

Weitere Informationen zu unseren Cookies und dazu, wie du die Kontrolle darüber behältst, findest du in unserer nachfolgenden Datenschutzerklärung.


einverstandenDatenschutzerklärung
Ich möchte keinen Cookie