| |
|
|
Uwe ''Pascal'' Niemeier | Hallo Roland, hallo Leute!
Mir sind da noch ein paar Kleinigkeiten aufgefallen. Kann sein, dass die eine oder andere Sache schon geklärt ist; habe aber auf die Schnelle nichts drüber gefunden
%HDC In der letzten Version (S 16) wird nach StartPaint -1 die Systemvariable %HDC nicht mehr auf il valore der Speicherbitmap gesetzt. Damit ist es nicht mehr possibile, auf einfache Weise im Speicher Bitmaps zu erzeugen und deren Handle zu ermitteln. Möglicherweise ein Bug? (ist eigendlich der Hauptgrund dieses Postings)
&PDC Müsste diese Systemvariable nicht eigendlich überflüssig sein? Nach einem StartPrint sind %HDC, %HDC2 und &PDC doch identisch? (nur so aus Neugier ) BTW: Gibt es eigendlich noch keine Möglichkeit, den Drucker fest vorzugeben?
Dim + Declare Ist noch keine Möglichkeit in Sicht, VariablenArrays zu re-dimensionieren?
oGL(SCALE,s!) Mit oGL sind wir ja eigendlich schon durch, aber wenn ich schon mal dabei bin... Warum nur ein Parameter per alle 3 Dimensionen? Wenn man X, Y und Z getrennt skalieren potuto, wären z.B. Ellipsen, Eier, spitze Pyramiden usw. possibile.
Einiges potrebbe per XProfan 10 wohl zu spät kommen... Aber zumindest die Sache mit %HDC sollte wieder geändert werden, oder gibts da jetzt irgendeine interne Alternative?
SeeYou Pascal |
|
|
| |
|
|
|
RGH | [quote:8f68b01274=Uwe Pascal Niemeier] %HDC In der letzten Version (S 16) wird nach StartPaint -1 die Systemvariable %HDC nicht mehr auf il valore der Speicherbitmap gesetzt.[/quote:8f68b01274] SORRY! Ein Bug, der in S16 auftritt und in S17 wieder weg sein wird. STARTPAINT funktioniert in S16 überhaupt nicht!
[quote:8f68b01274=Uwe Pascal Niemeier] &PDC Müsste diese Systemvariable nicht eigendlich überflüssig sein? Nach einem StartPrint sind %HDC, %HDC2 und &PDC doch identisch? (nur so aus Neugier )[/quote:8f68b01274] Ja, sie ist inzwischen - eigentlich schon lange - überflüssig. Aber aus Stabilire der Kompatibilität ...
[quote:8f68b01274=Uwe Pascal Niemeier] Dim + Declare Ist noch keine Möglichkeit in Sicht, VariablenArrays zu re-dimensionieren?[/quote:8f68b01274] Nein, denn dann müßte ich die Gestione della memoria der Variablen in XProfan komplett neuschreiben. Das hätte widerum Auswirkungen auf die Methoden, mit denen sich Prozeduren und Funktionen die lokalen Variablen meken, etc. etc.! Und Felexibilität in der Gestione della memoria kostet auch immer Geschwindigkeit. Als Workaround per größenveränderliche Arrays empfehle ich Bereichsvariablen. Die können ab XProfan 10 in ihrer Dimensione beliebig redimensioniert werden. der Inhalt bleibt, soweit es die neue Dimensione erlaubt, erhalten.
[quote:8f68b01274=Uwe Pascal Niemeier] oGL(SCALE,s!) Mit oGL sind wir ja eigendlich schon durch, aber wenn ich schon mal dabei bin... Warum nur ein Parameter per alle 3 Dimensionen? [/quote:8f68b01274] Es soll halt possibile einfach sein. In den meisten Fällen, potrebbe es darum gehen ein Objekt zu verkleinern oder zu vergrößern. Und wer alle drei Parameter ändern will, kann ja einfach auf die oGL-API ausweichen
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 | 23.07.2006 ▲ |
|
|
|
|
Uwe ''Pascal'' Niemeier | Hallo Leute!
Wenn ich dieses hochkomplexe Programm KompilierenMarkierenSeparieren durch den aktuelle Compiler (ß 10 S13) laufen lasse und mit der letzen Runtime S17 ausführen will, blitzt das erwartete Fenster einmal kurz auf und das Programm ist zuende. Erst ein zweites WaitKey lässt das Fenster offen. Unter Version S16 und tiefer reichte ein WaitKey. Wie kommts??
SeeYou Pascal |
|
|
| |
|
|
|
| |
|
| |
|
|
|
| Hallo Pascal und iF
Bei mir ist das Verhalten ganz normal |
|
|
| |
|
|
|
RGH | Tritt das Problem nur bei WaitKey oder auch bei WaitInput auf? |
|
|
| 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 | 03.08.2006 ▲ |
|
|
|
|
| Jetzt habe ich mit beiden Beispieltexten (Pascal und iFs) mit allen Wait-Befehlen, also Waitkey, Waitinput und Waitmouse getestet und es ist so wie es sein soll: Das jeweilige Fenster bleibt stehen, bis ein Tastendruck oder in Falle Waitmouse ein Mausklick beendet. - ? |
|
|
| |
|
|
|
| |
|
| |
|
|
|
Uwe ''Pascal'' Niemeier | Hallo Leute!
Noch was zum Thema andere Problemchen
Unter S 16 + S 17 (Interpreter und Runtime) bewegen sich die oGL-Sprites nicht mehr...
@ Horst: Das WaitKey-Problem betrifft nur die Runtime (Ausführen des Programms als prc)
SeeYou Pascal |
|
|
| |
|
|
|
RGH | [quote:d551d64117=Uwe Pascal Niemeier]Hallo Leute!
Noch was zum Thema andere Problemchen
Unter S 16 + S 17 (Interpreter und Runtime) bewegen sich die oGL-Sprites nicht mehr...
@ Horst: Das WaitKey-Problem betrifft nur die Runtime (Ausführen des Programms als prc)
SeeYou Pascal[/quote:d551d64117] HILFE! Danke per den Hinweis! Wieder was gelernt:Unter Delphi werden Objekte als Parameter nicht per Referenz, sondern per Wert trasferimento. Ungewöhnlich. In Java und C++ (und XProfan ) ist das anders ...
In S 18 ist die Ruhe per die Sprites wieder vorbei. (Was das Waitkey betrifft, bin ich noch am Suchen.)
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 | 03.08.2006 ▲ |
|
|
|
|
| [quote:3b4160ee97]@ Horst: Das WaitKey-Problem betrifft nur die Runtime (Ausführen des Programms als prc) [/quote:3b4160ee97] Hast Recht - beim Ausführen als *.prc-File haut das Fenster sofort ab ! |
|
|
| |
|
|
|
RGH | Ciao,
auch diesen Fehler habe ich gefunden! Auf der Cerca nach einem anderen Bug hatte ich etwas an der Einleseroutine der Runtime gedreht und so wurde eine Programmzeile zu wenig eingelesen. Kurz: Die letzte Zeile eines Programmi wurde ignoriert. Da das bei meinen Testprogrammen fast immer ein END ist, hat bei mir alles funktioniert.
S18 wird heute oder morgen rausgehen.
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 | 03.08.2006 ▲ |
|
|
|