| |
| |
|
| - 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 7 - |
|
Rolf
Koch | Nein iF genau soll es nicht, nur es soll nicht im Interpreter sagen ist OK und in der Exe dann aufeinmal meckern. Darum geht es eigentlich. Beide sind ein und dasselbe und dürfen nicht abweichen. 
Darum ging es ja eigentlich hier im Thread. Eigentlich unabhängig von Fehlern. So muss leider ins Bett - gähhhhn - Nächtle ^^ |
|
| |
| |
| |
|
|
 | Dieter Zornow (17.11.10)
nein, aber Interpreter und Runtime kämen zum gleichen falschen Ergebnis
Bei einem logischen Programmfehler gibt es aber nicht unbedingt DAS oder das GLEICHE Ergebnis und das hat ja nichts damit zu tun ob man es "besser gewusst" hat oder nicht.
Wenn ich mich "verprogrammiere" kann ich eben NICHT von ausgehen das es ein "geordnetes" Ende nimmt - sonst hätte ich mich ja nicht verprogrammiert. ^^
Tatsächlich wissen wir doch aber alle, reichts oft, nur 1 Byte sich zu verschieben - um einen lecker Absturz hinzulegen.
Abzuverlangen das XProfan nun aber solche logischen Fehler erkennt - vlt. auch noch erkennt obs Absturzfehler sind (bzw. die Folgen erkennt) ist nett gesprochen "unfair". |
|
| |
| |
| |
|
|
| | Darum kann man technisch gesehen schlecht abverlangen, dass bei logischen Programmfehlern Interpreter und/ oder Runtime und/ oder Win7 und/ oder Win98 und/ oder Irfanviewer "geordnet" oder (wie "verlangt") "GLEICH" reagieren denn das kann man nur bei zu erwartendem Verhalten und dies wäre z.B. in der Hilfe beschrieben zu den jeweiligen Befehlen/ Funktionen. ^^ |
|
| |
| |
| |
|
| |
| |
| - Seite 8 - |
|
|
Dieter
Zornow | | Das verlangt ja auch kein Mensch, ist auch nicht das eigentliche Thema, dass sowas erkannt werden soll, ist ja auch zu weit hergeholt. |
|
| |
| Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 17.11.2010 ▲ |
|
| |
|
|
| Dieter Zornow (17.11.10)
Das verlangt ja auch kein Mensch, ist auch nicht das eigentliche Thema, dass sowas erkannt werden soll, ist ja auch zu weit hergeholt.
Eben - nur wie erkläre ich das nun Rolf und E.T. weniger vergeblich als auf diesen 8 Seiten...  ? |
|
| |
| |
| |
|
|
Dieter
Zornow | | Ich denke du brauchst nichts zu erklären, da der Ausgangspunkt die Unterschiede zwischen Interpreter und Runtime sind, die aus welchen Gründen auch immer bestehen. Man kann nicht auf äußere Umstände oder auf sowas abheben, da das Verhalten von beiden ja immer gleich ist, heißt in diesem Fall, das Static wird im einen immer angezeigt im anderen immer nicht, ist also nichts zufälliges dabei. So dass Unterschiede in der Abarbeitung von Code tatsächlich bestehen, warum weiß nur Roland. |
|
| |
| Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 17.11.2010 ▲ |
|
| |
|
|
| Ja das ist doch aber klar und wir waren meiner Meinung nach ja darüber auch längst hinweg bis hin dazu, dass ich es halt als "unfair" verstehe abzuverlangen, dass Interpreter und Runtime bei fehlerhaften Codes gleich "abstürzen" sollen.
Ich mein ich habs auf Seite 1 bereits...
iF (16.11.10)
E.T. (16.11.10)Sollte denn aber nicht alles, was im Interpreter funzt, auch fertig genau so aussehen ???
Wenn überhaupt dann aber bei nicht-fehlerhaften Programmen. ^^
Um Syntaxfehler gings dabei (mehr oder weniger)-offensichtlich nicht, ich denke da sind wir uns alle einig das diese von Interpreter und Kompiler anzumeckern sind.
Bezüglich der logischen Fehler gings mir persönlich halt darum darzustellen, dass man bei diesen Fehlern eben nicht abverlangen kann, dass das Ablaufergebnis GLEICH ist (z.B. bei Interpreter/ Runtime)...
Dazu fragte ich wer damit nicht "Einverstanden" ist. ^^ |
|
| |
| |
| |
|
|
Dieter
Zornow | | Du hast ja selbst die Wiki Erklärung von logischen Fehlern beschrieben, insofern ist das kein logischer Programmfehler, denn wenn ich falsch an eine Sache herangehe oder einen falschen Algorithmus verwenden kommt am Ende ein falsches Ergebnis heraus, in diesem Fall bei beiden, was dann menschliches Versagen ist. Das Ergebnis ist dann immer falsch und nicht vage oder zufällig, denn das Programm soll ja egal wo es läuft das gleiche machen, wenn ich aus Unwissenheit einen Absturz provoziere stürzt das Programm in jeder Form ab.. |
|
| |
| Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 17.11.2010 ▲ |
|
| |
|
|
| Bei logischen Programmfehlern kann man Deiner Meinung nach erwarten, dass Interpreter und Kompilat gleichermassen reagieren?
Vielleicht mache ich 2 Schritte wenn ich behaupte, logische Progammfehler enden im Ablaufchaos und ein Solches wird in verschiedenen Umgebungen eher nicht gleiche Reaktionen hervorrufen. |
|
| |
| |
| |
|
|
Dieter
Zornow | | Ich kann mir im Programmcode keine logischen Fehler vorstellen, ich weiß echt nicht was das sein könnte und weiß außer Blödsinn zu programmieren auch kein echtes Beispiel. Es gibt undefinierte Zustände von Variablen usw. die etwas auslösen können, was anderes fällt mir nicht ein. Wobei das für mich auch keine logischen Fehler sind. |
|
| |
| Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 17.11.2010 ▲ |
|
| |
|
|
| Musste eh nochmal unter die Dusche...
Ein logischer Fehler ists z.B. wenn Du...
... ein Control 2 Mal zu zerstören versuchst
... mehr Speicher kopierst als das Ziel gross ist
... auf ein dc malst wo keins mehr ist
... in einer Schleife zu weit zaehlst
... eine Funktionadresse falsch berechnest
... nicht beachtest wo hex statt dec gewandelt wird
... den stack nicht leerst und sich speicher auffuelt...
... ein Static auf ein Button setzt wenns so nicht explizit gedacht...
... alles was man halt falsch machen kann und auch mindestens pro zeile gefühlt 12 mal falsch macht.
Nach dem Duschen bin ich jetzt für mich zu folgender Meinung gelangt:
Hierbei kein XProfan-Bug, auch nicht das es im Interpreter anders als im Kompilat reagiert.
Begründung: Es ist kein XProfan-Bug, wenn fehlende Variablendeklarationen nicht angemeckert werden, wenn XProfan nicht verspricht, jede fehlende Variablendeklaration anzumeckern. Somit kann man auch nicht davon ausgehen, dass eine fehlende Variablendeklaration angemeckert wird und muss selbst darauf achten Variablen korrekt zu deklarieren. Diese Obacht fehlte hier, daraus entstand ein Quellcode mit logischem Programmierfehler der unerwarteten Ablauf verursachte und bei einem logischen Programmierfehler kann man nicht davon ausgehen, dass der Ablauf sich in verschiedenen Umgebungen/ Systemen (bzw. und/ oder bei Interpreter und Kompilat) gleichermassen auswirkt.
Bei einem Quelltext jedoch der ala XProfan "fehlerfrei" ist sollte das Kompilat und das interpretierte Programm selbstverständlich scheinbar ziemlich gleich ablaufen - aber ein fehlerfreier Quelltext lag hierbei eben nicht vor.
Jetzt aber schnell ins Bett... ^^ |
|
| |
| |
| |
|
|
Rolf
Koch |
Tatsächlich wissen wir doch aber alle, reichts oft, nur 1 Byte sich zu verschieben - um einen lecker Absturz hinzulegen.
Ahh - das kapiere ich jetzt und mir ist klar worum es jetzt geht. Der Satz hat mich überzeugt. |
|
| |
| |
| |
|
(540)
Deutsch
English
Français
Español
Italia
