| 
				
					|  | 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 |  
		| Jojo alter Rang
 
  
 Anmeldungsdatum: 12.02.2005
 Beiträge: 9736
 Wohnort: Neben der Festplatte
 
 | 
			
				|  Verfasst am: 20.12.2013, 00:11    Titel: |   |  
				| 
 |  
				|  	  | TimesChange hat Folgendes geschrieben: |  	  | Frage dazu: Kann mir jemand sagen, ob das Grafikformat  unter 64-Bit Windows das selbe ist (Palette mit 4 Bits / pixel)? Sinn und Zweck der ganzen Übung ist ja, dass das Programm auch künftig z.B. unter Windows 7 / 8 /... in 64-Bit-Version läuft.
 
 | 
 Ja, das hat überhaupt nichts mit der Bittigkeit des Systems zu tun. Die Konsole ist jetzt ja nicht gerade ein Feature, das super toll ausgebaut wird von Version zu Version, sondern bleibt kompatibel mit alten Terminals.
 _________________
 » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 
  |  |  
		| Nach oben |  |  
		|  |  
		| TimesChange 
 
 
 Anmeldungsdatum: 20.11.2013
 Beiträge: 85
 
 
 | 
			
				|  Verfasst am: 20.12.2013, 00:33    Titel: |   |  
				| 
 |  
				| OK, soweit klar.  	  | Jojo hat Folgendes geschrieben: |  	  | ... Die Konsole ist jetzt ja nicht gerade ein Feature, das super toll ausgebaut wird von Version zu Version... | 
 
 Schade. Ich hatte gehofft, das wird das neue Kernstück von Windows 9, weg mit den blöden Kacheln und Fenstern, back to the roots und so...
   
 Jetzt ganz ernsthaft noch eine Anschlussfrage dazu:
 
 Spricht irgendetwas dagegen, das Programm in Konsolenmodus laufen zu lassen, speziell in Bezug auf die "Zukunftstauglichkeit"?
 Das Programm verrichtet bei mir seit mindestens 1993 (und ich habe ganz vergessen, das 20-jährige Jubiläum zu feiern...) seine Dienste, ist im Kern unverändert, und wurde nur gelegentlich bei Bedarf angepasst. Es wäre also schön, wenn es mich auch die nächsten 20 Jahre begleiten könnte
   Ich "brauche" nicht mehr als den Konsolenmodus für diese Zwecke, es wäre nur ungeschickt, wenn ich jetzt mein Programm darauf umbaue, und in paar Jahren gibt's keine mehr.
 
 Grüße
 Rainer
 |  |  
		| Nach oben |  |  
		|  |  
		| grindstone 
 
 
 Anmeldungsdatum: 03.10.2010
 Beiträge: 1283
 Wohnort: Ruhrpott
 
 | 
			
				|  Verfasst am: 20.12.2013, 02:55    Titel: |   |  
				| 
 |  
				| Da meines Wissens selbst die schickste und modernste Bedienoberfläche im Innersten immer noch auf DOS und die Kommandozeile aufsetzt (auch wenn Mickysoft sich alle Mühe gibt, das zu verbergen), dürfte uns die Konsole wohl noch eine ganze Weile erhalten bleiben. 
 
 Du hast tatsächlich Recht! Mir ist das in den ganzen Jahren noch nie aufgefallen, weil ich sowieso einen schwarzen Hintergrund habe. Und die Zeichenfarbe wird ja korrekt dargestellt. Sachen gibt's... 	  | Zitat: |  	  | Im Konsolenmodus ist das mit SCREEN erhaltene Farbattribut nur ein 8-Bit-Wert | 
   
 Gruß
 grindstone
 _________________
 For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!
 |  |  
		| Nach oben |  |  
		|  |  
		| Jojo alter Rang
 
  
 Anmeldungsdatum: 12.02.2005
 Beiträge: 9736
 Wohnort: Neben der Festplatte
 
 | 
			
				|  Verfasst am: 20.12.2013, 09:34    Titel: |   |  
				| 
 |  
				|  	  | grindstone hat Folgendes geschrieben: |  	  | Da meines Wissens selbst die schickste und modernste Bedienoberfläche im Innersten immer noch auf DOS und die Kommandozeile aufsetzt (auch wenn Mickysoft sich alle Mühe gibt, das zu verbergen), dürfte uns die Konsole wohl noch eine ganze Weile erhalten bleiben. | 
 Das ist schon seit Windows NT nicht mehr der Fall. Das Terminal wird lediglich emuliert (deshalb der name NTVDM = NT Virtual DOS Machine).
 Natürlich kann hier niemand den Trend voraussagen, dem Windows folgend wird, aber als Syadmin-Tool und ähnliches wird es die Konsole natürlich noch für lange Zeit geben, und selbst wenn es sie auf Windows nicht mehr geben soll, kann man immer noch einen beliebigen anderen Terminal-Emulator, auch unter Linux, verwenden.
 _________________
 » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 
  |  |  
		| Nach oben |  |  
		|  |  
		| grindstone 
 
 
 Anmeldungsdatum: 03.10.2010
 Beiträge: 1283
 Wohnort: Ruhrpott
 
 | 
			
				|  Verfasst am: 20.12.2013, 11:07    Titel: |   |  
				| 
 |  
				| OK, ich nehme alles zurück und behaupte das Gegenteil. Ich hatte da wohl noch WinME im Hinterkopf. 	  | Jojo hat Folgendes geschrieben: |  	  | Das ist schon seit Windows NT nicht mehr der Fall. Das Terminal wird lediglich emuliert (deshalb der name NTVDM = NT Virtual DOS Machine). | 
  Aber bist du wirklich ganz sicher, daß nicht doch noch heimlich, versteckt, irgendwo ganz tief im Kernel........? Nein...?   
 Gruß
 grindstone
 _________________
 For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!
 |  |  
		| Nach oben |  |  
		|  |  
		| St_W 
 
  
 Anmeldungsdatum: 22.07.2007
 Beiträge: 958
 Wohnort: Austria
 
 | 
			
				|  Verfasst am: 20.12.2013, 15:35    Titel: |   |  
				| 
 |  
				| DOS hat mit der NT Reihe von Windows nichts zu tun - wie Jojo schon gesagt hat werden DOS Programme unter Windows NT mit Hilfe der NTDVM ausgeführt. Die NTDVM hat jedoch wiederrum mit der Konsole nicht wirklich was zu tun. Eine normale 32-Bit FreeBasic Konsolenanwendung braucht keine NTDVM. Die NTDVM wird nur für die Ausführung von 16-Bit DOS Programmen auf einem 32-Bit System benötigt.
 
 Eine Konsolenapplikation ist also meines Erachtens sehr zukunftssicher, was dessen Ausführbarkeit betrifft. Trotzdem würd ich sagen, dass ein Endbenutzer heutzutage eine Grafische Oberfläche erwartet und eine Konsolenoberfläche als nicht mehr zeitgemäß empfindet.
 _________________
 Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
 http://www.mv-lacken.at Musikverein Lacken (MV Lacken)
 |  |  
		| Nach oben |  |  
		|  |  
		| TimesChange 
 
 
 Anmeldungsdatum: 20.11.2013
 Beiträge: 85
 
 
 | 
			
				|  Verfasst am: 20.12.2013, 17:44    Titel: |   |  
				| 
 |  
				|  	  | St_W hat Folgendes geschrieben: |  	  | ...Trotzdem würd ich sagen, dass ein Endbenutzer heutzutage eine Grafische Oberfläche erwartet und eine Konsolenoberfläche als nicht mehr zeitgemäß empfindet. | 
 
 Da gebe ich dir schon recht.
 In dem Fall bin aber ich der Hauptbenutzer (und wer aus meiner Familie das sonst noch nutzen will) , mir ist das Programm mit ein paar einfachen Rahmen aus ASCII-Zeichen und farbigem Hintergrund "grafisch genug".
 Und es ist halt ungeschlagen schnell: Ich brauche vom Anklicken des Programmsymbols auf dem Desktop rund 3 Sekunden, bis ich die gesuchte Adresse / Tel-Nr. sehe. Gut, vielleicht würde man das auch in "hübsch" so schnell hinbekommen.
 
 Wo ich einen gewissen Nachbesserungsbedarf sehe, ist das etwas umständliche Übernehmen oder Einfügen von Daten in/aus anderen Quellen. Direktes copy and paste geht hier ja nicht (nur umständlich über BEARBEITEN...)
 Das würde den praktischen Nutzen erhöhen.
 
 Ich werde mal im Forum suchen, ob ich was dazu finde, wie man Daten aus FB in die Zwischenablage bekommt. Wenn ich nichts finde, frage ich hier nochmal in einem neuen Thema nach.
 
 Grüße
 Rainer
 |  |  
		| Nach oben |  |  
		|  |  
		| dreael Administrator
 
  
 Anmeldungsdatum: 10.09.2004
 Beiträge: 2530
 Wohnort: Hofen SH (Schweiz)
 
 | 
			
				|  Verfasst am: 20.12.2013, 21:40    Titel: |   |  
				| 
 |  
				| Zum Titelthema: FreeBasic versucht hier aus Rückwärtskompatibilität das Verhalten von SCREEN 9, also damals den EGA-BIOS-Aufruf INT 10h, AH=00, AL=10h möglichst gut nachzubilden, was auch zum besagten Verhalten führt. 
 Da derartige "Krücken" bei Neuentwicklungen keinen Sinn mehr machen, ist ScreenRes logischerweise sinnvoller, wo COLOR ein logisches und konsistentes Verhalten besitzt.
 
 Logischerweise emuliert FreeBasic auch bei ScreenRes einen Paletten-Videomodus bei niedrigen Farbtiefen, da inzwischen selbst der billigste PCs mit Onboard-VGA schon seit über 10 Jahren eine True Color-Videokarte besitzt.
 _________________
 Teste die PC-Sicherheit mit www.sec-check.net
 |  |  
		| Nach oben |  |  
		|  |  
		| TimesChange 
 
 
 Anmeldungsdatum: 20.11.2013
 Beiträge: 85
 
 
 | 
			
				|  Verfasst am: 21.12.2013, 01:49    Titel: |   |  
				| 
 |  
				| Die Variante mit SCREENRES hätte ich auch gerne genommen, aber dort fehlt mir der cursor für meine Eingaberoutine. Mit einem "normalen" cursor konnte mir nemored zwar aushelfen, doch einen Einfüge-Cursor konnte ich so nicht realisieren. 
 Grüße
 Rainer
 |  |  
		| Nach oben |  |  
		|  |  
		| dreael Administrator
 
  
 Anmeldungsdatum: 10.09.2004
 Beiträge: 2530
 Wohnort: Hofen SH (Schweiz)
 
 | 
			
				|  Verfasst am: 21.12.2013, 18:21    Titel: |   |  
				| 
 |  
				| Hier musst Du halt ggf. selber eine Cursor-Emulation implementieren, also diesen mit LINE ,BF zeichnen. Dabei SLEEP mit Zeitangabe für die Blinkzeit verwenden. Dabei das "vermalte" Zeichen einfach wieder mit PRINT frisch ausgeben. Tastatur mit Inkey abfragen. 
 Sinnvollerweise alles in eine SUB hineinpacken.
 
 Siehe dazu auch
 
 http://www.dreael.ch/Deutsch/BASIC-Knowhow-Ecke/BildschirmMasken.html
 
 aus meiner Sammlung.
 _________________
 Teste die PC-Sicherheit mit www.sec-check.net
 |  |  
		| Nach oben |  |  
		|  |  
		| nemored 
 
  
 Anmeldungsdatum: 22.02.2007
 Beiträge: 4711
 Wohnort: ~/
 
 | 
			
				|  Verfasst am: 21.12.2013, 19:58    Titel: |   |  
				| 
 |  
				| Ich würde einen Bildpuffer in Größe des Cursors vorschlagen, der mit der Hintergrundfarbe befüllt ist und über PSET gesetzt wird. Dann kannst du, falls gewünscht, auch mit der Methode XOR setzen, um den Buchstaben in umgekehrter Farbe darzustellen. Alternativ kann man statt mit unterschiedlichen Cursor-Höhen auch mit verschiedener Anzeigelänge arbeiten (0.8 sec an, 0.2 sec aus o. ä.) _________________
 Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.
 |  |  
		| Nach oben |  |  
		|  |  
		| grindstone 
 
 
 Anmeldungsdatum: 03.10.2010
 Beiträge: 1283
 Wohnort: Ruhrpott
 
 | 
			
				|  Verfasst am: 22.12.2013, 13:59    Titel: |   |  
				| 
 |  
				| ScreenRes wäre sehr viel schöner, wenn es 1. threadsicher wäre und
