Textfenster - amiga-news.de Forum

amiga-news.de Forum > Programmierung > Textfenster

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2

[ - Beitrag schreiben - ]

08.12.2006, 19:53 Uhr

Ralf27
Posts: 2779
Nutzer

Ich hab vor sowas wie ein Textfenster für die virtuelle Kommunikation in einem Spiel zu programmieren. Allerdings frage ich mich auch ob es eventuell schon sowas ähnliches ins System integriert ist. Oder muß ich wirklich alles selbst zusammenbauen(was ich eigentlich auch vor hatte)?

Das ganze sollte folgende Features haben:
* Text anzeigen (wow

)
* Texteingabe entgegen nehmen
* eventuell auch eine Art Textbuffer besitzen

Ich hab gesehn das man z.b. auch CON: öffnen kann. Aber mein Wissen ist halt auf OS1.2-Ebene und auch da nur vermutlich sehr lückenhaft...

Ideen?

Gibt es da etwas oder doch lieber alles selbst schreiben?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

08.12.2006, 20:55 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von Ralf27:
Ich hab gesehn das man z.b. auch CON: öffnen kann. Aber mein Wissen ist halt auf OS1.2-Ebene und auch da nur vermutlich sehr lückenhaft...

Auch die AmigaOS-Versionen nach 1.2 erlauben das Öffnen von CON:
Sie unterstützen auch noch ne Reihe von zusätzlichen Fancy Features, aber wenn es Dir nur um die genannten drei Punkte "Text anzeigen", "Texteingabe" und "Textbuffer besitzen" geht, dann ist ja eigentlich schon alles gesagt.

Oder wolltest Du noch mehr?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

08.12.2006, 22:23 Uhr

Ralf27
Posts: 2779
Nutzer

Kann man überhaupt das CON:-Fenster auch auf einem eigenen Screen öffnen lassen?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

08.12.2006, 22:35 Uhr

thomas
Posts: 7718
Nutzer

Ja, kann man. Wenn dein Screen ein PubScreen ist, kannst du mit

con://///SCREEN pubscreenname

das Fenster auf diesem PubScreen öffnen.

Ansonsten mußt du das Fenster selbst öffnen und kannst dann mit

con://///WINDOW 0x12345678

die Adresse des Fensters übergeben. Das Fenster wird beim Schließen der CON-Datei mit geschlossen, du darfst also nur, wenn das Open("con:....") nicht geklappt hat, CloseWindow aufrufen.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

08.12.2006, 23:04 Uhr

Ralf27
Posts: 2779
Nutzer

Danke!

Also, das muß ich dann einfach mal testen. Das erspart mir wirklich einiges an Arbeit und dem Benutzer bestimmt auch einiges an Nerven.

--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

08.12.2006, 23:41 Uhr

Ralf27
Posts: 2779
Nutzer

Ohoh, da kommen sie wieder, die kleinen Probleme:

Also, ich kann jetzt erfolgreich ein CON: auf ein eigenes Fenster mit CON:////WINDOW 0x12342323 öffnen und es erscheint auch eine Textausgabe, wenn ich will. Aber leider bekomme ich auf meinem eigenen Fenster keine Eingaben. Ich kann kein Text schreiben.

Wenn ich aber das ganze *ohne* eigenes Fenster mach, dann kann ich schreiben.

IDCMP_VANILLAKEY und IDCMP_RAWKEY hab ich auch mal testweise im Fenster gesetzt, aber bringt auch nichts.
Wie muß denn das Fenster beschaffen sein, damit die Console richtig damit arbeiten kann?

EDIT:
Ah, ich habs: Man darf diese beiden erst gar nicht setzen, dann gehts. Aha, wieder was gelernt.

--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 08.12.2006 um 23:43 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

10.12.2006, 14:49 Uhr

Ralf27
Posts: 2779
Nutzer

