Probleme mit Textübergabe

Hallo wehrtes Forum....

Ich habe ein Problem.

Bei Texten die von FMS 32 pro zu anderen Programmen wie IBSS.exe übertragen werden, fehlen die Worte nach folgender Zeichenfolge. Die Zeichenfolge habe ich mal zum besseren Verständniss in eine Klammer gesetzt. ( -> ) Nach diesem Minus Zeichen und dem Pfeil wird das nächste Wort ausgelassen. Und nur das nächste Wort. Alle Worte nach dem ausgelassen Wort werden wieder übernommen. Ich denke mir mal, das heißt dann Übersetzt für das Programm FMS32pro === Sende den Text minus das nächste Wort nach dem Pfeil === Wie kann ich das verhindern? Das Wort wird bei der Übergabe von FMS32pro zu dem Programm wie z.B. IBSS.exe sozusagen gelöscht.

Wer kann mir da helfen? Kann man die Übergabeparameter in dieser Hinsicht manipulieren bzw. ändern?

Neeed Help....

Moin moin,

ist es immer das selbe Wort, welches gelöscht wird? hast Du schon einmal versucht den Übergabeparameter zu quoten? wenn es immer das selbe Worte ist, kann es sein, daß es durch IBSS.exe als Befehl interpretiert wird?

Nein, es sind immer verschiedene Wörter. Und ich habe sie auch nicht in der textfilter Datei stehen. Ich weiß ja noch nicht mal ob es am FMS32pro oder der IBSS.exe liegt.

Werde mal beiden eine Mail schicken. Vielleicht kennt ja noch einer das Problem?

Hey Leute!

Ich dachte, dass ich einen Text habe wo "->" drin vorkommt, aber solch einen habe ich nicht gefunden!

Kannst du nicht mit der Filterdatei von IBSS mal versuchen die Zeichenfolge "->" durch ein ">" zu ersetzen? Ich werde mal versuchen ein Text mit "->" zu verschicken! Melde mich gleich wieder!


-------------
Edit:

Der folgende FMS-Text:
BAB A7 Hannover -> Hamburg

wurde so bei FMS32pro angezeigt:
BAB A7 Hannover -> Hamburg

so an IBSS übergeben:
BAB A7 Hannover -> Hamburg

und so als SMS versendet bzw. zugestellt:
BAB A7 Hannover -> Hamburg

Wahrscheinlich liegt der Fehler in einen Filter bei dir von IBSS vielleicht? Kuck doch noch mal alles durch.

Bei mir ist es so....

Der folgende FMS-Text oder Digital Alarm:
BAB A7 Hannover -> Hamburg

wurde so bei FMS32pro angezeigt:
BAB A7 Hannover -> Hamburg

Und ab hier fehlt es dann!

so an IBSS übergeben:
BAB A7 Hannover -

und so als SMS versendet bzw. zugestellt:
BAB A7 Hannover -

Dabei ist es übrigens egal ob das Klammer Zeichen > oder so < in dem Text steht. Das Wort welches hinter diesem Zeichen kommt wird, weg gelassen. Und zwar schon bei der Übergabe zur ibss.exe. Also muß das Problem ja bei FMS32pro und der Übergabe liegen. Oder sehe ich das falsch?

Weil es schön ist, poste ich hier mal alle meine Daten!

Das Empfängt FMS32pro:

BAB A7 Hannover -> Hamburg[EOT][EOT]

Daraufhin wird diese Aktion gestartet:

C:\Programme\ibss\MitteilunglesenXXXXXXXX.bat %3

Die Aktion hat folgenden Inhalt:

@echo off
rem Herr XYZ
start C:\Programme\ibss\ibss.exe /C:config.txt /E:0123456789 /N: {datumlang} {zeitkurz} Einzelruf XXXXX: %*

Die LOG Datei in IBSS.exe sieht wie folgt aus:

10:40:03 IBSS gestartet : C:\Programme\ibss\ibss.exe
10:40:04 -- SILENTMODE --------------------------------------------------------
10:40:04 Username : XXXXXXX
10:40:04 Passwort : ******
10:40:04 Nummer : 0123456789
10:40:04 SMS-Typ : 2
10:40:04 FlashSMS : Nein
10:40:04 Absender :
10:40:04 Übergebener Text : {datumlang} {zeitkurz} Einzelruf XXXXXXX: BAB A7 Hannover -
10:40:04 Gesendeter Text : 27.05.05 10:40 Einzelruf XXXXXXX: BAB A7 Hannover -
10:40:04 Sendestatus : [ 100 ] SMS wurde erfolgreich verschickt

Die Config Datei hat folgenden Inhalt:

