PureBoard

Tschuldigung, falls ich was falsch verstanden habe.
Sonst:
Ergebnis$ = InsertString(String$, StringToInsert$, Position)

PB 4.60

Gruß: BSP

Na Leute, hat keiner eine Idee warum es mit den Strings nicht funktioniert?

Gruß

Daffy

Ok, ich kanns leider nicht testet, aber in deinen "IncRegisterKommandoRingpuffer..." Proceduren setzt du in den Beispielen 1 und 2 den Zeiger wieder zurück auf 1, im Beispiel 3 auf 0. Strings fangen aber auch mit dem Index 0 an (zumindest unsere beiden Varianten). Ich weiß, bei Mid, Left, usw... hat der erste Buchstabe den Index 1, das find ich aber persönlich eigentlich inkosistenz. Aber diese Funktionen benutzen wir ja nicht. Wir arbeiten ja mit Pointern.

lg Kevin

Wie war das mit dem ausführbaren, vereinfachten Code?
Spontan würde ich sagen, dass du Unicode und Ascii mischt (z.T. var.u z.T. var.b und im dritten Beispiel benutzt du .a wo du vorher .b benutzt....)

Daffy0815 hat geschrieben:Na Leute, hat keiner eine Idee warum es mit den Strings nicht funktioniert?

Ich habe mir den von Dir geposteten Code nicht genau angesehen, und habe auch keine Lust das zu tun.

Daffy0815 hat geschrieben:also irgendetwas stimmt mit der Stringverarbeitung in PureBasic nicht!

Um das zu verdeutlichen habe ich mal 3 lauffähige Beispiele gemacht.

Zum Testen muss über die definierte serielle Schnittstelle (COM1) alle 5 Sekunden die Zeichenkette "DI25=123456<CR>" gesendet werden.

Wenn Du zeigen willst dass irgendetwas mit der Stringverarbeitung in PureBasic nicht stimmt, dann poste kurzen Code der "auf den Punkt kommt" und genau dieses Problem zeigt, ohne Gedöns mit der seriellen Schnittstelle o.Ä. So kann ich nur sagen, dass bei gechätzten ca. 95% aller "Bugmeldungen" dieser Art die Bugs im geposteten Code sind, und nicht in PB.

Hallo.
Ich gestehe, ich verstehe Euch nicht.
Im Ursprung ging es doch darum,
Teile eines Satzes zu ändern und dabei die Ursprungslänge
bei zu behalten ? Richtig?

Warum dann aber so kompliziert?
Die Beispiele mit dem Serialport kann ich nicht ausprobieren,
ich habe keinen eingerichtet.

Hier mal mein Vorschlag im reisten PureBasic: Gruß: BSP

BSP hat geschrieben:Warum dann aber so kompliziert?

Das Frag ich mich auch

BSP hat geschrieben:Hallo.
Ich gestehe, ich verstehe Euch nicht.
Im Ursprung ging es doch darum,
Teile eines Satzes zu ändern und dabei die Ursprungslänge
bei zu behalten ? Richtig?

Ja, das war eines von 2 Ursprungsthemen. Inzwischen hat der OP ja sogar schon ein 3. Thema angesprochen ...

BSP hat geschrieben:Hier mal mein Vorschlag im reisten PureBasic:

Code: Alles auswählen

Procedure.s ErsetzeString(String$,pos,laenge,ersatz$)
  ProcedureReturn Left(String$,pos-1)+ersatz$+Mid(String$,pos+laenge)
EndProcedure

Ja, so ungefähr kann man das machen. Wenn das aber in einer Schleife oft aufgerufen wird, dann ist das sehr langsam, weil dauernd Strings zerteilt und wieder neu verknüpft werden. Das ist im Prinzip gar nicht nötig, deshalb haben viele andere BASIC-Dialekte einen speziellen Befehl dafür, und deshalb wurde hier entspr. Code gepostet.

Grüße, Nino

@CSHW89
Das mit den unterschiedlichen Zeigerrücksetzwerten kann ich erklären.
Da die beiden ersten Beispiele einen String als Ringpuffer verwenden und die MID-Funktion zum als Startwert "1" verwendet muss auch der Zeiger auf 1 gesetzt werden (wobei natürlich auch jeder andere Wert >0 und <Ringpufferlänge möglich ist).

Das dritte Beispiel verwendet numerische Feldvariablen und deren Index beginnt ja bei "0" daher auch der Zeigerrücksetzwert = "0".

@Derren
Das liegt an der Art der Verwendung der Variablen. Ich finde die Kennzeichnung der Variablentypen auch ein wenig "unglücklich".
Mir wäre die "historische" Bezeichnung ".w" für vorzeichenlos 16Bit und ".b" für vorzeichenlos 8Bit lieber aber PureBasic will für diese Datentypen halt ".u" und ".a" (Wobei ".a" für ASCII eigentlich unlogisch ist da ASCII nur von 0-127 geht).

@Nino
Ich habe den Code so aus dem Programm extrahiert wie er im eigentlichen Programm verwendet wird und dabei der Fehler auftritt.
Das verrückte daran ist doch gerade die Tatsache, dass das Problem bei den "einfachen" Beispielen die hier von CSHW und hjbremer gezeigt wurden nicht auftreten. Meine erste Vermutung war daher, dass die Zeichen via serielle Schnittstelle "verloren" gehen. Dem ist aber nicht so!
Daher finde ich die Äußerung "gedöns mit der seriellen Schnittstelle" schlicht kontraproduktiv.
Auch das mit den "90%" (woher haben Sie diese Information eigentlich?) bringt niemanden weiter.
Das ich wie jeder Andere auch Fehler mache weiß ich selbst nur deshalb habe ich ja darauf hingewiesen, dass alle drei Beispiele zwar exakt die gleiche Systematik verwenden aber nur Beispiel 3 funktioniert.

@Rest
Es ging ursprünglich darum einen Ersatz für die in PureBasic nicht vorhandene "MID$-Anweisung" zu finden.
Das die hier vielfach vorgestellten "String-kleinhack und String-zusammenbind"-Lösungen alle irgendwie funktionieren ist völlig klar nur haben die alle das gleiche Problem - Sie sind alle sehr langsam und daher in meinem Fall nicht verwendbar.

Gruß

Daffy

@Daffy0815

die MID-Funktion zum als Startwert "1" verwendet muss

Das ist richtig, aber an dieser Stelle: ist das erste Zeichen an der Position 0
dort musst du also entweder RegisterKommandoRingpufferSchreibzeiger-1 machen, oder auch hier den Index mit 0 beginnen lassen und beim Mid dann +1 ...

Zurück zum Ursprungsthema: Was ist eine Mid$-Anweisung ? Kannst du mal den Syntax zeigen?

Ist das Problem nun gelöst ? Ich meine das CharacterArray ist die schnellste Lösung die es gibt, Zeichen in einem Speicher zu ändern.