Deutsch
Forum

Immer noch ganzer Screen...

 
- Seite 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 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
 
20.04.2004  
 



 
- Seite 1 -


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
 
20.04.2004  
 



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
 
20.04.2004  
 



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
 
20.04.2004  
 



Ich nochmal,
hier ist das abschreckende Beispiel:
KompilierenMarkierenSeparieren
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
 
20.04.2004  
 



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
 
20.04.2004  
 



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
 
20.04.2004  
 



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
 
20.04.2004  
 



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
 
20.04.2004  
 



Hi Moritz )

aber warum verwendest du denn 2 verschiedene Schriftarten bei den Zwischenräumen... Es geht auch ohne Forum-Codes... )))

Gruß, Frank
 
20.04.2004  
 



 
- Seite 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 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
 
20.04.2004  
 



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
 
20.04.2004  
 



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
 
20.04.2004  
 




Antworten


Thementitel, max. 100 Zeichen.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Beitrag  Schrift  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Themenoptionen

8.213 Betrachtungen

Unbenanntvor 0 min.
Andreas Koch14.06.2013
Julian Schmidt15.09.2012

Themeninformationen

Dieses Thema hat 1 Teilnehmer:

unbekannt (15x)


Admins  |  AGB  |  Anwendungen  |  Autoren  |  Chat  |  Datenschutz  |  Download  |  Eingangshalle  |  Hilfe  |  Händlerportal  |  Impressum  |  Mart  |  Schnittstellen  |  SDK  |  Services  |  Spiele  |  Suche  |  Support

Ein Projekt aller XProfaner, die es gibt!


Mein XProfan
Private Nachrichten
Eigenes Ablageforum
Themen-Merkliste
Eigene Beiträge
Eigene Themen
Zwischenablage
Abmelden
 Deutsch English Français Español Italia
Übersetzungen

Datenschutz


Wir verwenden Cookies nur als Session-Cookies wegen der technischen Notwendigkeit und bei uns gibt es keine Cookies von Drittanbietern.

Wenn du hier auf unsere Webseite klickst oder navigierst, stimmst du unserer Erfassung von Informationen in unseren Cookies auf XProfan.Net zu.

Weitere Informationen zu unseren Cookies und dazu, wie du die Kontrolle darüber behältst, findest du in unserer nachfolgenden Datenschutzerklärung.


einverstandenDatenschutzerklärung
Ich möchte keinen Cookie