/U:XXXXX
/P:XXXXX
/T:2
/SILENT
/OP:probelist.txt
/OB:blacklist.txt
/OF:textfilter.txt


probelist, blacklist sind leer. Also kann hier schoneinmal nichts mehr gefiltert werden. Im Textfilter steht [EOT]. Das habe ich aber auch schon einmal ohne jegliche Filter probiert. Mit dem gleichen Ergebniß.

Woran kann es sonst liegen? An dem Übergabeparameter von FMS32pro?

Neeeeeeeeeeeeed heeeeeeeeeeeeeeelp........

Hier noch etwas was mir aufgefallen ist. Teilweise werden die Wörter die ausgelassen wurden im IBSS Ordner als 0 Byte Datei gespeichert. Die Datei sind also mit 0 Byte leer und nur der Dateiname weißt auf das Wort hin, welches bei der Übergabe irgendwie verloren gegangen ist. :-)

Habe mal einen Screenshot angehängt.

Hey Leute !

Das ist ganz normal, dass das nicht funktioniert.
Die Klammern < und > sind DOS-Steuerzeichen, die die Ausgabe in eine Datei umleiten.

BSP:

dir *.* > liste.txt

Dieser Befehl listet alle Dateien auf. Aber nicht auf den Bildschirm, sondern umgeleitet in die Datei liste.txt. Probierts mal aus.

Der Fehler liegt nun an der Stelle, an der IBSS gestartet wird. Mitten im Text erscheint plötzlich das > und DOS denkt, es soll die Ausgabe umleiten. Das Wort was NACH dem > erscheint, wird dann als Dateiname benutzt.

Lösung :

C:\Programme\ibss\MitteilunglesenXXXXXXXX.bat %3

Die Aktion ändern auf das hier :

C:\Programme\ibss\MitteilunglesenXXXXXXXX.bat "%3"

Die "" sagen jetzt aus, dass alles was in den Anführungszeichen steht ein Text ist. Dann schaut DOS gar nicht nach, ob es Steuerzeichen gibt oder nicht.

Sollten die "" auch in der SMS erscheinen, kannste die einfach mit dem Filter entfernen. Das > lässt sich nicht mit dem Filter entfernen, da es ja noch vor IBSS von DOS falsch interpretiert wird.

Etienne hat vermutlich auch automatisch die "" benutzt, und deshalb gab es bei ihm diesen Fehler nicht.

Gruß Joachim

Gruß Joachim

Zitat:

---

Original geschrieben von Erstversuch
Hier noch etwas was mir aufgefallen ist. Teilweise werden die Wörter die ausgelassen wurden im IBSS Ordner als 0 Byte Datei gespeichert. Die Datei sind also mit 0 Byte leer und nur der Dateiname weißt auf das Wort hin, welches bei der Übergabe irgendwie verloren gegangen ist. :-)

Habe mal einen Screenshot angehängt.

---

Jetzt habe ich auch verstanden, was Du mit den "spitzen Klammern" meinst. Unter DOS (und auch in den Eingabeaufforderungsboxen von Windows) bedeuten diese Zeichen die Umleitung der Standard-Ein/Ausgabe von/in eine Datei anstelle von Tastatur/Bildschirm. Wobei "Datei" auch eine "Schnittstelle" vie COMn: oder LPTn: sein kann. Um solche Interpretationen durch das Betriebssystem zu vermeiden sind solche Zeichen zu quoten, bzw. der gesamte Übergabeparameter ist zu quoten (Einfassen in "").

Trotz aller anderslautender Argumente hat es noch nie geschadet die Grundbegriffe von MS-DOS verstanden zu haben, denn diese haben auch unter dem aktuellsten Windows noch immer Gültigkeit.

@ MiThoTyN:

Das war alles richtig. Die "" werden durch den Filter rausgenommen. Jetzt ist alles wieder okay... :-)

Das ist ja aber auch eine blöde Leitstelle die ein solchen Hinweis Pfeil in ihre Texte mit reinsetzt.

Schööööööööönen Dank dafür...............!!!

Zitat:

---

Original geschrieben von Erstversuch
@ MiThoTyN:

Das war alles richtig. Die "" werden durch den Filter rausgenommen. Jetzt ist alles wieder okay... :-)

Das ist ja aber auch eine blöde Leitstelle die ein solchen Hinweis Pfeil in ihre Texte mit reinsetzt.

Schööööööööönen Dank dafür...............!!!

---

Tja wie heißt es so schön in dem Sprichwort von der Schönheit?