So, Textfenster ist eingbaut, die Kommunikation im Spiel via Netzwerk läuft super. Nur ein Punkt ist etwas seltsam: Ich hab ab und zu einen Absturz beim Fensterschliese?!? Ich vermute mal das ich was falsch oder in der falschen reihenfolge zu mach. Hier mal der Code zum Fenster öffnen und Fenster schliesen:

code:

OeffneCONWin:
 IF con_win&=0 THEN
  TAGLIST tagsl&,_
  WA_IDCMP&,IDCMP_CLOSEWINDOW&,_
  WA_Flags&,WFLG_CLOSEGADGET&+_
            WFLG_ACTIVATE&+_
            WFLG_SIZEGADGET&+_
            WFLG_DEPTHGADGET&+_
            WFLG_DRAGBAR&+_
            WFLG_SIMPLE_REFRESH&,_
  WA_MinHeight&,50,_
  WA_MinWidth&,100,_
  WA_Title&,"Netzwerkfenster",_
  TAG_END&
  con_win&=OpenWindowTagList&(0,tagsl&)
  IF con_win& THEN
   con_buffer&=AllocMem&(tcp_bufferl&,MEMF_PUBLIC&)
   con_port&=CreateMsgPort&()
   con&=xOpen&(SADD("CON://///WINDOW 0x"+HEX$(con_win&)+CHR$(0)),MODE_READWRITE&)
   IF con&=0 OR con_buffer&=0 OR con_port&=0 THEN
    Meldung"Kann Netzwerkfenster nicht einrichten",1
    GOSUB SchlieseCONWin
   ELSE
    con_userport&=PEEKL(con_win&+UserPort%)
    StartRead con&,con_buffer&,tcp_bufferl&,con_port&:con_packet&=packet&
   END IF
  ELSE
   Meldung"Kann Netzwerkfenster nicht öffnen",1
  END IF
 END IF
RETURN

SchlieseCONWin:
 IF con_port& THEN DeleteMsgPort con_port&:con_port&=0
 IF con_packet& THEN FreeDosObject DOS_STDPKT&,con_packet&:con_packet&=0
 IF con& THEN junk=xClose(con&):con&=0:con_win&=0:REM Vorsicht: Console schliest auch Fenster!
 IF con_win& THEN CloseWindow con_win&:con_win&=0
 IF con_buffer& THEN FreeMem con_buffer&,tcp_bufferl&:con_buffer&=0
 con_userport&=0
RETURN

Da das öffnen und der Betrieb funktioniert, dürfte es vermutlich am schhliesen liegen. Jetzt die Frage, was könnte da falsch laufen?

Hinweis:
Das ist nur ein Teil vom ganzen Programm. Die Verarbeitung des CONFenster läuft ja ohne Probleme.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

10.12.2006, 20:25 Uhr

thomas
Posts: 7718
Nutzer

Du benutzt offenbar asynchrones I/O. Vermutlich stürzt dein Programm ab, weil du nicht ordentlich auf das Beenden des I/O wartest, bevor du das Fenster schließt. (Wenn du ordentlich warten würdest, müßte der Benutzer erst Return drücken, bevor du das Fenster schließen kannst.)

Für deine Zwecke wäre es wohl sinnvoller, das console.device direkt zu benutzen, denn dann kannst du ein offenes SendIO mit AbortIO abbrechen.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

10.12.2006, 21:56 Uhr

Ralf27
Posts: 2779
Nutzer

Zitat:
Original von thomas:
Für deine Zwecke wäre es wohl sinnvoller, das console.device direkt zu benutzen, denn dann kannst du ein offenes SendIO mit AbortIO abbrechen.

Dann ergeben sich wohl jetzt für mich zwei große Probleme:
Zum einen benutze ich auch dieses async-lesen bei TCP: und da müßte ich das dann wohl auch umbauen. Die Frage ist nun, wie ich das mit diesem SendIO bzw. AbortIO hinbekommen könnte. Wie sieht das dann aus?

code:

