Forum: PC-Programmierung raw data per json


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Hmm ich habe wohl ein Problem :( und zwar wollte ich raw data in ein 
Json Object bzw. Array übergeben. Um sie hinterher auf der Client Seite 
zu verarbeiten. Denn hierzu fehlen ein paar Informationen die der Client 
erst zusammentragen muss.

Es ginge schon aber ungemein umständlich.. In dem man jedes Byte in ein 
Objekt packt {"byte_1": data}  zumal müssen Sonderzeichen maskiert 
werden und aus den daten werden strings.


Gibt es keine Möglichkeit ein Array aus Daten zu senden ? Diese 
gekapselt in einen Objekt ?

von Stephan S. (uxdx)


Bewertung
0 lesenswert
nicht lesenswert

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Hat sich erledigt ... mal wieder zu kurz gedacht.. man packe diese in 
ein array und man muss die Daten als String dort rein packen ;). Ich 
Idiot habe zwar richtig gedacht aber das nicht umgesetzt...

: Bearbeitet durch User
von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Marco H. schrieb:
> Hat sich erledigt ... mal wieder zu kurz gedacht.. man packe diese in
> ein array und man muss die Daten als String dort rein packen ;). Ich
> Idiot habe zwar richtig gedacht aber das nicht umgesetzt...

Es muss kein String sein. Für String muss man die Daten wieder irgendwie 
Codieren, z.B. als HEX oder als Bytes mit Leerzeichen o.ä.

Ein Number-Array mit Bytes ist auch eine häufig verwendete Möglichkeit 
um Rohdaten zu übertragen. Und Numbers sind eindeutig vom Wert her und 
müssen nicht noch zusätzlich mit Textfunktionen geparsed werden, wenn 
JSON selbst bereits geparsed vorliegt.

: Bearbeitet durch User
von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
1
{"raw":[1,2,23,255,0,10,128,17,23]}

So einfach kann json zum Transport von "raw data" aussehen.

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Ist ja trotzdem ein String ! Aus 100 wird 1 0 0.. denn sonst wird aus 
dem value ein Zeichen welches maskiert werden muss. Wie soll der Parser 
wissen was als String oder Byte zu betrachten ist ?

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Die einzige Möglichkeit die Daten base64 codieren !

: Bearbeitet durch User
von Vincent H. (vinci)


Bewertung
0 lesenswert
nicht lesenswert
Wie wärs stattdessen ein Serialisierungsformat zu wählen, dass 
Binärdaten unterstützt? Etwa BSON oder MessagePack.

von 50c (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Marco H. schrieb:
> Ist ja trotzdem ein String

Was ist JSON (Zitat Wikipedia): "Die JavaScript Object Notation, kurz 
JSON [ˈdʒeɪsən], ist ein kompaktes Datenformat in einer einfach lesbaren 
Textform zum Zweck des Datenaustauschs zwischen Anwendungen."

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Also wenn man das als Hex übergibt braucht man zwei Byte 0..9 und A..F. 
dezimal maximal 3 Byte, base64 min 5 Byte..

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Marco H. schrieb:
> Ist ja trotzdem ein String !

Unsinn. Natürlich ist JSON erstmal immer ein String. Aber das lässt man 
normalerweise erst mal durch einen Parser.
Und wenn du das JSON mal geparsed hast, hast du direkt Zugriff auf alle 
Array Element als Number.
Schickst du aber alles als String, musst du diesen String danach nochmal 
selbst irgendwie parsen und die Binärdaten rausfummeln. Bei der 
Number-Array Methode entfällt dieser Schritt.

> Also wenn man das als Hex übergibt braucht man zwei Byte 0..9 und A..F.
> dezimal maximal 3 Byte, base64 min 5 Byte..

Wenn es dir um den Platzbedarf geht und um das letzte gesparte Byte ist 
ein Textformat wie JSON sowieso nicht das Richtige. Dann übertrage 
direkt alles Binär.

von Marco H. (damarco)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem hex klappt auch nicht ! Es muss als string markiert sein 
"ff" dann werden daraus 4 byte und somit kann man das auch dezimal 
ausgeben..

"A number is very much like a C or Java number, except that the octal 
and hexadecimal formats are not used."

Man darf sich gerne daran versuchen ;) https://jsoneditoronline.org/

Sobald A..F oder 00 auftaucht wird das json ungültig..

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Marco H. schrieb:
> Sobald A..F oder 00 auftaucht wird das json ungültig..

