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

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 (!)
Kompilieren Markieren Separieren

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

hier im Compilat und im Interpreter
Kompilieren Markieren Separieren

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

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

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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 dürfte! (Oder ist das so und ich weiß es nur nicht?) Dann könnte man kinderleicht in den eigenen Programmen eine eigene Untersprache anbieten. Plugins zum selberschreiben etc.

05.07.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Dietmar
Horn

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

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

Wenn ich die über 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 ...

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

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 (für Menschen bestimmt gut lesbar) geschrieben hast. Für Menschen gut lesbarer Code ist jedoch kein Qualitätsmerkmal für 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 für ineffektiv oder unhandlich halte.

Aber natürlich 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 Spaß mehr macht. (Bei 30min Kompilierzeit machts kein Spaß mehr!) Ich hätte da schon längst eine Unterteilungsmöglichkeit gefunden.

05.07.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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 Programmes ja auch das Programm beendet ... ganz wie ehedem in BASIC.

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

05.07.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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:
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

Es wird also sehrwohl unterschieden - also ist es eigendlich ja doch ein Bug wenn ich kritisch bin.

ganz wie ehedem in BASIC.

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

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

Ein DestroyWindow sendet eine Message, deren Folge das Zerstören des Hauptfensters ist, dessen Folge die Beendigung des Programmes 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.

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

05.07.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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 möglich 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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

rgh

Ein DestroyWindow sendet eine Message, deren Folge das Zerstören des Hauptfensters ist, dessen Folge die Beendigung des Programmes 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 Programmes haben - das macht keinen Sinn und ist auch nicht vorhersehbar.

05.07.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

rgh

Ein DestroyWindow sendet eine Message, deren Folge das Zerstören des Hauptfensters ist, dessen Folge die Beendigung des Programmes 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 Programmes 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 für künftige XProfan-Versionen.

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

05.07.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

12 3

►