SUB StartRead(bptr&,buffer&,size&,port&)
 SHARED packet&
 fh&=bptr&<<2
 IF fh&<>0 AND PEEKL(fh&+fh_Type%)<>0 THEN
  packet&=AllocDosObject&(DOS_STDPKT&,TAG_END&)
  IF packet& THEN
   POKEL packet&+dp_Port%,port&
   POKEL packet&+dp_Type%,ACTION_READ&
   POKEL packet&+dp_Arg1%,PEEKL(fh&+fh_args%)
   POKEL packet&+dp_Arg2%,buffer&
   POKEL packet&+dp_Arg3%,size&
   PutMsg PEEKL(fh&+fh_Type%),PEEKL(packet&+dp_Link%)
  END IF
 END IF
END SUB

Das ist übrigens der Code zum lesen, denn ich bei CON: und TCP: benutze.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

11.12.2006, 22:09 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von thomas:
Du benutzt offenbar asynchrones I/O. Vermutlich stürzt dein Programm ab, weil du nicht ordentlich auf das Beenden des I/O wartest, bevor du das Fenster schließt. (Wenn du ordentlich warten würdest, müßte der Benutzer erst Return drücken, bevor du das Fenster schließen kannst.)

Sollte zum Zeitpunkt des Schließens noch eine asynchrone Anfrage unbeantwortet sein, dann ist vor allem das Freigeben des zugehörigen DOS-Packets die Ursache für den Absturz. Den console-handler interessiert gar nicht, ob die I/O synchron oder asynchron abläuft, da er ja, wie die meisten (wenn nicht sogar alle) DOS-Handler in einem task die Packets in der Reihenfolge abarbeitet, wie sie eintreffen. Anders gesagt, bevor der hängende Lese-Request nicht bearbeitet ist, wird der Close-Request gar nicht erst empfangen.

Zitat:
Für deine Zwecke wäre es wohl sinnvoller, das console.device direkt zu benutzen, denn dann kannst du ein offenes SendIO mit AbortIO abbrechen.

Das ist mit Kanonen auf Spatzen geschossen. Man kann auch einfach RAW: statt CON: benutzen, bzw. CON: in den RAW-Modus umschalten...

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

11.12.2006, 22:11 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von Ralf27:

Zitat:
Original von thomas:
Für deine Zwecke wäre es wohl sinnvoller, das console.device direkt zu benutzen, denn dann kannst du ein offenes SendIO mit AbortIO abbrechen.
Dann ergeben sich wohl jetzt für mich zwei große Probleme:
Zum einen benutze ich auch dieses async-lesen bei TCP: und da müßte ich das dann wohl auch umbauen. ...

Wieso?!
Was hat das eine mit dem anderen zu tun?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

11.12.2006, 23:15 Uhr

Ralf27
Posts: 2779
Nutzer

Zitat:
Original von Holger:
Was hat das eine mit dem anderen zu tun?

Ich benutze für beides die gleichen Routinen. Und ich vermute einfach mal, wenn ich beim schliesen vom CON:-Fenster(mit allem was dran hängt, also auch das async-lesen) probleme bekommen kann, dies wohl auch bei TCP: bekommen könnte. Vermutlich ist es da ja auch so, aber soweit komme ich ja beim beenden nicht, weil ja vorher die CONsole(mit allem drum und dran) freigegeben wird.

Also:
Erst alle Msg vom jeweiligen Port holen und dann, wenn nix mehr kommt kann ich denn Port dicht machen und auch denn rest?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

12.12.2006, 21:08 Uhr

Ralf27
Posts: 2779
Nutzer

Hm, ich weis da leider nicht weiter. Ich bekomme die Abstürze einfach nicht weg. Hm, doch lieber alles selbst ohne CON: programmieren? Wie würdet ihr da denn machen?
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

12.12.2006, 21:16 Uhr

Ralf27
Posts: 2779
Nutzer

Hab da eben was gefunden:
WaitForChar ()

