| |
|
|
Dietmar Horn | Ciao, ich bin circa folgende Merkwürdigkeit gestolpert.
Dieser Code funktioniert: KompilierenMarkierenSeparieren Bei dem folgenden Code erfolgt kein Neustart des Programmi im Interpretermodus (es müßte meiner Meinung nach jedoch wenigstens der Interpreter aufgerufen werden): KompilierenMarkierenSeparieren 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. |
|
|
| |
|
|
|
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. |
|
|
| |
|
|
|
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: KompilierenMarkierenSeparierenusermessages 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* |
|
|
| |
|
|
|
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... |
|
|
| |
|
|
|
| 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. |
|
|
| |
|
|
|
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 ▲ |
|
|
|