  | 
					
						Das deutsche QBasic- und FreeBASIC-Forum Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!   
						
						
					 | 
				 
			 
			 
	
		| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen   | 
	 
	
	
		| Autor | 
		Nachricht | 
	 
	
		Eastler_dart
 
  
  Anmeldungsdatum: 24.09.2005 Beiträge: 177 Wohnort: Baden-Würtemberg + Sachsen
  | 
		
			
				 Verfasst am: 11.10.2005, 16:54    Titel: stuerzt  CAllocate mein Programm??? | 
				     | 
			 
			
				
  | 
			 
			
				Hallo erst mal.
 
 
Brauch nochmal eure Hilfe.
 
 
Folgende Fakten:
 
Arbeite unter W98SE
 
un entsrechendem FreeBasic 014b
 
Screen 18,8
 
 (also 640x480 bei 8bit/256 Farben)
 
 
und dabei will ich Bildschirminhalte
 
sichern zum restaurieren.
 
Mit GET sichern,
 
Mit PUT restaurieren.
 
 
Und wie in anderem Thread schon befragt,
 
das ganze in einer SUB, ohne Eintraege
 
im Hauptteil des Basic-Codes.
 
 
Also Callocate ich Speicher mit:
 
 	  | Code: | 	 		  | STATIC AS INTEGER PTR BUScrSavePuffer(20):'Für 21 Sicherungen Buffers anlegen | 	  
 
Dimme ich ein Variablenarray mit 0-20 Felder, in denen die Adressen der Sicherungen liegen.
 
 
Auf Bedarf hole ich den Speicher mit:
 
 	  | Code: | 	 		  
 
    Breite%=BUB%(BuNr%)+2+BUShadowWidth%(BuNr%)
 
    Hoehe%=BUH%(BuNr%)+2+BUShadowWidth%(BuNr%)
 
    Groesse%=(  ((Breite%+2)*(Hoehe%+2)) \2)  +8
 
    IF ScrSavePuffer(BuNr%)=0 THEN ScrSavePuffer(BuNr%) = CALLOCATE( SIZEOF(INTEGER) * Groesse% )
 
 | 	  
 
In der Verzweiflung hab ich bereits bei Breite% und Hoehe% jeweils noch 2pixel dazugezaehlt
 
Auch in der Berechnung von Groesse% nochmals je weitere 2 Pixel. Und statt 4 Bytes, sogar 8 dazugezaehlt.
 
Es gab auch schon einen Versuch, da hab ich statt 8 volle 8000Bytes nochmal dazugezaehlt, immer noch Fehler.
 
An der Groesse scheint es nicht zu liegen.
 
 
Ach ja, Breite% * Hoehe% Teile ich durch 2, weil ich in Integer(=2Bytes) den Speicherbedarf errechne.
 
Denke mal, das ist so richtig.
 
 
 
Der Vollstaendigkeit halber noch das Sichern:
 
 	  | Code: | 	 		  
 
    GET ( BUX%(BuNr%)-1 , BUY%(BuNr%)-1 )-( BUX%(BuNr%)+Breite% , BUY%(BuNr%)+Hoehe%), ScrSavePuffer(BuNr%)
 
 | 	  
 
und das Restaurieren:
 
 	  | Code: | 	 		  
 
    PUT (BUX%(BuNr%)-1,BUY%(BuNr%)-1), ScrSavePuffer(BuNr%), PSET
 
    DEALLOCATE(ScrSavePuffer(BuNr%))
 
 | 	  
 
 
 
So, nun hoffe ich, hier erst mal alle relevanten Zeilen
 
aufgefuehrt zu haben.
 
 
Jetzt das Problem:
 
Kurz gesagt, Windows bricht das Programm per Fehlermeldung ab:
 
Programm verursacht einen Fehler durch eine ungueltige Seite
 
 
Aber nicht immer !
 
beim testen nach dem Erstellen lief unter (BuNr%) = 1,4,6,9,12,14 alles super,
 
mehrfach per Restaurieren bild wieder weg, wieder hin, wieder restaurieren, 
 
an anderer Position zeigen, wieder restaurieren,
 
alles ueberhaupt kein Problem.
 
Aber wie gesagt, nur bei bestimmten BuNr%-Werten. 
 
(stellt die jeweilige Array-Index-Nr dar,
 
unter der alle buttons nahezu identische Werte liegen haben)
 
 
Mach ich das gleiche z.B. mit BuNr%=0 oder 2 oder 3 oder 5,
 
sofort Programmabbruch. 
 
Dachte dann, Callocateter Speicher reicht nicht,
 
dann die (siehe oben) je 2 pixel auf Breite und Hoehe dazugenommen,
 
dass mehr Speicher reserviert wird.
 
Jetzt ploetzlich gehts mit ganz anderen Index-Nummern einwandfrei,
 
und die, die bisher gingen, stuerzen das Programm.
 
 
 
Hab mir auch schon die Adressen des Callocateten Speichers angeguckt,
 
jeweils die Groesse% dazugerechnet, ueberlappen sich nicht.
 
 
 
VERMUTUNG:
 
Die Adressen werden ja von FreeBasic festgelegt, das wird wohl so stimmen.
 
Aber bei Groesse koennt ich mir vorstellen, das sowas Computereigenes
 
dahintersteckt, wie z.B. Groessen muessen durch 16 teilbar sein, oder so,
 
ich meine halt, dass meine Groessenberechnung nicht den gesamten
 
benoetigten Speicher ermittelt und dadurch doch Ueberlappung.
 
Dabei sollten aber jede 2. Index-Nr betroffen sein, was ja so nicht 
 
der Fall ist.
 
So richtig ne Idee hab ich nun nicht mehr, vielleicht seht Ihr 
 
wo die Saege klemmt.
 
 
Viel Spaß beim gruebeln (ich habs aufgegeben) _________________ Kaum macht mans richtig, schon geht's | 
			 
		  | 
	 
	
		| Nach oben | 
		 | 
	 
	
		  | 
	 
	
		Eastler_dart
 
  
  Anmeldungsdatum: 24.09.2005 Beiträge: 177 Wohnort: Baden-Würtemberg + Sachsen
  | 
		
			
				 Verfasst am: 11.10.2005, 19:36    Titel:  | 
				     | 
			 
			
				
  | 
			 
			
				Ok Leute, Entwarnung
 
 
Habs selber gefunden    
 
 
wenn man zum Callocaten prüft, ob die ZielAdressvariable = 0 ist
 
gehts schief, wenn man zwischendurch DeAllocatet,
 
aber die ZielAdressVariable nicht mit "=0" wieder auf null setzt.
 
Beim nächsten Aufruf sollte neu CAllocatet werden, 
 
aber weil die (nicht mehr reservierte) Speicheradresse  immer
 
noch in der ZielAdressVariable stand, wurde nicht neu
 
Speicher reserviert.
 
 
Jetzt funzt das ganze einwandfrei!
 
 
Danke trotzdem für alles
 
 
Euer Eastler _________________ Kaum macht mans richtig, schon geht's | 
			 
		  | 
	 
	
		| Nach oben | 
		 | 
	 
	
		  | 
	 
	
		 | 
	 
 
  
	 
	    
	   | 
	
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
  | 
   
 
     |