Dieses Problem taucht immer dann auf, wenn echte MS-DOS-Kompatibilität gefordert ist. Sei Froh, daß die nach den Spitzen Klammern nicht noch andere für MS-DOS mit besonderer Bedeutung versehene Sonderzeichen verwendet haben wie doppelte Doppelpunkte Mehrfachpunkte oder gar die unter DOS-Programmierern sehr beliebten "Graphikzeichen". DAnn hättest Du immer Meldungen über ungültige Dateinamen und so erhalten.

Hallo, ich habe so ein ähnliches Problem.

Der FMS-Text:

07:33 200512345 Verkerhsunfall a-dorf b-dorf

Wird ohne Probleme an die Batch-Datei übergeben.

07:33 200512345 Verkerhsunfall a-dorf >>>> b-dorf

Wird hingegen durch die >>> gar nicht übergeben.

Meine Aktion in FMS32 Pro lautet. c:\alarmruf\testintxt.bat "%1 %2"

Hat noch einer Ideen zu diesem Thema?

Servus!

Das Problem sind die ">>"-Zeichen.
Diese Zeichen werden als Umleitungszeichen interpretiert.
So kannst Du z.B. mit folgendem Code einen Text in eine Datei schreiben:

Code:

---

echo. So ein wunderschoener Tag >> schoen.txt

---

Nun steht in dem File schoen.txt der Text "So ein wunderschoener Tag".
Genauso interpretiert Deine Batch-Datei nun diese Übergabe.
Du musst hier also Deine Batch-Datei diesem Umstand anpassen. Am besten schreibst Du Deine ganze Batch mal hier rein, dann kann man es eher beurteilen.

Gruß
Alex

Die testintxt.bat hat folgenden Inhalt.
---------------------------------------------
c:\alarmruf\wait 3
echo "%*" >> c:\alarmlog\%date%.txt
c:\alarmruf\wait 3
----------------------------------------------


Meine Aktion in FMS32 Pro lautet.
----------------------------------------------
c:\alarmruf\testintxt.bat "%1 %2"
----------------------------------------------

Die Batch-Datei wird in der 2. Zeile abgebrochen.
Leider kann ich den Fehler nicht lesen da das Fenster gleich geschlossen wird.

Servus!

Dann mach' mal nach jeder Zeile ein "pause", dann kannst Du auch den Fehler lesen und sehen, was die Batch da in die CommandLine schreibt.

Gruß
Alex

Wenn man die Batchdatei über eine Eingabeausforderungsmaske startet, kann man ganz bequem mitlesen ohne an der Batch was zu verändern. Das ist gerade bei größeren Batchdateien sinnvoll. Die Eingabeaufforderung kann man auch so aufrufen:
Start - Ausführen - cmd (command bei Win 9x)

Zitat:

---

Original geschrieben von Kalle
Hallo, ich habe so ein ähnliches Problem.

Der FMS-Text:

07:33 200512345 Verkerhsunfall a-dorf b-dorf

Wird ohne Probleme an die Batch-Datei übergeben.

07:33 200512345 Verkerhsunfall a-dorf >>>> b-dorf

Wird hingegen durch die >>> gar nicht übergeben.

Meine Aktion in FMS32 Pro lautet. c:\alarmruf\testintxt.bat "%1 %2"

Hat noch einer Ideen zu diesem Thema?

---

Unter DOS gibt es einige Sonderzeichen, die besondere Funktionen ausgeführt haben.

Dazu zählen unter anderem die Zeichen

<
>
|
+
/ -

Die Zeichen < und > bewirken die Ein- und Ausgabeumleitung, dabei kann das Zeichen > einzeln oder doppelt auftreten.
Einzeln bedeutet es Ausgabe in die hinter dem Zeichen angegebene Datei zu schreiben. Gebe ich dagegen direkt hintereinander 2 > (onhne Leerzeichen dazwischen) so bedeutet es Ausgabe in die Datei umleiten, mit der Besonderheit, daß die Datei, wenn sie besteht nicht überschrieben wird, sondern die neue Ausgabe an die bestehende Datei angehängt wird.

Um solche Zeichen als Text in Parametern zu verwenden muß man diese in "-Zeichen einschließen (quoten), damit das Betriebssystem erkennt, daß diese Zeichen KEINE Funbktionalität mehr besitzen.

Hallo kalle!

Zitat:

---

