Italia
Foro

Merkwürdigkeit bei DestroyWindow

 

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  
 




Christian
Eichler
Ich hab Profan 6.6, du XProfan 10, bei mir passiert das gleiche --> wird wohl kein Bug sein !

---> DestroyWindow(%HWnd) beinhaltet ein end , aber anscheinend nur im Interpreter - Modus ... wo ist da der Sinn ???


Als Compilat funktionieren komischerweise beide Varianten.


Öhm, naja, aber beide wird man nicht mehr los !


mit der Stringvariablen gerettet,


Das bringt leider nicht viel, selbst wenn ich das Programm wie folgt im Interpreter ausführe, wird nicht die cmd geöffnet ! Im Compilat allerdings schon (!)
KompilierenMarkierenSeparieren
hier im Compilat und im Interpreter
KompilierenMarkierenSeparieren
--> bei dem DestroyWindow(%HWnd) wird das Programm im Interpreter beendet, beim Compilat allerdings nicht !

Vll. soll das ein Schutz davor sein, dass du den Interpreter in mehreren Instanzen geöffnet hast, ohne es zu merken !?
mfg Christian
 
Debian Lenny, Intel Celeron 2,8 Ghz, 768 MB Ram && Win XP Pro, Intel C2D 1,66Ghz, 2 GB Ram ... PROFAN² 6.6
05.07.2007  
 



Nein kein Schutz sicher ein Bug - ich kann mir vorstellen das wm_close oder wm_destroy in der profan.exe-WProc das Exit einleitet - aber dazu muss und kann sich eigendlich nur Roland äußern.

Ich sags ja immer wieder: Abschaffung des Interpretermodi! Und wer den trotzdem nutzt... selbst schuld. ;) Es ist praktisch unmöglich das beide Varianten (IMode und ExeMode) exakt gleich funktionieren. Also wofür dann bitte den IMode wenn man doch eh immer die EXE weitergibt - und nicht die Profan.Exe und die Prf!

Dann lieber immer gleich richtig als exe testen und {$cleq} nutzen.

Den Interpretermodus kann man jedoch ziemlich gut als evaluator nutzen. Hierbei wäre es nun toll wenn man z.B. die Profan.Exe einer jeden Version einfach weitergeben potrebbe! (Oder ist das so und ich weiß es nur nicht?) Dann potuto man kinderleicht in den eigenen Programmen eine eigene Untersprache anbieten. Plugins zum selberschreiben etc.
 
05.07.2007  
 




Christian
Eichler
Ich persönlich muss sowieos sagen, dass ich es mir abgewohnt hab, den Interpretermodus zu verwenden, da ich dann schon oft, das Problem hatte, dass mein Programm im Interpreter funktionniert und im Compilat dann eben nicht.
Daher compiliere ich mein Programm gleich komplett und dann weiß ich auch sicher, wie und was etwas funktionniert.

mfg !
 
Debian Lenny, Intel Celeron 2,8 Ghz, 768 MB Ram && Win XP Pro, Intel C2D 1,66Ghz, 2 GB Ram ... PROFAN² 6.6
05.07.2007  
 




Dietmar
Horn
Die Unterschiede zwischen Interpreter- und Compilermodus nerven mich schon seit Jahren.

Grundsätzlich immer erst Compilieren und dann Ausführen, das mag per Leute ausreichen, die lediglich Dreizeiler, Demos und kleinere Programme schreiben.

Wenn ich die circa 150000 Zeilen meines XProfan-Managers compiliere, dann dauert das auf meinem schnelleren XP-Rechner fast 20 Minuten. Erstelle ich ein komplettes Update (also einschließlich Inno-Setup compilieren), dann warte ich inzwischen fast eine halbe Stunde, bis alles fertig ist.

In dem einen unserer PC-Kabinette mit 333 MHz-Rechnern und 64 MB RAM kann ich an diesem Programm gar nicht mehr arbeiten, denn da dauert nur das Compilieren des XProfan-Codes schon fast 2 Stunden ...

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  
 



Ok ich formuliere es mal so:

150.000 Zeilenprogramme können deutlich mächtiger sein als z.B. der XProfan-Manager. Ich will um Gotteswillen nicht Deine Programmerkünste in Frage stellen aber ich meine das Du den Code sehr unkomprimiert (per Menschen bestimmt gut lesbar) geschrieben hast. Für Menschen gut lesbarer Code ist jedoch kein Qualitätsmerkmal per eine funktionierende Software welche ohne Code weitergegeben wird. Unterteile Deine Riesenprogramme doch besser (jetzt insgesammt meine ich - also nicht nur beim XProfanmanager) in Aufgabengebiete und hau nicht alles in einen Source. Seit dem die Prozesskommunikation erfunden ist (spätestens mit SendMessage) ist das eigendlich auch sehr üblich und Gang und Gebe.

Ich biete Dir gerne an den Source nach dem Prinzip zu optimieren welches ich hier eben angesprochen habe. Einfach weil 4 Augen mehr sehen als 2.

Ich will sagen - ich schreibe auch Riesenprogramme - kein Quelltext jedoch hat mehr als 50.000 Zeilen weil ich selbst den Code sonst per ineffektiv oder unhandlich halte.