Die zahlen müssen halt DEZIMAL sein du Genie. Wo ist das Problem?

Rufus hat es doch sogar hingemalt, quasi meinen Post darüber 
visualisiert.

Bekommst du immer so wenig gebacken? Ist ja furchtbar.

: Bearbeitet durch User
von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Es ging darum das verfahren zu finden nicht unnötig die payload 
aufzublasen. Teilweise hängen da mal 500 byte an.. Die sich nur am ende 
wirklich verwerten lassen. Da hierzu ein paar andere Daten nötig sind...

Die meisten Descriptoren kommen ohne externe values aus.. Einige sind 
aber so Geräte spezifisch das dessen Steuerungsdaten RAW angehängt 
werden.

Ist erstmal nicht meine Baustelle, aber betrachtet Java bzw. Javascript 
nicht alles als string ? In so fern ist es wurst, nur mit C etc. muss 
man den string wieder umwandeln.

Das hatte ich schon längst auch ohne diesen Hinweis schon gebacken... 
was glaubst du wie viele Kuchen ich schon gebacken haben, das ist nur 
ein einziger Mückenschiss vom ganzen Projekt.

: Bearbeitet durch User
von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Marco H. schrieb:
> Es ging darum das verfahren zu finden nicht unnötig die payload
> aufzublasen.

Was heißt "unnötig"? Allein schon JSON selbst benötigt unnötig viel 
Overhead. Übertrage alles Binär wenn du das letzte Byte sparen willst. 
Wie ich schon sagte.

> Ist erstmal nicht meine Baustelle, aber betrachtet Java bzw. Javascript
> nicht alles als string ?

Wie kommst du auf solch einen Unsinn? Erstmal hat Java damit gar nichts 
zu tun und zweitens gibt es in der JavaScript/ JSON Welt genau 
spezifierte Datentypen. Schlage sie nach wenn du sie nicht kennst.
Wenn alles String wäre könnte man nie damit rechnen.

> In so fern ist es wurst, nur mit C etc. muss
> man den string wieder umwandeln.

Wenn du ein Textformat wie JSON nutzt musst du parsen. Ja. Liegt in der 
Natur der Sache. Willst du nicht? Übertrage Binär.

> Das hatte ich schon längst auch ohne diesen Hinweis schon gebacken...
> was glaubst du wie viele Kuchen ich schon gebacken haben, das ist nur
> ein einziger Mückenschiss vom ganzen Projekt.

Ich denke nicht dass ich die Essen wollte. Deine Kompetenzt scheint eng 
begrenzt aufs Maulhurentum zu sein.

Deine konkrete Eingangsfrage:
> Gibt es keine Möglichkeit ein Array aus Daten zu senden ? Diese
> gekapselt in einen Objekt ?

Wurde doch 100% beantwortet. Und auch noch positiv. Also woran hängts 
jetzt noch?

: Bearbeitet durch User
von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Wenn man Javascript Code einließt wird das als String geladen und 
interpretiert, oder etwa nicht? Der Code ist als String codiert, wenn 
ich den Editor öffne kann ich ihn lesen. Einen Objekt Code nicht den ein 
Compiler erstellt hat und auch dessen Daten nur wenn sie als String 
codiert sind.

Wenn ich einer Javascript Funktion etwas übergebe was aus einer response 
per Ajax stammt ist diese ein string -> steht im HTML header wie dieser 
codiert ist...

Die Datentypen werden vereinbart weil so der Interpreter weiß mit 
welchen Type er es zu tun hat. Hierzu sind weitere "Strings" nötig um 
ihm das mitzuteilen ;)..

Aus dem json weiß auch Javascript was es vor sich hat und somit dürfte 
man eine dezimal Zahl so übergeben können... Keine Ahnung ob der 
Interpreter intern noch etwas macht... Durch die Steuerzeichen im json 
sind die Datentypen klar definiert. Deswegen kann nicht raw bytes 
versenden, da sie Zeichen entsprechen die in der Codetabelle hinterlegt 
sind. Das Json wird dann ungültig sobald das value werte von 
reservierten Zeichen annimmt

Es hängt nirgends...

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Marco H. schrieb:
> Deswegen kann nicht raw bytes versenden,

Über die HTTP-Schnittstelle, über die "Ajax" Daten transportiert, lassen 
sich auch beliebige Binärdateien transportieren.