Damit könnte ich ja prüfen ob Bytes vorhanden sind zum lesen und dann in einem rutsch mit Read() lesen. Dann würde ich mir wohl die ganze story mit MsgPort etc. sparen. Und das bei TCP: und CON: . Das sind ja "virtuelle Laufwerke", also müßte WaitForChar da auch laufen. Wäre das eine einigermaßen korrekte Lösung?
Ok, die Anzahl der Bytes bekomme ich nicht mit, aber ich sehe ja beim Rückgabewert von Read wieviele Bytes ich bekommen habe.

EDIT: geht leider auch nicht. damit bekomme ich es überhaupt nicht zum laufen...
--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 12.12.2006 um 21:46 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.12.2006, 23:44 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von Ralf27:
Hm, ich weis da leider nicht weiter. Ich bekomme die Abstürze einfach nicht weg. Hm, doch lieber alles selbst ohne CON: programmieren? Wie würdet ihr da denn machen?

Hast Du denn mal statt rumprobieren versucht, Dich mir genau den Dingen zu beschäftigen, die Dir hier gesagt wurden?

Hast Du überprüft, ob noch ein Lesevorgang läuft, wenn Du die Datei schließen willst?
Mit welchem Ergebnis? Falls er noch läuft, hast Du ein Warten auf die Antwort vor dem Freigeben des DOS-Packets eingefügt?
Falls nein, ist Dir in den Sinn gekommen, dass es dann gar nicht die Ursache für den Absturz sein kann?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

15.12.2006, 18:07 Uhr

Ralf27
Posts: 2779
Nutzer

Zitat:
Original von Holger:
Hast Du denn mal statt rumprobieren versucht, Dich mir genau den Dingen zu beschäftigen, die Dir hier gesagt wurden?

Ich weis leider nicht wo ich da ansetzen soll. Es läuft ja keine Leseaktion beim CON-Fenster, weil ich ja nix eingebe, wenn ich das Fenster schliese.
Deswegen ist mir auch nicht klar was ich da noch machen muß, damit es richtig läuft..

Zitat:
Hast Du überprüft, ob noch ein Lesevorgang läuft, wenn Du die Datei schließen willst?

Ich möchte dann ja das CON:-Fenster schliesen. Ich weis jetzt auch nicht wie ich das Prüfen könnte, außer halt die anzahl der gelesen Bytes zu vergleichen. Aber ob das so richtig ist...

Zitat:
Mit welchem Ergebnis? Falls er noch läuft, hast Du ein Warten auf die Antwort vor dem Freigeben des DOS-Packets eingefügt?
Falls nein, ist Dir in den Sinn gekommen, dass es dann gar nicht die Ursache für den Absturz sein kann?

Warten? Hm, ne, da ist nix drin. Also egal was ist, muß ich also erst Warten (muß später mal nachsehn wie das gehn soll) und dann schliesen. Oh, ich will ja gar nicht wissen was es da alles noch für Stolperfallen gibt.

Das ganze async-lesen mach ich ja nur, weil Read() einfach nicht zurück kommt, wenn kein Byte vorhanden ist. Wenn Read() sofort zurück kommen würde(von TCP: und CON:)auch wenn kein Byte vorhanden wäre, dann bräuchte ich das ganze ja nicht...

EDIT:
WaitPort(port)
Ok, das ist mein Kandidat. Ich hab es jetzt nicht getestet, aber wartet der dann wirklich so lange bis was passiert beim async-lesen? Und abbrechen... ah, ich muß mal schaun, vielleicht find ich was bei den Autodocs.
--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 15.12.2006 um 18:11 Uhr geändert. ]

