StrTran() casesensitive [ERLEDIGT]

[Manfred]

Ich mußte gerade feststellen, das StrTran() casesensitive arbeitet, wenn es um den zu tauschenden Suchbegriff geht. Was soll denn der Unsinn? Nichts in xbase++ wird wirklich casesensitive behandelt, aber sowas? Das verstehe ich nicht.

[Tom]

So ein Quatsch, dass nichts case-sensitive ist. Wenn Du Strings vergleichst, ist das grundsätzlich so, ansonsten wäre das auch absurd. Und da man StrTran() für komplexe Stringoperationen verwendet und nicht für Indexsuchen, die bei vielen DBEs auch case-sensitiv sind, wäre es totaler Quatsch, hier unsensitiv zu arbeiten. Aber Du kannst einfach ein "Upper()" auf Deinen Suchbegriff und den zu durchsuchenden String setzen, dann bekommst Du, was Du willst. Aber Du ersetzt dann auch "Müller" durch ""MeiER", wenn Du StrTran(Upper("Müller"),Upper("üll"),"ei"), aber ohne das Upper() auf dem zu durchsuchenden Begriff würdest Du das geupperte "ÜLL" nicht finden.

[Manfred]

mein Quatsch bezog sich darauf, das es halt diese Unterschiede gibt. Mal casesensitive und mal nicht. Ich perönlich habe mich so fest darauf eingestellt, das es nicht der Fall ist, das es sehr viel Obacht verlangt, vorher zu prüfen, wo es der Fall ist. Wenn ich mit javascript arbeite, dann achte ich peinlich darauf, weil ich es weiß und auch damit rechne, aber in dem Fall...
Aber stimmt, ich hätte daran denken müssen (fällt mir gerade beim Schreiben hier ein). Ich benutze StrTran() intensiv bei meinen Webanwendungen, wenn ich Platzhalter in SQL Strings, oder HTML Templates tausche. Da hatte ich mich schonmal gewundert und sofort auf Lower und Upper eingestellt. Es ist aber trotzdem sehr gewöhnungsbedürftig.

[Tom]

Ich benutze StrTran() intensiv bei meinen Webanwendungen, wenn ich Platzhalter in SQL Strings, oder HTML Templates tausche.

Das mache ich auch, ja.

Da hatte ich mich schonmal gewundert und sofort auf Lower und Upper eingestellt.

Und ich achte gerade dabei akribisch darauf, meine Platzhalter eindeutig zu wählen und auch exakt so anzusprechen, damit nicht Texte ersetzt werden, die ich nicht ersetzen will. Und, wie im Beispiel eben gezeigt - ich würde auch die Finger davon lassen, ein Upper() oder Lower() auf das ganze Dokument zu legen, sonst zerlegt man den ja case-sensitiven Code darin, etwa das Javascript, aber auch CSS-Elemente - und die Texte, die ein solches Dokument zeigt. Ich arbeite in diesem Zusammenhang also sowieso case-sensitive und lasse die Finger von Umwandlungsfunktionen.

[Marcus Herz]

So spontan fällt mir eigentlich KEINE Xbase String Funktion ein, die NICHT casesensitiv arbeitet.
Kannst du mir auf die Sprünge helfen?

[Manfred]

ich meine das ganze System als solches. Alle Vars können geschrieben werden wie man will. Alle UDF genauso. Z.B.

[Tom]

ich meine das ganze System als solches. Alle Vars können geschrieben werden wie man will. Alle UDF genauso. Z.B.

Das ist so und macht es ein bisschen einfacher, aber Texte sind nun einmal Texte, und eine Eigenschaft von Texten ist grundsätzlich und fast immer die Unterscheidung zwischen Groß- und Kleinschreibung. Du redest hier nicht über Xbase-Syntax, sondern über Inhalte.

[Manfred]

ja, stimmt ja auch wieder. Aufgefallen ist es mir eigentlich nur deshalb, weil ich eine Datei umkopieren wollte. Ich hatte die komplette Bezeichnung nebst Dateipfad und Name und wollte nur einen ZWischenteil im gesamten namen austauschen. Da aber die einzelnen Verzeichnis/Dateinamen groß oder klein geschrieben werden können, hatte ich den Suchstring klein geschrieben (gedankenlos) und mich gewundert, warum der nicht getauscht wurde. klar, in dem Fall war er groß geschrieben. Das kann aber jetzt von Fall zu Fall anders sein. Da die Dateexplorer das wohl intern verarbeiten, hatte ich da nie drüber nachgedacht und bin halt genau vor die Wand gelaufen in dem Fall. Jetzt, wo das Thema hier breiter getreten wird, merke ich auch das ich da anfänglich wohl zu unbedacht dran war.