Aber solange noch nicht mal ansatzweise klar ist, was jetzt eigentlich 
Dein Problem ist, ist jedes Gerate recht sinnlos.

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Ja klar ;) es ging wie schon erwähnt die Möglichkeit zu finden die am 
wenigsten bytes verbraucht.  Das ist aber nicht immer das Ziel, wie ich 
jetzt  an einer anderen stelle verstellen musste. Bei Tokens oder AES 
Keys macht es schon Sinn sie Base64 zu codieren.

Was als RAW zurückgegeben wird sind Steuerungsdaten, die Beschreibung zu 
diesen Daten ist auf einen anderen Descriptor zu finden. Deswegen macht 
es keinen Sinn das Json weiter aufzudröseln, das soll der Empfänger des 
json bewerkstelligen. Der hat auch die Möglichkeit des die Infos hierzu 
zu holen.

Es ist immer noch der AVB Controller ;) Das Thema ist viel zu komplex um 
es hier verständnisvoll zu beschreiben.

Ich habe noch ein anderen Thema was es zu lösen gilt..

Das parsen des Querys von der REST.

Klar man kann es staffeln

../1/2/3
../1/2/4
../1/2/5/6

Das Problem ich muss min 80 cmds pro Subtype in summe über 200 oder mehr 
auseinander halten..
Die Lösung nach Schnittmengen funktioniert aktuell aber ich denke das es 
Performance Probleme bekomme.

Ich habe mir mal uriparser angeschaut, das macht im groben nichts 
anderes wie ich.. Gibt es alternativen ?

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Marco H. schrieb:
>> Deswegen kann nicht raw bytes versenden,
>
> Über die HTTP-Schnittstelle, über die "Ajax" Daten transportiert, lassen
> sich auch beliebige Binärdateien transportieren.
>
> Aber solange noch nicht mal ansatzweise klar ist, was jetzt eigentlich
> Dein Problem ist, ist jedes Gerate recht sinnlos.

Ja aber nie ohne HTTP Header(String) in dem vereinbart wird was dran 
hängt...

Beim Query Problem wäre es eben schön wenn man einen request einfach 
hinzufügt und die Bibliothek es so in die Liste packt das sie optimal 
durchsucht wird.

Ich will vermeiden jedes mal die Stelle im Code zu suchen wo es eben 
optimal wäre den request einzufügen.

Vielleicht wurde das Problem schon mal gelöst?

: Bearbeitet durch User
von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Marco H. schrieb:
> Ja aber nie ohne HTTP Header(String) in dem vereinbart wird was dran
> hängt...

Mein Verdacht, daß das Problem, das Du lösen willst, an einer komplett 
anderen Stelle zu suchen ist, hat sich soeben verhärtet.

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
hmm ich sende das jetzt als Array und Dezimal.. Bei den tokens muss ich 
mal schauen ob es nicht besser ist sie base64 zu kodieren. Bislang gibt 
es aber noch kein AVB Gerät was dies unterstützt ! Also 
Verschlüsslung...

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Marco H. schrieb:
>> Ja aber nie ohne HTTP Header(String) in dem vereinbart wird was dran
>> hängt...
>
> Mein Verdacht, daß das Problem, das Du lösen willst, an einer komplett
> anderen Stelle zu suchen ist, hat sich soeben verhärtet.

Die Stelle zwischen Tastatur und Stuhl vermute ich.

Und ihm scheint es völlig daran zu fehlen in Schichten zu denken. HTTP 
enthält Header und Daten. Die Daten könnten Binär sein, oder JSON oder 
HTML.
Hat nichts damit zu tun das der HTTP Header Textbasiert ist.

Also da hängts sowohl an grundlegendem Verständnis der Materie als auch 
am sinnvollen Erfassung und Wiedergeben des aktuellen Problems mit der 
Teilaufgabe.

> Vielleicht wurde das Problem schon mal gelöst?

Bestimmt. Und sobald du es ohne Gestotter beschreiben kannst kann man 
sogar eine solche Lösung suchen.

von Ralf D. (doeblitz)


Bewertung
0 lesenswert
nicht lesenswert
Marco H. schrieb:
> Ja klar ;) es ging wie schon erwähnt die Möglichkeit zu finden die am
> wenigsten bytes verbraucht.  Das ist aber nicht immer das Ziel, wie ich
> jetzt  an einer anderen stelle verstellen musste. Bei Tokens oder AES
> Keys macht es schon Sinn sie Base64 zu codieren.