Aber naturalmente kann es trotzdem Gründe geben weshalb ein Source mal >100t Zeilen haben kann. Aber ich würde ja irre werden wenn ich Codes programmieren müsste welche derart riesig sind dass das Handling keinen Divertimento mehr macht. (Bei 30min Kompilierzeit machts kein Divertimento mehr!) Ich hätte da schon längst eine Unterteilungsmöglichkeit gefunden.
 
05.07.2007  
 




RGH
... um zum Thema zurückzukommen:

DestroyWindow(%Hwnd) sendet eine Message, die das Hauptfenster zerstört. Das zerstören des Hauptfensters kommt der Programmbeendigung gleich. Das ist im Interpreter genauso wie in der fertigen EXE, ...

...aber in der EXE kommt die Message aufgrund ihres erhöhten Tempos (ich erinnere hier auch an die seltenere Abfrage des Messageloops) erst nach dem Run-Befehl an.

Außerdem rate ich dringenst davon ab, das Hauptprogramm brutal und ohne Rücksicht auf Speicherverluste mit einem DestroyWindow(%HWnd) zu beenden, sondern dazu entweder den Befehl End zu benutzen oder eben Run, der nach dem Start des anderen Programmi ja auch das Programm beendet ... ganz wie ehedem in Di base.

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
05.07.2007  
 




Das zerstören des Hauptfensters kommt der Programmbeendigung gleich. Das ist im Interpreter genauso wie in der fertigen EXE, ...


Hiernach müsste aber es keinen Unterschied machen ob ich ein End setze oder ein Destroywindow - tut es aber:
KompilierenMarkierenSeparieren
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

ganz wie ehedem in Di base.


XProfan ist zum Glück kein Basic - es ist syntaktisch zwar an Basic angelehnt aber trotzdem zum Glück nicht Basic. Auch das PiCoPrinzip spricht nicht per Basic denn es gibt Basics mit Kompilern welche nativen Code erzeugen und es gibt Nicht-Basics welche PiCo erzeugen.

Ich meine nur - XProfan ist ja kein altes Ding sondern orientiert sich ja an den aktuellen Gegebenheiten. So betrachtet ist es aber gänzlich falsch das destroywindow (und sei es die api) auf %hwnd die Anwendung beendet. Es sollte als ganz normale Message durchgehen - ich finde so wird es auch erwartet - und das ist letztendlich mehr entscheidend als ganz wie ehedem in Di base {es mal war - als es aber destroywindow nicht gab} .

Hey ich meine hier gehts um meine Lieblingsprogrammiersprache - die soll funktionieren wie es sich gehört. (Und destroywindow ist nunmal nicht terminateprocess oder end) *g*
 
05.07.2007  
 




RGH
Ein DestroyWindow sendet eine Message, deren Folge das Zerstören des Hauptfensters ist, dessen Folge die Beendigung des Programmi ist.
Ein END wirkt sofort und sorgt dafür, daß der Speicher aufgeräumt, keine weitere Programmzeile mehr gelesen und das Hauptfenster mittels Message zerstört wird. Und da die Abarbeitung des Codes beendet wurde, ist es egal wie lange die Message unterwegs ist und wo der Postzusteller zwischendurch noch einkehrt.

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
05.07.2007  
 




Frank
Abbing

So betrachtet ist es aber gänzlich falsch das destroywindow (und sei es die api) auf %hwnd die Anwendung beendet. Es sollte als ganz normale Message durchgehen - ich finde so wird es auch erwartet


Ich sehe das aber genauso. Es sollte possibile sein, sein Programm weiter zu führen, wenn das Hauptfenster auch beendet ist. Immerhin gibt es Programme, die gar kein Fenster erstellen, die laufen ja auch ohne dieses.
WM_DESTROY ist eine von vielen Message, kein Programmabbruch...
 
05.07.2007  
 



rgh

Ein DestroyWindow sendet eine Message, deren Folge das Zerstören des Hauptfensters ist, dessen Folge die Beendigung des Programmi ist.


Ja klar das habe ich ja sofort verstanden und ich persönlich bin eben der Meinung das es sich hierbei um einen Bug handelt - auch dann - wenn das Verhalten einfach erklärbar ist. Destroywindow darf halt nicht zur Folge die Beendigung des Programmi haben - das macht keinen Sinn und ist auch nicht vorhersehbar.
 
05.07.2007  
 




RGH
iF

rgh

Ein DestroyWindow sendet eine Message, deren Folge das Zerstören des Hauptfensters ist, dessen Folge die Beendigung des Programmi ist.


Ja klar das habe ich ja sofort verstanden und ich persönlich bin eben der Meinung das es sich hierbei um einen Bug handelt - auch dann - wenn das Verhalten einfach erklärbar ist. Destroywindow darf halt nicht zur Folge die Beendigung des Programmi haben - das macht keinen Sinn und ist auch nicht vorhersehbar.


Das ist kein Bug, sondern wurde ganz bewußt so schon in die allererste Profan-Version eingebaut. Das führt unter anderem dazu, daß das Programm durch Schließen des Programmfensters beendet wird, so wie man es von anderen Windowsprogrammen gewohnt ist, ohne daß man dafür auch nur eine Zeile Code programmieren müßte.

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.

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
05.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.064 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