| |
| |
|
| - 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 6 - |
|
|
Dieter
Zornow | | Ja ich, weil das kein logischer Fehler ist, gibts das überhaupt, bei Code der sequentiell abgearbeitet wird ? Wenn man auf den Kern geht ist es ein Variablenproblem. Kannst du mal ein Beispiel für einen logischen Fehler geben |
|
| |
| 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. | Und warum sollten Interpreter & Kompilat auf ein und demselbem System nicht auch gleich reagieren ??
Also ist doch bei Interpreter & Kompilat ein Unterschied, sonst würde es beides gleich reagieren... |
|
| |
| 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... | 17.11.2010 ▲ |
|
| |
|
|
 | @Dieter: mögl.log.Bug:
Kann aus xprofansicht weder als falsch oder richtig eingeschätzt werden.
@E.T.:
Darum kann auch nicht erwartet werden, dass obiger Code im Interpreter oder Kompilat gleich abläuft.
Es kann mal dies passieren, mal das, ... mal nichts.
So meine ich halt, dass bei fehlerhaftem Code (hiermit sind nur logische Fehler gemeint niemals Syntaktische!) man nicht erwarten kann, dass dieser in unterschiedlichen Umgebungen (egal ob Interpreter/ Kompilat/ Win98/ Win7...) gleich ausgeführt wird. |
|
| |
| |
| |
|
|
Dieter
Zornow | | Wenn 12345 ein Handle ist, ist es ja ok, im anderen Fall ist es kein logischer Fehler sondern schlicht und einfach Blödsinn. |
|
| |
| 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 ▲ |
|
| |
|
|
| Wieso Blödsinn wenn ich zuvor an die Adresse Opcode schreibe oder gar dort schon Opcode steht? Wie willst Du den Speicher hinter einer Adresse auf "logischen" Opcode testen?
Dieter Zornow (17.11.10)
Wenn 12345 ein Handle ist, ist es ja ok,
Eher nicht, dann gibts eher einen Absturz weil hinter dem Wert eines Handles nicht auch an selbiger Speicheradresse "nützlicher" Code stehen muss bzw. es sogar eher unwahrscheinlich ist. |
|
| |
| |
| |
|
|
Dieter
Zornow | | Wenn du das gemacht hast und dort eine Funktion oder so liegt, wo ist dann der logische Fehler ? |
|
| |
| 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 | | wenn ich eine Adresse aufrufe ohne zu wissen was da drin steht ist es doch Bödsinn oder wie würdest du das Bezeichnen, hat auf jeden Fall nichts mit Logik zu tun |
|
| |
| 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 ▲ |
|
| |
|
|
| Blödsinn <> Logik
darum gehts doch...
XProfan kann nicht wissen, ob der Call abstürzt - oder nicht - oder wie er abstürzt - also nicht erkennen/ wissen ob ein logischer Fehler vorliegt.
Darum kann man auch nicht erwarten, dass Interpreter und Runtime bei logischen Programmfehlern gleichermassen reagieren. |
|
| |
| |
| |
|
|
E.T. | | ...und wenns doch kein logischer ist... |
|
| |
| 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... | 17.11.2010 ▲ |
|
| |
|
|
E.T. | ...ein simpler Fehler bei der Variablenzuweisung, das sollte für Interpreter und Compiler nicht das Problem sein, dies GLEICH zu behandeln.
Nachtrag: selbst XPSE hat nix bemeckert... |
|
| |
| 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... | 17.11.2010 ▲ |
|
| |
|
|
Dieter
Zornow | | Wer einen Call ins Blaue schickt muss mit einem Absturz oder schlimmeres rechnen. Wenn ich das machen würde, könnte ich auch nie Profan dafür verantwortlich machen. Ich würde aber behaupten, dass bei einem Call ins Blaue bei Interpreter und Runtime das Ergebnis gleich ist, EIN ABSTURZ |
|
| |
| 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 ▲ |
|
| |
|
|
| Syntaktische - und das sollte eher _keine Diskussion sein - sollten natürlich angewarnt werden.
Kleiner Logischer:
Hier schreib ich 4 Byte zu weit übern Speicher... je nach Windows/ Sys/ Laune funktionierts oder mal nicht - oder maln ExitCode, oder .... |
|
| |
| |
| |
|
(946)
Deutsch
English
Français
Español
Italia