Dann nimm ein geeignetes Content-Encoding im HTTP-Layer (z.B. gzip), das 
spart die meisten Bytes ein und ist für die Anwendungsebene transparent.

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Rufus Τ. F. schrieb:
>> Marco H. schrieb:
>>> Ja aber nie ohne HTTP Header(String) in dem vereinbart wird was dran
>>> hängt...
>>
> Und ihm scheint es völlig daran zu fehlen in Schichten zu denken. HTTP
> enthält Header und Daten. Die Daten könnten Binär sein, oder JSON oder
> HTML.
>

Content-Type: application/xxx bestimmt wie die Daten zu behandeln sind.. 
Das habe ich schon verstanden...

Das Problem besteht drin das ich die Daten leider in ein Json kapseln 
muss.

Das json kann beliebig groß werden das ist nicht das Problem, sobald der 
Buffer voll ist werden die Zeichen über das fastcgi Modul -> Webserver 
zum Client geschrieben.

Was ich aber bedenken muss wie man sie auf dieser Seite wieder zusammen 
bekommt. Denn hier wird alles komplett eingelesen und geparst. Ein 
Browser bricht schon merklich bei ein paar MB zusammen und der parser 
braucht massiv CPU Zeit... Außerdem sollte die Methode kompatible zu dem 
sein die solche Daten verarbeiten. Wir reden hier über 500bytes ;) es 
denen im schlimmsten Fall 33% mehr werden durch das base64..

Wenn ich sie in einen String packte versucht der parser diese nicht in 
ein Array zu organisieren, da ist der String ewt. besser in base64 
codiert da setzt der parser zwei pointer Anfang und Ende vom String 
Object. Auf solche Gedanken wollte ich hinaus...

: Bearbeitet durch User
von Marco H. (damarco)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mal zum test mit Firefox öffnen und die CPU bzw. Speicherverbrauch 
beobachten ... Die Daten kommen aus dem Controller und sind vom 
ADP(AVDECC Discovery Protokoll) die Liste ist künstlich zum Test 
aufgebläht..

Durch das MAPP ist die Anzahl der Geräte auf 255 begrenzt momentan....

Der Token unten war mal gedacht den client die Möglichkeit zu geben nur 
teile der Liste abzufragen. Also die Anzahl der Results im Query 
anzugeben. Dann bekommt er einen token und damit lässt sich der Rest 
abfragen...

: Bearbeitet durch User
von Marco H. (damarco)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal zwei descriptoren aus einen Gerät..

Entity u. configuration

Configuration beschreibt welche "TOP" descriptoren das Gerät unterstützt 
in diesen finden sich weitere...

Alle zusammen beschreiben das Gerät. Mit dieser Beschreibung lassen sich 
auch  die Daten per AECP(AVDECC Enumeration and Control Protokoll) 
auswerten.

Da die response auf diese commands Geräte spezifisch ist und dessen 
Bedeutung  nur im Zusammenhang mit den Descriptoren decodiert werden 
kann.

Das hängt dann value raw hinten dran ;) nun war das Problem wie diese 
Daten am besten übergeben..

: Bearbeitet durch User
von Marco H. (damarco)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Problemfall ist dann das AECP command auth_get_identity wo die Signatur 
RAW nun dezimal dran hängt...

: Bearbeitet durch User
von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Marco H. schrieb:
> Also wenn man das als Hex übergibt braucht man zwei Byte 0..9 und A..F.
> dezimal maximal 3 Byte, base64 min 5 Byte..

Hä, das ist völliger Quatsch. Base64 ist natürlich kompakter als Hex, 
denn Base64 kodiert 6=log2(64) Bit Nutzdaten pro 8 Bit, während Hex nur 
4=log2(16) schafft. Natürlich ist es auch kompakter als Dezimal mit ca. 
3.3=log2(10) Bit pro 8 Bit. Hex ist damit übrigens auch kompakter als 
Dezimal.

Also ja, wenn man wirklich Binärdaten in einem JSON-File haben muss, ist 
base64 vermutlich die beste Variante. Base85 würde auch gehen.

: Bearbeitet durch User
von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Eben steht ja auch weiter unten da sich im json kein hex zahlen 
übergeben lassen....

Danke, base64 wurde ja entwickelt im Binäre Daten über Text basierte 
Protokolle zu versenden. Einen encoder, decoder habe ich auch schon mal 
programmiert.. MQTT über Websocket :)

: Bearbeitet durch User
von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Marco H. schrieb:
> Problemfall ist dann das AECP command auth_get_identity wo die Signatur
> RAW nun dezimal dran hängt...

Und was soll daran jetzt das Problem sein? Ich kann es immer noch 
nicht nachvollziehen.

