XProfan

Deutsch

Dietmar
Horn

Hallo,
ich bin über folgende Merkwürdigkeit gestolpert.

Dieser Code funktioniert:
Kompilieren Markieren Separieren

declare tmp$
cls
tmp$ = upper$(Par$(0))
run tmp$
end

Bei dem folgenden Code erfolgt kein Neustart des Programmes im Interpretermodus (es müßte meiner Meinung nach jedoch wenigstens der Interpreter aufgerufen werden):
Kompilieren Markieren Separieren

declare tmp$
cls
tmp$ = upper$(Par$(0))
DestroyWindow(%HWnd)
run tmp$
end

Eigentlich habe ich doch den nullten Parameter (also den Dateinamen des eigenen Programmes) 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.

Gruß
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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

- Seite 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 für künftige XProfan-Versionen.

Ab damit auf deine ToDo-Liste...

05.07.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Dieses Set gibt es schon es heißt usermessage 2

Kompilieren Markieren Separieren

usermessages 2
Print Moment...
settimer 2000:waitinput:killtimer
destroywindow(%hwnd)

whileloop 40

    sleep 10

wend

var dlg&=createwindow(0,Oha?,100,100,640,480)
waitinput
end

05.07.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Frank
Abbing

Hehe, ja, oder so.

05.07.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Gleich kommt bestimmt ein WindowStyle 512 Argument. Hey aber darum gehts doch garnicht! Ich verstehe ja natürlich 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 dürfte 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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

Dieses Set gibt es schon es heißt 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ß. ;)

Gruß
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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

Dieses Set gibt es schon es heißt 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:
Kompilieren Markieren Separieren

usermessages 2
Print Moment...
settimer 2000:waitinput:killtimer
destroywindow(%hwnd)

whileloop 40

    sleep 10

wend

var dlg&=createwindow(0,Oha?,100,100,640,480)
waitinput
end

nicht funktionieren soll.

Da musst Du ran Roland - dad nutzt Dir janix.

Schau einfach wie der Thread hier benannt wurde und schau wer den Thread erstellt und so benannt hat. Das sollte doch völlig ausreichen um zu erkennen ob man es nur mit einer von Dir aus fehlenden aber nötigen Erläuterung zu tun hat - oder mit einer Sache die eben nicht für den normalen XProfaner nachvollziehbar ist.

06.07.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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 für 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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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.

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.

Gruß
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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

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 für 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.

Gruß
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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

◄

123

►