Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

Hintergrundfarbe mit COLOR vom Modus abhängig?
Gehe zu Seite Zurück  1, 2, 3  Weiter
 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC.
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 20.12.2013, 01:11    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
TimesChange



Anmeldungsdatum: 20.11.2013
Beiträge: 85

BeitragVerfasst am: 20.12.2013, 01:33    Titel: Antworten mit Zitat

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... lächeln

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 zwinkern
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
Benutzer-Profile anzeigen Private Nachricht senden
grindstone



Anmeldungsdatum: 03.10.2010
Beiträge: 1278
Wohnort: Ruhrpott

BeitragVerfasst am: 20.12.2013, 03:55    Titel: Antworten mit Zitat

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.

Zitat:
Im Konsolenmodus ist das mit SCREEN erhaltene Farbattribut nur ein 8-Bit-Wert
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... verwundert

Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 20.12.2013, 10:34    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
grindstone



Anmeldungsdatum: 03.10.2010
Beiträge: 1278
Wohnort: Ruhrpott

BeitragVerfasst am: 20.12.2013, 12:07    Titel: Antworten mit Zitat

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).
OK, ich nehme alles zurück und behaupte das Gegenteil. Ich hatte da wohl noch WinME im Hinterkopf. verlegen Aber bist du wirklich ganz sicher, daß nicht doch noch heimlich, versteckt, irgendwo ganz tief im Kernel........? Nein...? zwinkern

Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
St_W



Anmeldungsdatum: 22.07.2007
Beiträge: 956
Wohnort: Austria

BeitragVerfasst am: 20.12.2013, 16:35    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
TimesChange



Anmeldungsdatum: 20.11.2013
Beiträge: 85

BeitragVerfasst am: 20.12.2013, 18:44    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
dreael
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 2529
Wohnort: Hofen SH (Schweiz)

BeitragVerfasst am: 20.12.2013, 22:40    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
TimesChange



Anmeldungsdatum: 20.11.2013
Beiträge: 85

BeitragVerfasst am: 21.12.2013, 02:49    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
dreael
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 2529
Wohnort: Hofen SH (Schweiz)

BeitragVerfasst am: 21.12.2013, 19:21    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4699
Wohnort: ~/

BeitragVerfasst am: 21.12.2013, 20:58    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
grindstone



Anmeldungsdatum: 03.10.2010
Beiträge: 1278
Wohnort: Ruhrpott

BeitragVerfasst am: 22.12.2013, 14:59    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4699
Wohnort: ~/

BeitragVerfasst am: 22.12.2013, 17:59    Titel: Antworten mit Zitat

@Threadsicherheit: da ist ja nicht SCREENRES das Problem, sondern die implementierten Grafikbefehle. cool

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
Benutzer-Profile anzeigen Private Nachricht senden
dreael
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 2529
Wohnort: Hofen SH (Schweiz)

BeitragVerfasst am: 22.12.2013, 18:51    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
TimesChange



Anmeldungsdatum: 20.11.2013
Beiträge: 85

BeitragVerfasst am: 22.12.2013, 19:05    Titel: Antworten mit Zitat

Zwischenfrage des "interessierten Laien": zwinkern

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
Benutzer-Profile anzeigen Private Nachricht senden
Sebastian
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 5969
Wohnort: Deutschland

BeitragVerfasst am: 22.12.2013, 19:34    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
dreael
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 2529
Wohnort: Hofen SH (Schweiz)

BeitragVerfasst am: 22.12.2013, 19:38    Titel: Antworten mit Zitat

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:
Code:
a = a + 1


Ü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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
TimesChange



Anmeldungsdatum: 20.11.2013
Beiträge: 85

BeitragVerfasst am: 22.12.2013, 21:08    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
grindstone



Anmeldungsdatum: 03.10.2010
Beiträge: 1278
Wohnort: Ruhrpott

BeitragVerfasst am: 22.12.2013, 21:38    Titel: Antworten mit Zitat

@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. grinsen

@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. lächeln

Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
ThePuppetMaster



Anmeldungsdatum: 18.02.2007
Beiträge: 1839
Wohnort: [JN58JR]

BeitragVerfasst am: 23.12.2013, 00:52    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC. Alle Zeiten sind GMT + 1 Stunde
Gehe zu Seite Zurück  1, 2, 3  Weiter
Seite 2 von 3

 
Gehe zu:  
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.

 Impressum :: Datenschutz