| |
| |
|
 | 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 läuft schief, aber was????
Ansonsten Danke für Euere Überlegung im Vorraus - wäre schade um das Programm, wenn ich es nicht weiterentwickeln könnte
Rolf |
|
| |
| |
| |
|
|
| Hallöchen zur späten Stunde,
hab zwar nur die hälfte von dem da oben verstanden (warst du betrunken als du das geschrieben hat ), hört sich aber auf jeden Fall nach ein Bitmapproblem an.
Benutzt du noch andere Speicherbitmaps als die von der ProSpeed erzeugten ? (wenn ja, wie ermittelst du die HDCs ?)
Sind die Speicher-Bitmaps auch groß genug ?
Du benutzt bestimmt auch copysizedbmp, da scheint es irgendwie auch noch ein problem zu geben. Hatte ich bei der Lupe vom Pathfinder, verursachte Schlieren auf dem ganzen Bildschirm, wenn man ein Dialog geöffnet hatte war wieder alles ok und das Problem trat danach dann nicht mehr auf.
Hatte dann eine schnellere Lösung gefunden, die hatte zur Folge das der Grafikfehler nicht mehr auftrat (schwein gehabt )
Gib bloß nicht auf, hatte beim Pathfinder teilweise auch Probleme die mich in den wahnsinn trieben weil es keine Programmierfehler gab (ich sag nur @loadfile(), Frank ). Früher oder Später findet man doch fast immer eine Lösung, am besten lässt du das Programm mal für ein paar Tage ruhen, hilft meistens weiter und gibt einen wieder neue Motivation !
der nachtschichtende Moritz |
|
| |
| |
| |
|
|
| Hi Moritz
Nee Alkohol hatte ich lange nicht mehr zu mir genommen
Vielleicht hat es ja daran gelegen.
War vielleicht zu sauer (weil der Rest genial läuft), um noch irgendwie sauber zu schreiben
Aber trotzallem haste das Problem verstanden (hatte es ja auch schon mal angesprochen).
Meinste also, es könnte an dem Profaninternen Mcopybmp u.s.w. liegen? - Ja das benutze ich.
Oder liegt es an
Dim bereich#,10000 (zu wenig?)
Hauptsache ich hab mal wieder nen Anhaltspunkt - Danke Dir.
Und falls dies nicht verständlich sein sollte: Es ist morgen und ich trinke Kaffee - und hab URLAUB JUCHUUU
Bis dann
Rolf |
|
| |
| |
| |
|
|
| Hi,
alles hab ich auch nicht verstanden.
Wenn du die profaninternen Bitmaps benutzt, geht die Größe der Bitmap über 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.
Gruß, 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 über 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()
Gruß, 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#
EndProc
So eine Programmierung kann nicht gutgehen...
Gruß, Frank |
|
| |
| |
| |
|
|
| Hallo ihr beiden...
das Beispiel da oben lässt sogar mir einen kalten schauer über 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 groß 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 könnte 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 natürlich 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 große Zwischenräume im Text gehen ja doch...)
Gruß, Frank |
|
| |
| |
| |
|
|
| Hallo,
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 könnte !!!
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 großen zwischenräume gehen ???)
Moritz |
|
| |
| |
| |
|
|
| Hi Moritz  )
aber warum verwendest du denn 2 verschiedene Schriftarten bei den Zwischenräumen... Es geht auch ohne Forum-Codes... )))
Gruß, Frank |
|
| |
| |
| |
|
(851)
Deutsch
English
Français
Español
Italia