Original geschrieben von Kalle
[BMeine Aktion in FMS32 Pro lautet.
----------------------------------------------
c:\alarmruf\testintxt.bat "%1 %2"
----------------------------------------------

Die Batch-Datei wird in der 2. Zeile abgebrochen.
Leider kann ich den Fehler nicht lesen da das Fenster gleich geschlossen wird. [/B]

---

Versuchs mal folgendermassen:

c:\alarmruf\testintxt.bat "%1" "%2"

Ich hatte jetzt leider keine Möglichkeit das zu testen, aber versuchen kannste das ja mal.

Gruß FMS-Master

Hallo, vielen Dank füt die Antworten.

Paue Befehl!
Die Batch-Datei schließt sich einfach in der 2. Zeile. Pause hatte ich in der 3. Zeile eingebaut.

CMD!
Im CMD hatte ich den Text zwischen die " Zeichen gestellt. Also ansatt "%*" "07:33 200512345 Verkerhsunfall a-dorf >>>> b-dorf"
Da geht es.??????????

" Zeichen!
Die " Zeichen habe ich an allen Stellen ausprobiert. Leider auch ohne Erfolg.

c:\alarmruf\testintxt.bat "%1 %2" geht nur ohne >>>>> im Text

c:\alarmruf\testintxt.bat "%1" "%2" geht nur ohne >>>>> im Text

"c:\alarmruf\testintxt.bat %1 %2" geht gar nicht

Blöde Leitstelle bei mir oder?

Hallo Kalle!

Zitat:

---

Original geschrieben von Kalle
CMD!
Im CMD hatte ich den Text zwischen die " Zeichen gestellt. Also ansatt "%*" "07:33 200512345 Verkerhsunfall a-dorf >>>> b-dorf"
Da geht es.??????????

---

Das ist doch schonmal super!

Habe leider im moment garkeine zeit für dich zu testen, aber versuch mal folgendes:

In der Batch anstatt
echo "%*" >> c:\alarmlog\%date%.txt

echo "%1" "%2" >> c:\alarmlog\%date%.txt

so könnte es klappen.

Und nochmal zu den " unabhängig von dem Problem sollte die
" so gesetzt sein wie ich geschreiben hab, also "%1" und "%2" anders macht es programmiertechnisch keinen sinn.

FMS-Master

Jetzt geht es endlich!

Meine Aktion in FMS32 Pro lautet. Wichtig die " Zeichen verwenden.
----------------------------------------------
"c:\alarmruf\test in txt.bat" "%1" "%2"
----------------------------------------------


Die test in txt.bat hat folgenden Inhalt. Wichtig keine " Zeichen verwenden.
---------------------------------------------
c:\alarmruf\wait 3
echo %* >> c:\alarmlog\%date%.txt
c:\alarmruf\wait 3
----------------------------------------------

Hmm,

sei mir nicht böse, aber wenn man Leerzeichen in Dateinamen verwendet kann nix Gescheites dabei rauskommen. Besser ist hier die Verwendung von Unterstrichen oder die Nutzung von Gross-/Kleinschreibung.

Gruß
Alex

noch was zu diesem thema.. ich habe probleme mit der übergabe von umlauten (Ä.Ü,Ö)

diese weden als leerzeichen übergeben kann das sein bsp

schö 1-11
kommt als
sch 1-11 in der textdatei an

Servus!

Das ist ein Problem mit dem Zeichensatz. Der DOS-Zeichensatz unterstützt normalerweise keine Umlaute. Wir hatten schonmal drüber diskutiert, bemüh' doch bitte mal die Suchfunktion, da müsstest Du eigentlich was zum Thema Windows- und DOS-Zeichensatz finden.

Gruß
Alex

jo danke ich dachte halt es passt in diesen thread so schlimm is es auch nicht -- ich schmeiss mal die suchkiste an...

danke

Zitat:

---

Original geschrieben von Quietschphone
Servus!

Das ist ein Problem mit dem Zeichensatz. Der DOS-Zeichensatz unterstützt normalerweise keine Umlaute. Wir hatten schonmal drüber diskutiert, bemüh' doch bitte mal die Suchfunktion, da müsstest Du eigentlich was zum Thema Windows- und DOS-Zeichensatz finden.

Gruß
Alex

---

Wenn man mit MS-DOS groß geworden ist, kennt man die Probleme und vermeidet sie durch konsequente NICHTNUTZUNG der entsprechenden Zeichen. User, die "nur" unter Windows groß geworden sind, wundern sich immer über solche Probleme, weil Windows allen Nutzer immer wieder klar zu machen versucht, daß es keine Probleme mehr mit länderspezifischen Sonderzeichen gibt, was leider, wie man an solchen Threads sieht, in der Realität ganz anders aussieht. Aber wie soll ein Nicht -Europäer (MS-Boss B.G.) solche Probleme verstehen, wenn die in Amerika solche Zeichen gar nicht kennen?

Ich bin unter dos groß geworden nur wusste ich nicht dass mein LCD Display programm die texte im windowsformat braucht.