ProSpeed.dll
Wenn sie Fragen und Anregungen zu meiner ProSpeed DLL oder zu den Profan²-Sourcecodes und Demos haben, dann sind sie hier richtig. Auch neue Vorschläge sind jederzeit willkommen. Und bitte mit richtigem Namen und Email-Adresse einschreiben. Danke.

| Suchen
| Zurück zur Übersicht

Autor | Thema: Immer noch ganzer Screen...
Rolf Koch
| Datum:04.07.02 22:18 (webmaster@rokosoft.de) |
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
Moritz Kersten
| Datum:05.07.02 01:44 (IsNoMK@gmx.de) |
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 HDC's ?) 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
Rolf Koch
| Datum:05.07.02 09:39 (webmaster@rokosoft.de) |
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
Frank Abbing
| Datum:05.07.02 10:00 |
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 ProSpeed's 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
Rolf Koch
| Datum:05.07.02 10:02 (webmaster@rokosoft.de) |
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
Frank Abbing
| Datum:05.07.02 10:29 |
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
Frank Abbing
| Datum:05.07.02 10:35 |
Ich nochmal, hier ist das abschreckende Beispiel: Declare 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
Moritz Kersten
| Datum:05.07.02 14:27 (IsNoMK@gmx.de) |
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
Rolf Koch
| Datum:05.07.02 14:49 (webmaster@rokosoft.de) |
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
Frank Abbing
| Datum:05.07.02 15:23 |
Hi, super, das es jetzt funktioniert! Kannst du LoadFileCursor mal posten ? @Moritz: Inkompatibilitäten zwischen Profan's und ProSpeed's 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
Moritz Kersten
| Datum:05.07.02 20:15 (IsNoMK@gmx.de) |
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
Frank Abbing
| Datum:05.07.02 20:59 |
Hi Moritz ;-)) aber warum verwendest du denn 2 verschiedene Schriftarten bei den Zwischenräumen... Es geht auch ohne Forum-Codes... ;-)))) Gruß, Frank
Rolf Koch
| Datum:06.07.02 00:51 (webmaster@rokosoft.de) |
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 könnte. 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 über 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
Moritz Kersten
| Datum:06.07.02 04:52 (IsNoMK@gmx.de) |
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 könnte das sie waitinput verlassen. Habs bis jetzt immer ohne waitinput gemacht was der Systemauslastung natürlich nicht zugute kommt, aber mit einem Sleep Befehl hält sich das auch noch in Grenzen ! ich darf gleich arbeiten gehen... *heul* Moritz
Frank Abbing
| Datum: 06.07.02 13:05 |
Hi, in jede "Leerzeile" mußt du Chr$(160) einfügen, das ist die Tastenkombination >Shift Space<. Ziemlich heidnische Arbeitszeiten hast du aber *bedauer*... Gruß, Frank

| Zurück zur Übersicht

| Ein kostenloses WebMart Forum WebMart Homepage Tools kostenlos |