| |
| |
|
| - Seite 1 - |
|
E.T. | Im Interpreter funktionierts:
SubProc Create.BigPicButton
Parameters Ziel&, Text$, PosX%, PosY%, Breite%, Hoehe%, Icon&
var BigPicButton& = @control("Button",Text$,$50012200+$2000000,PosX%,PosY%,Breite%,Hoehe%,Ziel&,100,%Hinstance)
Button_Refresh BigPicButton&, Icon&
Return BigPicButton&
EndProc
Proc Button_Refresh
Parameters Button&, Icon&
var Refresh_Button&=@control("Static","",$50000003,5,5,32,32,Button&,0,%Hinstance)
@Sendmessage(Refresh_Button&,$170,Icon& ,0)
EndProc
Windowstyle 16+8+2+512
Window 100,100
WindowTitle "ButtonTest" + " -- " + $ProfVer
UseIcon "A"
var Icon1& = @Create("hIcon","baum")
var Button& = @Create("BigPicButton",%HWnd,"Test- \nButton ",10,10,100,42,Icon1&)
waitinput
DeleteObject Icon1&
end
Compiliert gehts nicht:
Getestet mit XProfan 11.2 / X2-R1 |
|
| |
| Grüße aus Sachsen... Mario  WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 16.11.2010 ▲ |
|
| |
|
| |
| |
| - Seite 5 - |
|
|
 | E.T. (16.11.10)
Egal ob Fehlerhaft oder völlig richtig, wie kann ich mir dann noch sicher sein, das Interpreter und Compiler / Linker genau das gleiche mit meinem Quelltext machen ???
Es kann nicht Rolands/ XProfans Aufgabe sein eine Sicherheit zu geben bei falschprogrammierten Programmen/ Quelltexten.
Die Sicherheit beschränkt sich auf nicht-fehlerhafte Quelltexte - also alles was z.B. wie in der Hilfe beschrieben eingesetzt wird.
E.T. (16.11.10)
Dann könnte ja auch der Compiler, der was anderes übersetzt als der Interpreter, ein völlig und gänzlich fehlerfreies Programm so übersetzen, das was ganz anderes raus kommt.
Er übersetzt ja nichts anderes. Es geht ja um die Ausführung.
E.T. (16.11.10)
Also bleiben wir mal auf dem Boden der Tatsachen: Interpreter und Compiler/ Runtime sollten schon mit dem Quelltext das gleiche machen.
Ja, aber ich glaube Du verlangst ja das Interpreter und Kompilat bei logisch falsch programmierten Code auch noch selbes Falschverhalten verursachen und das ist zu viel verlangt. ^^ |
|
| |
| |
| |
|
|
| E.T. (16.11.10)
Es geht um ein- und dasselbe XProfan, um ein- und dasselbe Betriebssystem, um ein- und denselben PC !! Und es geht um um das unterschiedliche Verhalten von Interpreter und Compiler/ Runtime in genau dieser Umgebung !!!
Ich verstehe Dich schon - ist doch "egal" - das ändert doch am Problem nichts.
Du kannst gleiches Verhalten verlangen bei nicht-fehlerhaften Code.
Wenn Du logische Fehler einprogrammierst kannst nicht den erwarteten Ablauf erwarten - nicht bei Interpreter/ Kompilat/ Win98/ Win7 ... egal welcher Umgebung. |
|
| |
| |
| |
|
|
| Was Du machst ist:
Hallo Mercedes, im Handbuch steht das Auto fährt 200. Meins fährt garnicht mehr weil ich gegen einen Baum gefahren bin. Euer Handbuch lügt.
^^ |
|
| |
| |
| |
|
|
E.T. | Du verstehst mich eben nicht !!!
Es geht darum, das Interpreter und Compiler/ Runtime aus ein- und demselben Quelltext zwei verschiedene Sachen herstellen.
Wie soll ich 's denn noch beschreiben... |
|
| |
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 16.11.2010 ▲ |
|
| |
|
|
Dieter
Zornow | | Mal zur Ursache, ich sehe sie darin, dass Mario das Static mit zwei lokalen Variablen die in der Proc deklariert wurden erstellt hat. Der Interpreter erkennt, dass das Static erstellt wurde und zeigt es an. Die Runtime vergisst, das ein Static erstellt wurde, weil die Variablen lokal waren und dann nicht mehr gelten, da läuft doch ganz offensichtlich etwas falsch. Beide müssten gleich darauf reagieren, ob die Variablen gültig sind oder nicht. |
|
| |
| Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 16.11.2010 ▲ |
|
| |
|
|
E.T. | @Dieter: Liegt an der Windows-Version !!
Ich geb auf !!! |
|
| |
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 16.11.2010 ▲ |
|
| |
|
|
| @Dieter: Das muss XProfan erkennen in Runtime und Interpreter - stimme ich völlig zu!
E.T. (16.11.10)
@Dieter: Liegt an der Windows-Version !!
Die Reaktion Eurer (Deiner und Rolands) Fehlprogrammiererei hängt durchaus von der Windows-Version ab!  |
|
| |
| |
| |
|
|
Dieter
Zornow | und warum dann die die Diskussion  |
|
| |
| Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 16.11.2010 ▲ |
|
| |
|
|
E.T. | Was schreibe ich eigentlich die ganze Zeit ??
War wohl zu blöd, mich auszudrücken... |
|
| |
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 16.11.2010 ▲ |
|
| |
|
|
| | @Dieter: Die Diskussion war ja nicht ob XProfan nicht-deklarierte/ nicht-erreichbare Variablen erkennen sollte (was imho ohnehin klar ist) sondern das Kompilat und Interpreter nicht gleich reagieren können bei logisch-fehlerhaften Code. |
|
| |
| |
| |
|
|
| E.T. (16.11.10)
Was schreibe ich eigentlich die ganze Zeit ??
Gleiche Problem wie im obigen Code? |
|
| |
| |
| |
|
|
| Der Diskussion wegen:
Bei logisch-fehlerhaftem Code kann man nicht erwarten, dass Interpreter und Kompilat einheitlich reagieren.
Jemand nicht einverstanden?
iF (16.11.10)
Wenn Du mich fragst ist das aber aus mehreren Gründen kein XProfan-Bug sondern Ergebnis "unsachgemäßer" Programmierung. ^^
So ein Static auf nen Button ist halt "so" nicht gedacht und unterschiedliche Nachrichtenabwicklung könnte hier das unterschiedliche Verhalten verursachen. ^^
Offensichtlich habe ich die Ursache falsch eingeschätzt, tatsächlich lags (danke Dieter!) an nicht- oder "falsch"-deklarierten Variablen.
Vlt. hätte die Diskussion nicht stattgefunden. |
|
| |
| |
| |
|
(949)
Deutsch
English
Français
Español
Italia
