| |
| |
|
| - Page 1 - |
|
 | Schade, so kann ich nicht an Speed@nim weiterarbeiten.
Klappt alles saugut, jedoch wie schonmal beschrieben,
wenn ich länger arbeite - also z.B. 3-5 Minuten male, so springt plötzlich mein Programm auf den ganzen Screen als ob es ein Bildschirmschoner hätte.
Mir ist es gerade passiert:
Speichern unter gewählt -
komischerweise keine Icons vor den vorhandenen Bitmaps (überhaupt keine Grafik) und 3sec später wieder ganzer Bildschirm mit meinem Programm.
Nachdem ich irgendwie den Speichernbutton von Savebmpdialog erreicht hatte, hatte ich mein original Programm wieder, aber hmmmm ???? >>>> dasselbe als Screenhintergrund. Sieht also nach Duplikat aufm Desktop aus.
Irgendetwas corre schief, aber was????
Ansonsten Danke per Euere Überlegung im Vorraus - wäre schade um das Programm, wenn ich es nicht weiterentwickeln potuto
Rolf |
|
| |
| |
| |
|
|
| |
| |
| - Page 1 - |
|
| Hi,
alles hab ich auch nicht verstanden.
Wenn du die profaninternen Bitmaps benutzt, geht die Dimensione der Bitmap circa das Limit von 2000 Pixel hinaus? Leider dürfen die Bitmaps nicht größer sein (warum eigentlich, die Systembitmaps und ProSpeeds auch dürfen bis 32768 Pixel breit sein). Da scheint mir noch ein Bug vorhanden zu sein.
Rolf, wenn ich mal was testen soll, dann sag Bescheid.
Saluto, Frank |
|
| |
| |
| |
|
|
| Hi ich nochmal
Aha - ich habe gerade festgestellt, daß es evtl. an etwas anderem liegen kann.
Ich nutze LoadFileCursor aus PRFELLOW. Vielleicht kennste diese Funktion ja.
Wenn ich mit der Maus circa den Arbeitsbereich gehe, so wird dieser aufgerufen.
Leider wird diese Funktion andauernd aufgerufen, wenn ich im Arbeitsbereich mit dem Cursor bin.
Also hab ich diesen Teil mal deaktiviert und es kam auch nach längerer Zeit nicht zu dem beschriebenen Effekt.
Also werde ich versuchen den Cursor nur bei Eintritt in den Bereich zu laden.
Vielleicht hilft es. Warum dies so ist - tja ?????
Rolf |
|
| |
| |
| |
|
|
| Hi,
ne, die Funktion hab ich noch nicht benutzt.
Ich hab aber festgestellt, das einige PrFellow Funktionen unter Windows XP fehlerhaft arbeiten, weil oft Bereiche mit Integern (auf 4er Offset-Basis) beschrieben werden, obwohl es LongInteger sein sollten. Das funktionierte unter Windows 98 tadellos, unter XP aber nicht mehr.
Ein gutes Beispiel ist: BevelBox()
Saluto, Frank |
|
| |
| |
| |
|
|
| Ich nochmal,
hier ist das abschreckende Beispiel:
KompilierenMarkierenSeparierenDeclare BevelRect#
Def DrawEdge(4) !"USER32","DrawEdge"
Proc DrawBevel
Parameters x%,y%,x1%,y1%,BorderStyle%
Dim BevelRect#,16
Word BevelRect#,0=x%
Word BevelRect#,4=y%
Word BevelRect#,8=@add(x%,x1%)
Word BevelRect#,12=@add(y%,y1%)
DrawEdge(%hdc,BevelRect#,BorderStyle%,15)
DrawEdge(%hdc2,BevelRect#,BorderStyle%,15)
Dispose BevelRect#
| 20.04.2004 ▲ | |
|
| |
|
|
| Hallo ihr beiden...
das Beispiel da oben lässt sogar mir einen kalten schauer circa den Rücken laufen, obwohl ich noch ein Integer Fanatiker bin .
@Rolf:
Also an Dim bereich#,10000 kann es keinen Fall liegen (würde ja ne tolle Exeption EAccess... Fehlermeldung bringen), ich meinte ob die Bitmaps auch grande genug sind. Frank hat ja auch schon darauf hingewiesen die Profan interne Speicherbitmap (mit mcls erzeugt) kann nicht größer als 2000x2000 Pixel sein.
Meinste also, es potuto an dem Profaninternen Mcopybmp u.s.w. liegen? - Ja das benutze ich.
Also ein Fehler bei MCopyBmp konnte ich bis jetzt noch nicht feststellen, ich meinte CopySizedBmp, verursachte Fehler bei mir, weiß jetzt aber nicht ob das nur die ProSpeed-Funktion verursacht oder auch der Profan interne Befehl.
Das es an LoadFileCursor liegt kann ich mir nicht vorstellen (auch wenn ich dich da entäuschen muß), obwohl man solch ein Fehler naturalmente auch vermeiden sollte
Moritz |
|
| |
| |
| |
|
|
| Tja Moritz,
es scheint aber die Cursorsache zu sein. Die ganze Zeit nach Auskommentieren dieser Geschichte kommt es nicht mehr zu diesem Problem.
Nee ich habe kein einziges Bild, welches solche extremen Größen hat.
Naja, ich warte mal ab, ob der Fehler doch irgendwann mal wieder erscheint. Ich glaub z.Zt. nicht mehr daran - hoffentlich.
Danke
Rolf |
|
| |
| |
| |
|
|
| Hi,
super, das es jetzt funktioniert!
Kannst du LoadFileCursor mal posten ?
@Moritz:
Inkompatibilitäten zwischen Profans und ProSpeeds Bitmap kann ich, glaube ich, ausschließen. Nach Hunderten von Tests und Versuchen kann ich das ruhigen Gewissens sagen
(He, so grande Zwischenräume im Text gehen ja doch...)
Saluto, Frank |
|
| |
| |
| |
|
|
| Ciao,
na super, wenns doch der Fehler war ist es ja ok. Hätte ich mir zwar nicht vorstellen können aber es sind ja meistens die Dinge die man am wenigsten vermutet, die die Fehler verursachen Ich weiß noch wie lange ich an dem @loadfile problem beim Pathfinder gegrübelt hatte, obwohl ich absolut unschuldig war, und ich einfach nicht drauf kam das ASPack die Fehlerquelle sein potuto !!!
Mir sind eigentlich auch nie Fehler bei den bmp befehlen aufgefallen, aber trotzdem war er da, kann aber auch sein das es schlecht programmiert wahr, hatte dann ja wie gesagt eine schnellere (und wohl bessere) Lösung gefunden.
Kann aber auch sein das es an meinem Rechner lag, hatte gerade einen neuen Detonator installiert der meinem System irgendwie nicht geschmeckt hat.
(Warum sollten keine grande zwischenräume gehen ???)
Moritz |
|
| |
| |
| |
|
|
| Hi Moritz  )
aber warum verwendest du denn 2 verschiedene Schriftarten bei den Zwischenräumen... Es geht auch ohne Foro-Codes... )))
Saluto, Frank |
|
| |
| |
| |
|
| |
| |
| - Page 2 - |
|
|
| So ------
und nun ......
hab ich wirklich mal was getrunken.
Mit meiner Frau 4 Flaschen Sekt - jjaaaaa kein Bier
Danke und wartet mal schön weiter, in meinem Urlaub werde ich wohl Speed@nim sehr weit entwickeln.
Achso:
Das Problem kommt sogar bei USECURSOR.
Wenn ich bloß trotz Waitinput den Arbeitsbereich (Bereich, welcher das Malen ermöglicht) abfragen potuto.
Wie hat das bloß Thomas damals hinbekommen, daß Tooltips trotz Waitinput (ohne Timersachen!!!) angezeigt werden.
Bedeutet:
Wenn ich Waitinput habe, wandelt sich mein Cursor nicht um, wenn ich circa einem bestimmten Bereich bin?
Dies geht nur ohne Waitinput oder per Timer.
Und dort liegt auch das Problem. Besser wäre mein Programm mit Waitinput und Aktionen, welche unabhängig von Waitinput reagieren.
Naja, dann
Euer Rolf |
|
| |
| |
| |
|
|
| Morgen zur frühen Stund...
@Frank: wie denn ?
@Rolf: Das Problem kenn ich nur zu gut, hat mich mehrmals frustriert das es dafür keine Lösung gibt, ideal wäre es wenn bestimmte Aktion so definieren potuto das sie waitinput verlassen. Habs bis jetzt immer ohne waitinput gemacht was der Systemauslastung naturalmente nicht zugute kommt, aber mit einem Sleep Befehl hält sich das auch noch in Grenzen !
ich darf gleich arbeiten gehen... *heul*
Moritz |
|
| |
| |
| |
|
|
| Hi,
in jede Leerzeile mußt du Chr$(160) einfügen, das ist die Tastenkombination >Shift Space<.
Ziemlich heidnische Arbeitszeiten hast du aber *bedauer*...
Saluto, Frank |
|
| |
| |
| |
|
(855)
Deutsch
English
Français
Español
Italia