2. etwas mehr Auswahl an Schriftgröße und -art hätte
 
 Gruß
 grindstone
 _________________
 For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!
 |  |  
		| Nach oben |  |  
		|  |  
		| nemored 
 
  
 Anmeldungsdatum: 22.02.2007
 Beiträge: 4711
 Wohnort: ~/
 
 | 
			
				|  Verfasst am: 22.12.2013, 16:59    Titel: |   |  
				| 
 |  
				| @Threadsicherheit: da ist ja nicht SCREENRES das Problem, sondern die implementierten Grafikbefehle.   
 Für mehr implementierte Schriftarten und -größen würde entweder die der Grafikbibliothek mitgelieferte Datenmenge enorm anwachsen oder man müsste (wesentlich praktischer) auf die Systemfonts zurückgreifen. Letzteres sollte über externe Bibliotheken möglich sein (siehe http://www.freebasic-portal.de/befehlsreferenz/externe-bibliotheken-639.html), damit habe ich mich aber noch nicht auseinandergesetzt.
 
 DRAW STRING bietet übrigens auch die Möglichkeit, einen komplett eigenen Schriftsatz einzubinden; Volta hat dazu auch ein ausführliches Beispiel ins Portal gestellt.
 _________________
 Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.
 |  |  
		| Nach oben |  |  
		|  |  
		| dreael Administrator
 
  
 Anmeldungsdatum: 10.09.2004
 Beiträge: 2530
 Wohnort: Hofen SH (Schweiz)
 
 | 
			
				|  Verfasst am: 22.12.2013, 17:51    Titel: |   |  
				| 
 |  
				| Lösung bei nicht thread-sicheren Bibliotheken/Befehlen: MUTEXCREATE und die ganze Befehlsfamilie drum herum, d.h. in diesem Fall musst Du halt mit einem Mutex selber einen "Verkehrspolizisten auf die Kreuzung" stellen. 
 Dazu am besten sämtliche GFX-Aufrufe in eine FreeBasic-Klasse einkapseln, diese ruft dann sämtliche LINEs, CIRLCEs usw. mit vorangehendem MUTEXLOCK und nachfolgendem MUTEXUNLOCK auf.
 
 => Somit kann die übrige FB-Anwendung dem heutigen 4-Kern-Prozessor gerechtwerdend beliebig parallelisiert werden. :-)
 _________________
 Teste die PC-Sicherheit mit www.sec-check.net
 |  |  
		| Nach oben |  |  
		|  |  
		| TimesChange 
 
 
 Anmeldungsdatum: 20.11.2013
 Beiträge: 85
 
 
 | 
			
				|  Verfasst am: 22.12.2013, 18:05    Titel: |   |  
				| 
 |  
				| Zwischenfrage des "interessierten Laien":   
 Was bedeutet thread-Sicherheit bei Screenres praktisch für mich?
 
 Kann es schon zu unerwünschten Inkonsistenzen oder sonstigem digitalem Schweinkram kommen, wenn ich mehrere mit FB erzeugte Programme laufen lasse, die SCREENRES und Grafikbefehle benutzen?
 
 Ansonsten bin ich sehr froh, dass ich es nach etlichen Stunden endlich geschafft habe, ein bis jetzt fehlerfrei laufendes Programm zu habe, das nun tut was es soll... auch wenn es derzeit nur der Konsolenmodus ist.
 
 Grüße
 Rainer
 |  |  
		| Nach oben |  |  
		|  |  
		| Sebastian Administrator
 
  
 Anmeldungsdatum: 10.09.2004
 Beiträge: 5969
 Wohnort: Deutschland
 
 | 
			
				|  Verfasst am: 22.12.2013, 18:34    Titel: |   |  
				| 
 |  
				|  	  | TimesChange hat Folgendes geschrieben: |  	  | Was bedeutet thread-Sicherheit bei Screenres praktisch für mich? | 
 Es dürfen nicht mehrere Threads innerhalb desselben Prozesses gleichzeitig auf den Screen zugreifen bzw. darauf herummalen. Da muss ein Thread auf den anderen warten oder man wickelt alle Grafikfunktionen in einem eigenen Grafikthread ab. Und die anderen Threads greifen dann nicht auf den SCREEN zu.
 
 
  	  | TimesChange hat Folgendes geschrieben: |  	  | Kann es schon zu unerwünschten Inkonsistenzen oder sonstigem digitalem Schweinkram kommen, wenn ich mehrere mit FB erzeugte Programme laufen lasse, die SCREENRES und Grafikbefehle benutzen? | 
 Nein, da muss man sich keine Sorgen machen, wenn sich die Programme nicht z. B. gemeinsame Dateien wie eine Adressdatenbank-Datei teilen, auf die alle Prozesse gleichzeitig zugreifen wollen.
 
 Wenn du ein Programm mehrmals parallel startest (mehrere Prozesse) oder ganz verschiedene FB-basierte Programme gleichzeitig laufen lässt, laufen sie isoliert voneinander. Jedes hat seinen eigenen Speicherbereich, auf den das jeweils andere nicht zugreifen darf.
 _________________
 
   Die gefährlichsten Familienclans | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen!
 |  |  
		| Nach oben |  |  
		|  |  
		| dreael Administrator
 
  
 Anmeldungsdatum: 10.09.2004
 Beiträge: 2530
 Wohnort: Hofen SH (Schweiz)
 
 | 
			
				|  Verfasst am: 22.12.2013, 18:38    Titel: |   |  
				| 
 |  
				|  	  | TimesChange hat Folgendes geschrieben: |  	  | Was bedeutet thread-Sicherheit bei Screenres praktisch für mich? | 
 
 Wikipedia:
 
 http://de.wikipedia.org/wiki/Threadsicherheit
 
 Denke an folgendes ganz einfache Beispiel:
 
 
 Überlegung: Wenn Thread A die Variable a liest, um a+1 auszuwerten und genau dann vom Multitasking unterbrochen wird, Thread B nun auch genau diese Anweisung ausführt (selbe Variable und damit Speicher!) und danach Thread A fortfährt (=weist nun das Ergebnis von zuvor an a zu), was passiert dann wohl?
 
 Sei a ein Zähler für etwas Erledigtes, Threads A und B möchten sich "rückmelden" und a erhöhen. Sei a = 4 bisher
 
 Vom Programmierer erwartet: a = 6 (jeder Thread hat a um 1 erhöht).
 
 Realität, wenn Thread A genau zwischen Lesen und wieder zuweisen unterbrochen wird und Thread B sein a=a+1 währenddessen ausführt: a = 5! Warum? Thread A hat Zählerstand 4 ausgelesen, Addition ausgeführt und wurde unterbrochen. Thread B liest ebenfalls a aus (besitzt immer noch 4!) und erhöht diese und kann meinetwegen das Ergebnis noch imselben CPU-Zeitschlitz zuweisen => a=5 jetzt. Thread A fährt nun fort: Ergebnis 5 an a zurückschreiben: Bemerkt Veränderung natürlich nicht und prompt steht der Zähler am Schluss entgegen den Absichten vom Programmierer immer noch bei 5!
 
 Lösung: Erhöhung dieses gemeinsamen a = kritischer Abschnitt
 
 http://de.wikipedia.org/wiki/Kritischer_Abschnitt
 
 => Mutex drumherumbauen. Wenn jetzt Thread A auch wieder mittendrin unterbrochen wird, dann _muss_ Thread B warten (=Betriebssystem beendet CPU-Zeitschlitz vorzeitig), bevor es ebenfalls a=a+1 ausführen kann. => Jetzt kann Thread A sein a=a+1 noch vollständig beenden, d.h. Wert 5 zurückschreiben. Mit dem UNLOCK gibt A den kritischen Abschnitt frei, womit anschliessend Thread B hineinkommt. Weil B nun diesmal den von A geupdateten Wert 5 ausliest und somit 6 zurückschreibt, funktioniert nun unser Zähler wie vom Programmierer erwartet.
 
 Wenn nun eine Bibliothek intern Ressourcen verwendet, auf welche nur ein Thread aufs Mal zugreifen darf und die nötigen LOCKs und UNLOCKs bereits intern selber macht, dann ist die Bibliothek threadsicher. Ist sie dies nicht, verwendet aber entsprechende Ressourcen, dann musst Du als Anwendungsprogrammierer selber die nötigen LOCKs und UNLOCKs machen.
 
 /edit: Kurz ein Herumspiel-Beispiel zusammengeschustert:
 
  	  | Code: |  	  | ' Thread-Beispiel 
 Dim Shared zaehler As Integer, m As Any Ptr
 
 Sub ThreadAufgabeUnsicher(ByVal p As Any Ptr)
 Dim i As Integer, j As Integer
 For i=1 To 100
 j = zaehler + 1
 Sleep 20 + 10 * Rnd
 zaehler = j
 Sleep 1 + 5 * Rnd
 Next i
 End Sub
 
 Sub ThreadAufgabeSicher(ByVal p As Any Ptr)
 Dim i As Integer, j As Integer
 For i=1 To 100
 MutexLock m
 j = zaehler + 1
 Sleep 20 + 10 * Rnd
 zaehler = j
 MutexUnLock m
 Sleep 1 + 5 * Rnd
 Next i
 End Sub
 
 Dim i As Integer, t(9) As Any Ptr
 
 ScreenRes 640, 480
 Width 80, 30
 
 zaehler = 0
 For i = 0 To 9
 t(i) = ThreadCreate(@ThreadAufgabeUnsicher)
 Next i
 Print "Threads Variante Unsicher gestartet."
 For i = 0 To 9
 ThreadWait t(i)
 Next i
 Print !"Ende Thread-Verarbeitung. Z\132hler = "; zaehler
 
 zaehler = 0
 m = MutexCreate
 For i = 0 To 9
 t(i) = ThreadCreate(@ThreadAufgabeSicher)
 Next i
 Print "Threads Variante Sicher gestartet."
 For i = 0 To 9
 ThreadWait t(i)
 Next i
 MutexDestroy m
 Print !"Ende Thread-Verarbeitung. Z\132hler = "; zaehler
 
 Sleep
 | 
 Hinweis: Man achte auf die Zählerstände am Schluss!
 _________________
 Teste die PC-Sicherheit mit www.sec-check.net
 |  |  
		| Nach oben |  |  
		|  |  
		| TimesChange 
 
 
 Anmeldungsdatum: 20.11.2013
 Beiträge: 85
 
 
 | 
			
				|  Verfasst am: 22.12.2013, 20:08    Titel: |   |  
				| 
 |  
				| Danke für eure Erläuterungen dazu (in Wiki habe ich natürlich auch schon nachgesehen, um überhaupt zu wissen was damit gemeint sein könnte). Interessantes Code-Beispiel, es ist immer leichter, wenn man etwas in der Praxis sehen kann, als es sich nur vorzustellen.
 
 In meinem Fall muss ich mir also keine Sorgen machen, da meine Programme wirklich sehr "basic" im wahrsten Wortsinne sind, und 'sequentiell' abgearbeitet werden.
 
 Grüße
 Rainer
 
 P.S. Zur Zwischenablage habe ich etwas gefunden und eingebaut. Jetzt kann ich auch einen Adressensatz mit CTRL-C in die Zwischenablage kopieren.
 |  |  
		| Nach oben |  |  
		|  |  
		| grindstone 
 
 
 Anmeldungsdatum: 03.10.2010
 Beiträge: 1283
 Wohnort: Ruhrpott
 
 | 
			
				|  Verfasst am: 22.12.2013, 20:38    Titel: |   |  
				| 
 |  
				| @nemored: Man müsste einen Dreh finden, TrueType-Fonts einzubinden. Aber da dürfte es wohl weniger Arbeit sein, sich eine "richtige" GUI zu basteln.   
 @dreael: Danke für den Tip, ich werde es mal versuchen. Ich hatte bei dem Colochessum (vormals "engine_vs_engine"), an dem ich gerade schreibe, einmal versucht, eine Mausabfrage mit eigenem Thread zu programmieren - mit dem Erfolg, daß das Programm nach spätestens 20 Sekunden abgestürzt ist. Wenn ich jetzt wenigstens die Tastaturabfrage auf "Chr(255,107)" (X) zum Programmbeenden in einen Thread packen könnte, wäre das schon eine große Erleichterung.
   
 Gruß
 grindstone
 _________________
 For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!
 |  |  
		| Nach oben |  |  
		|  |  
		| ThePuppetMaster 
 
  
 Anmeldungsdatum: 18.02.2007
 Beiträge: 1839
 Wohnort: [JN58JR]
 
 | 
			
				|  Verfasst am: 22.12.2013, 23:52    Titel: |   |  
				| 
 |  
				| PS: threadproblematische befehle sind gfx, io und sleep! .. Sprich, alle zusammen dürfen nicht aus mehreren threads heraus wechselseitig aufgerufen werden! (AUCH SLEEP!!!) 
 
 MfG
 TPM
 _________________
 [ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ]
 |  |  
		| 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.
 
 |  |