> Eben steht ja auch weiter unten da sich im json kein hex zahlen
> übergeben lassen....

Das ist natürlich Unfug.
1
{"bla":"DEADFACE"}

ist sauberes Json. Nur macht ein Json-Parser daraus einfach nur einen 
String, aber warum in drei Teufels Namen soll das ein Problem sein? Das 
kann man nun wirklich in jeder Programmiersprache der Welt zerklöppeln.

von Marco H. (damarco)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ja als String aber nicht als zahl {"bla":0F} -> ungültig, dezimal 
{"bla": 15} -> gültig

{"bla":[10,100,65,10,22]} verbraucht vermutlich mehr Ressourcen beim 
parsen als  base64 codiert als String {"bla":"MTAxMDA2NTEwMjI="}

Die Datei auth_get_identity.json als base64 codiert...

Lesen kann man die Daten wieso so nur schwer ;) Es galt eben den besten 
weg herauszuarbeiten. Der heißt für mich nun base64...

: Bearbeitet durch User
von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Marco H. schrieb:
> {"bla":[10,100,65,10,22]} verbraucht vermutlich mehr Ressourcen beim
> parsen als  base64 codiert als String

Vermutlich.

Um welche Menge an Daten geht es Dir denn? Tatsächlich nur um 500 Bytes?

Dann ist Deine komplette Fragestellung letztlich kaum was anderes als 
ein Trollbeitrag.

von Purzel H. (hacky)


Bewertung
0 lesenswert
nicht lesenswert
Ein Maximaltroll. Die Datenmenge ist doch voellig egal. Es muss (!) 
ASCII sein. Schluss. Nicht weiter denken. Machen.

Ich schau mir mit dem Brower Serverlogfiles von 150'000 Zeilen an. Ja. 
Und. Solange das nicht ueber Mobil geschehen muss..

: Bearbeitet durch User
von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
erstmal schon aber es könnte durchaus mehr werden und ich will vermeiden 
das mir das auf die Füße fällt ;)

Es kommt noch ein anderer Aspekt hinzu das die Schlüssel oder Signaturen 
ebenfalls ewt. in base64 vorliegen könnten.

Zumal ist die codierung eindeutig, wenn ich das Objekt auch noch so 
bezeichne  base64_values ...

{"bla":"DEADFACE"} kann ja der Anwender erstmal nichts anfangen, auch 
dessen type ist ja unbekannt. Die Codierung der Daten mit base64 ist 
eindeutig..

Im übrigen denke ich nicht nur an Browser sondern auch an µP Anwendungen 
die den Controller verwenden können...

Die Frage ist schon berechtigt, wenn man auf Leute trifft die damit 
Erfahrungen haben... Da ist es Wurst ob es nur 500byte sind, wenn am 
anderen Ende zum parsen 100MB Speicher verbraucht werden..

: Bearbeitet durch User
von Purzel H. (hacky)


Bewertung
0 lesenswert
nicht lesenswert
Nun, wenn die Datenmenge strikt reduziert werden muss, muss man eh alles 
nochmals neu ueberdenken.
Ich hab aber trotzdem einen Webserver fuer den ATMega32 geschrieben. Der 
musste eine Webseite erzeugen. Erstaunlich wie wenig Platz der 
benoetigte.

: Bearbeitet durch User
von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
Nunja die Payload in der AECPDU kann nicht größer wie 524byte werden 
wegen der Frame größe. Es gibt aber zwei paar Schuhe. A: Antworten von 
den Geräten B: vom Controller und bei B kann ich nicht ausschließen mehr 
anzuhängen..

Ehrlich gesagt versuche ich mit Weitblick solche Aktionen zu vermeiden, 
die erste Etage eines Hundertstöckigen Hochhauses wieder auszubauen.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich glaube, die Lust, mich mit diesem Thema in irgendeiner Weise 
auseinanderzusetzen, habe nicht nur ich schon vor einiger Zeit verloren.

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Ich glaube, die Lust, mich mit diesem Thema in irgendeiner Weise
> auseinanderzusetzen, habe nicht nur ich schon vor einiger Zeit verloren.

Full Ack. Mee2.

Ich kenne dieses "im Kreis labern" und vor allem das Phänomen von einer 
abstrakten konkreten Frage im Eingangspost hin zu immer mehr unnötigen 
Details der eigentlichen Aufgabe. Das ist typisch für Leute die absolut 
keinen Schimmer haben was die da eigentlich tun (sollen).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.