| |
|
|
- Page 1 - |
|
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 ▲ |
|
|
|
|
| |
|
- Page 2 - |
|
Frank Abbing | Hehe, ja, oder so. |
|
|
| |
|
|
|
| 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. |
|
|
| |
|
|
|
| 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. |
|
|
| |
|
|
|
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
iFDieses 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 |
|
|
|
|
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 ▲ |
|
|
|
|
| |
|
| |
|
|
|
| |
|
| |
|
|
|
RGH | iF
RGHUnd 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 ▲ |
|
|
|
| |
|
- Page 3 - |
|
|
| Du solltest am Destroywindow was drehen - winde Dich wie Du willst denn der obige Source (welcher übrigens bei mir nicht abstürzt) sollte auf jeden Fall fehlerfrei funktionieren. Solange der Source abstürzt ists per den den Laien ein Bug im Destroywindow. |
|
|
| |
|
|
|
Nico Madysa | Nunja, da im Dialogfensterstil 512 das Fenster eben nicht automatisch zerstört wird, sollte die Automatik in dem Fall ebenfalls abgeschaltet werden, oder? |
|
|
| |
|
|