[ Dieser Beitrag wurde von Ralf27 am 15.12.2006 um 18:12 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

15.12.2006, 18:53 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von Ralf27:
Ich weis leider nicht wo ich da ansetzen soll. Es läuft ja keine Leseaktion beim CON-Fenster, weil ich ja nix eingebe, wenn ich das Fenster schliese.

AArrgh
Dein Programm verschickt eine Leseanfrage oder es verschickt keine. Also Du bestimmst, wann eine Leseanfrage verschickt wird. Wenn Du eine verschickt hast, musst Du irgendwann, spätestens bevor Du den zur Leseanfrage gehörenden Speicher freigibst, auf die Rückmeldung wartest.

Zitat:
Ich möchte dann ja das CON:-Fenster schliesen. Ich weis jetzt auch nicht wie ich das Prüfen könnte, außer halt die anzahl der gelesen Bytes zu vergleichen. Aber ob das so richtig ist...

Ich versuch es noch mal:
Hast Du zu dem Zeitpunkt, zu dem Du das Fenster schliessen willst, eine Leseanfrage verschickt, auf deren Antwort Du noch nicht gewartet hast?

Zitat:
Warten? Hm, ne, da ist nix drin. Also egal was ist, muß ich also erst Warten (muß später mal nachsehn wie das gehn soll) und dann schliesen.

Wie bekommst Du denn jetzt eine Antwort von Deinen Leseanfragen?

Zitat:
EDIT:
WaitPort(port)
Ok, das ist mein Kandidat. Ich hab es jetzt nicht getestet, aber wartet der dann wirklich so lange bis was passiert beim async-lesen? Und abbrechen...

Nein, nicht abbrechen. Wenn WaitPort zurückkehrt, dann liegt mindestens eine Message vor. Dann holst Du die einfach ob, so wie Du immer die Antworten auf Deine Leseanfragen holst. Nur, dass Du dann den Inhalt ignorierst und die Datei schließt.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

15.12.2006, 19:07 Uhr

Ralf27
Posts: 2779
Nutzer

Zitat:
Original von Holger:
Hast Du zu dem Zeitpunkt, zu dem Du das Fenster schliessen willst, eine Leseanfrage verschickt, auf deren Antwort Du noch nicht gewartet hast?

Ich warte da nie auf eine Antwort, ich schaue einfach nach ob eine MSG auf dem Port liegt (GetMsg) und wenn eine da ist, dann quitiere ich diese (ReplyMsg) und schaue direkt nach wieviele Bytes(Gelesen=PEEKL(packet+dp_Res1)) da sind. Dann lese ich den Buffer aus und gebe das Packet frei. Ich benutze dazu kein WaitPort, aber das dürfte wohl falsch sein.

Das Problem:
Wenn ich das CON:-Fenster oder TCP: schliesen möchte, dann ist mir ja egal was da noch an Daten rüberkommen. Wenn ich dann also WaitPort einsetze, dann wartet er ja solange bis irgendetwas passiert. (ok, noch nicht getestet, mach ich aber gleich).

EDIT:
Dieses Anfordern und Freigeben läuft wärend der Laufzeit des Programmes die ganze Zeit. Bei TCP: und bei CON:. da läuft es. Und nicht anderst geb ich dann auch die Speicherbereiche frei. Und dann hauts das System um. Ok, aber ich werd dann immer mindestens einmal pro Port alle MSG anfordern und dann schliesen. Denn das fehlt wirklich noch. Hm.

--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 15.12.2006 um 19:11 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

15.12.2006, 19:32 Uhr

Ralf27
Posts: 2779
Nutzer

Ok, ich denke ich habs gefunden. Ich sollte wohl wirklich immer alle MSG vom Port holen, wenn ich den Port dicht mach. War mir leider nicht klar gewesen.

EDIT: Oder auch nicht... eben ist es wieder abgestürzt. Diesmal ohne CON-Fenster, sondern beim TCP:, das ich ja genau so auslese...

--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 15.12.2006 um 20:28 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

15.12.2006, 21:40 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von Ralf27:
Ich warte da nie auf eine Antwort, ich schaue einfach nach ob eine MSG auf dem Port liegt (GetMsg) und wenn eine da ist, dann quitiere ich diese (ReplyMsg) und schaue direkt nach wieviele Bytes(Gelesen=PEEKL(packet+dp_Res1)) da sind. Dann lese ich den Buffer aus und gebe das Packet frei. Ich benutze dazu kein WaitPort, aber das dürfte wohl falsch sein.

Nee, das ist soweit richtig. Solange Du eben nichts freigibst, das noch benutzt wird. Am Ende des Programm willst Du aber die Ressourcen freigeben, also musst Du dann eben warten.

Zitat:
Das Problem:
Wenn ich das CON:-Fenster oder TCP: schliesen möchte, dann ist mir ja egal was da noch an Daten rüberkommen. Wenn ich dann also WaitPort einsetze, dann wartet er ja solange bis irgendetwas passiert. (ok, noch nicht getestet, mach ich aber gleich).

Tja, ob Du Daten brauchst, oder nicht, spielt eben keine Rolle. Aber bei einem ordentlichen Netzwerkprotokoll wird normalerweise eh die Verbindung am Ende geschlossen, also kommen beim Leseversuch keine Daten mehr, sondern sofortiges EOF.

Bei der Console geht das natürlich nicht so einfach...
Im Raw-Modus kann man das dadurch umgehen, in dem man vor einer Leseanfrage einen Status-Report anfordert. Dann erhält man entweder nur den Status-Report oder Benutzereingaben, gefolgt von dem Status-Report. So kann man immer synchron bis zum Ende des Statusreport-Strings lesen, egal, ob Benutzereingaben vorliegen oder nicht. Nur muss man dann den Zeileneditiermodus, so man ihn braucht, von Hand nachprogrammieren.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

16.12.2006, 18:25 Uhr

Ralf27
Posts: 2779
Nutzer

Zitat:
Original von Holger:
Tja, ob Du Daten brauchst, oder nicht, spielt eben keine Rolle. Aber bei einem ordentlichen Netzwerkprotokoll wird normalerweise eh die Verbindung am Ende geschlossen, also kommen beim Leseversuch keine Daten mehr, sondern sofortiges EOF.

Ich lese ja nicht Byte für Byte, sondern stelle ein Buffer zur Verfügung. Aber selbst wenn ich Byteweise lesen würde, ich möchte ja auch abbrechen können wenn gerade keine Daten rüber kommen.
aber auch gerade bei der Console ist das Blöd, denn im normalfallen kommen dann keine Daten mehr rüber, denn die Console schickt ja immer nur dann Daten, wenn der User Return drückt.

Um es mal kurz zu machen:
Gibt es wirklich keine Möglichkeit nachzusehn ob Daten bei TCP: bereit liegen?

Das CON:-Problem kann ich durch ein Eigenkonstrukt umgehn, aber bei TCP: bekomme ich Probleme oder muß wohl dann doch denn "richtigeren" Weg über bsdsocket.lib gehn.

--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 16.12.2006 um 18:26 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

17.12.2006, 16:20 Uhr

Ralf27
Posts: 2779
Nutzer

Zitat:
Original von Holger:
Tja, ob Du Daten brauchst, oder nicht, spielt eben keine Rolle. Aber bei einem ordentlichen Netzwerkprotokoll wird normalerweise eh die Verbindung am Ende geschlossen, also kommen beim Leseversuch keine Daten mehr, sondern sofortiges EOF.

Beim Netzwerkprotokoll ist das ja auch kein großes Problem, denn ich kann ja einfach die Info übertragen das beendet werden soll und gut ist. Aber das Problem ist ja, wenn z.b. die Verbindung abbricht oder einer der Rechner sonst wie die Verbindung verliert. Dann fehlt halt die Info und dann? Das ist das Problem.

Es gibt da vermutlich noch eine Möglichkeit, bzw. eine schmutzige Methode: Wenn das Programm nicht richtig beendet werden kann, dann halt die entsprechenden Resourcen nicht freigeben. Aber so richtig gefällt mir das auch nicht...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

17.12.2006, 19:46 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von Ralf27:
Um es mal kurz zu machen:
Gibt es wirklich keine Möglichkeit nachzusehn ob Daten bei TCP: bereit liegen?

So sehr es mich selbst verwundert, dass so eine Funktion im AmigaDOS zu fehlen scheint: nein, ich habe keine entdeckt. Und die anderen Mitleser offenbar auch nicht.

Zitat:
Das CON:-Problem kann ich durch ein Eigenkonstrukt umgehn, aber bei TCP: bekomme ich Probleme oder muß wohl dann doch denn "richtigeren" Weg über bsdsocket.lib gehn.

Du brauchst kein Eigenkonstrukt. Wie ich schon schrieb, kannst Du statt CON: auf RAW: wechseln. Das sendet Tastendrücke unverzüglich an die Anwendung, d.h. Du musst lediglich die zeilenweise Eingabe (mit Editiermöglichkeit) selber programmieren, falls Du sie überhaupt brauchst.
Und über den Status-Report Trick, kannst Du, wie schon gesagt, dafür sorgen, dass beim nächsten Leseversuch auf jeden Fall Zeichen vorliegen.

Zitat:
Original von Ralf27:
Beim Netzwerkprotokoll ist das ja auch kein großes Problem, denn ich kann ja einfach die Info übertragen das beendet werden soll und gut ist. Aber das Problem ist ja, wenn z.b. die Verbindung abbricht oder einer der Rechner sonst wie die Verbindung verliert. Dann fehlt halt die Info und dann? Das ist das Problem.

Dann gibt es einen timeout.

Zitat:
Es gibt da vermutlich noch eine Möglichkeit, bzw. eine schmutzige Methode: Wenn das Programm nicht richtig beendet werden kann, dann halt die entsprechenden Resourcen nicht freigeben. Aber so richtig gefällt mir das auch nicht...

Nein, Du gibt alle Ressourcen frei, die freigegeben werden können (insb. UI) und wartest im Hintergrund, bis das Schließen von TCP: beendet ist (was definitiv irgendwann passieren wird, wie gesagt >timeout<) und beendest dann das Programm. Du kannst zusätzlich auch die Meldung ausgeben, dass Dein Programm noch auf die Beendigung der Netzwerkverbindung wartet, damit der Benutzer nicht denkt, Dein Programm hätte Speicherlecks...

Und, bevor Du anfängst mit bsdsocket... rumzuspielen: dieses API bietet Dir zwar per se asynchrone Funktionen an, beim Beenden des Programms kann es das obige Problem aber genauso wenig lösen. Alle Netzwerkprogramme haben die oben beschriebene Verhaltensweise, wenn ausgerechnet beim Beenden des Programm die Gegenstelle plötzlich nicht mehr antwortet.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

18.12.2006, 21:11 Uhr

Ralf27
Posts: 2779
Nutzer

Ok, somit sind wohl auch die beiden Probleme gelöst. An die CON:-Story geh ich später mal dran, TCP: hab ich jetzt damit schon gelöst.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

30.12.2006, 01:01 Uhr

Ralf27
Posts: 2779
Nutzer

Zitat:
Original von Holger:
Dann gibt es einen timeout.

Leider kommt dieser nicht. Hm, ich lasse zwar das Programm mit WaitPort darauf warten, es kommt aber leider nix rüber. Ein TimeOut ist doch bestimmt auch eine Msg.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

30.12.2006, 03:17 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von Ralf27:
Leider kommt dieser nicht. Hm, ich lasse zwar das Programm mit WaitPort darauf warten, es kommt aber leider nix rüber. Ein TimeOut ist doch bestimmt auch eine Msg.

Es gibt keine spezielle timeout-Message. Der TCP: handler zeichnet sich ja gerade dadurch aus, wie ein DOS-Handler zu funktionieren. Du bekommst von Timeout etwas dadurch mit, das die von Dir gestartete Aktion, wie Lesen, Schreiben oder Schließen beantwortet wird, und zwar mit einer Misserfolgsmeldung.

Du kannst das ja testen. Gebe copy TCP:server-xyz/datei RAM: in der Shell ein, also mit ner größeren Datei und kappe mittendrin die Verbindung. Wenn Du Zweifel hast, auf die harte Tour, Modem/Netzwerkkabel rausziehen.

Dann müsste es einen kurzen Moment dauern und der copy-Befehl mit einer Fehlermeldung abbrechen. Dann weißt Du, dass es funktioniert und auch, als welchen Fehler der handler so ein Ereignis an das Programm zurückgibt.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

30.12.2006, 22:13 Uhr

Ralf27
Posts: 2779
Nutzer

Zitat:
Original von Holger:
Du bekommst von Timeout etwas dadurch mit, das die von Dir gestartete Aktion, wie Lesen, Schreiben oder Schließen beantwortet wird, und zwar mit einer Misserfolgsmeldung.

Das versteh ich jetzt nicht. Wenn ich das jetzt nicht durch den MsgPort vom DosObject bekome, woher dann? Ich warte ja am Port mit Waitport auf irgendeine Nachricht, aber es kommt überhaupt nix.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

31.12.2006, 18:23 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von Ralf27:
Das versteh ich jetzt nicht. Wenn ich das jetzt nicht durch den MsgPort vom DosObject bekome, woher dann? Ich warte ja am Port mit Waitport auf irgendeine Nachricht, aber es kommt überhaupt nix.

Du bekommst, wie schon gesagt, nur dann eine Nachricht, wenn Du vorher eine Anfrage wie Lesen, Schreiben oder Schließen gesendet hast. Weil Du nur Antworten von Handler bekommst, er schickt Dir keine Meldungen von sich aus.

Wenn Du trotz Anfrage keine Rückmeldung nach einer gewissen Zeit (ab Netzwerkunterbrechung) bekommst, gibt es möglicherweise keinen korrekten timeout. Hast Du denn mal das mit dem copy-Befehl ausprobiert?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

31.12.2006, 18:32 Uhr

Ralf27
Posts: 2779
Nutzer

Zitat:
Original von Holger:
Du bekommst, wie schon gesagt, nur dann eine Nachricht, wenn Du vorher eine Anfrage wie Lesen, Schreiben oder Schließen gesendet hast. Weil Du nur Antworten von Handler bekommst, er schickt Dir keine Meldungen von sich aus.

Die Anfrage die ich als stelle ist lesen und das mit der Async-Routine. Und genau diesen Port frage ich ab.
Also, wenn ich eine Anfrage nach sagen wir mal 100 Bytes stelle und bis zum Zeitpunkt x noch keine Bytes angekommen sind und ich möchte das ganze ohne etwas gelesen zu haben beenden, wie kann ich alles freigeben? Ein weiteres warten auf ein Timeout endet im Endloswarten.

Ich bekomme übrigens ein TimeOut wenn ich z.b. eine Verbindung zu einer IP-Adresse aufbauen möchte die es nicht gibt. Dann wartet der Rechner ein paar Minuten und ich bekomme eine Fehlermeldung zurück.

Das Beispiel mit dem Copy hab ich allerdings noch nicht getestet.

--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

02.01.2007, 00:10 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von Ralf27:
Also, wenn ich eine Anfrage nach sagen wir mal 100 Bytes stelle und bis zum Zeitpunkt x noch keine Bytes angekommen sind und ich möchte das ganze ohne etwas gelesen zu haben beenden, wie kann ich alles freigeben? Ein weiteres warten auf ein Timeout endet im Endloswarten.

Das ganze war nur für das Szenario gedacht, dass es ein Protokoll gibt, aus dem sich das logische Ende ergibt. Also, dass die andere Seite entweder die Verbindung schließt oder den Geist aufgibt.

Wenn der andere Server am Leben bleibt, aber nicht daran denkt, Dir Daten zu schicken, kommst Du mit dem TCP: handler und den AOS3.x DOS-API nicht weiter.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

-1- 2

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > Textfenster

[ - Suche - Neue Beiträge - Registrieren - Login - ]