Excel-Suche: Buchstaben abhängig von Systemlocale Language? VBA

[cumulonimbus8]

Moin!

Ein Makro das die einfache Suche (über jeden Blattes ›Cells‹) verwendet funktioniert, so der Kollege, nach Übernahme auf einen anderen Rechner nicht mehr. Mir scheint es, es werden die per Array gelisteten Suchen-Strings (einzelne »ausländische« Buchstaben) gar nicht von der Suche gefunden.
Nun hat der Kollege Systemlocale Language geändert und es geht (für die dann »landestypischen« Buchstaben).

Kann das wirklich sein? Ist Excel (typisch, wieder mal Excel) so doof?
Wie sähe ein Würgaround aus (z.B. Systemlocale Language per Makro zu switchen)?
Wie sähe eine weitere Lösung aus die auf Groß/kleineschreibug reagiert (beim bewussten Ersetzen)? (Ein ›Rückwärtsmakro‹ findet offenbar nur Codes der Kleinbuchstaben die das Vorwärtsmakro aus Großbuchstaben machte.

CN8

 

[Sun_set_1]

https://www.techonthenet.com/excel/formulas/asc.php

Hilft Dir das? Mit ASC verwendest Du im Prinzip den ASCII Zeichensatz. Befehlsketten und Instruktionen damit kenne ich allerdings nicht, weiß nur aus einem Buch das man den auch als Index definieren kann.

Soweit ich das in Erinnerung habe nennt er dir den UNICODE Wert zurück, in dem Link als Beispiel 87 (als INT) für das W.
ASC(87) liefert dann wiederum W zurück. Usw usf.
Würde dann entsprechend versuchen im Code mit String, INT, ASC und Char was zusammen zu basteln.

Gruß

 

[cumulonimbus8]

ASC oder ASCW, CHR, CHRW kommen da (im ursprünglichen Makro) alle nicht vor.
Präziser gesagt - ich nutze just dieselben in meinem Ersatzcode.

Es spinnt ausschließlich die Suche

sht.Cells.Replace What:=fndList(x), Replacement:=rplcList(x), _
 LookAt:=xlPart, SearchOrder:=xlByRows, MatchCase:=True, _
  SearchFormat:=False, ReplaceFormat:=False

sht ist [hier tatsächlich unnötig da alle Blätter abgelaufen werden und Cells allein genügte] das jeweilige Blatt per Schleife, die mit x indizierten Variablen sind Arrays der sich entsprechenden Erssatzbegriffe.

Die «Suche» hier findet den in fndList abgelegten Buchstaben nicht, außer die Systemlocale Language stimmt. Und an der Stelle würde ich gerne ansetzen.

CN8

 

[Sun_set_1]

Okay, nen guten WA habe ich nicht parrat. Aber eventuell eine grobe Erklärung die mir noch ganz dunkel im Hinterstübchen rumläuft, als ich mir vor Jahren mal das MS VBA Buch angetan (überflogen) habe.

Da stand sinngemäß etwas, dass Windows intern mit einem Char-Mapping arbeitet, welches Länder-spezifisch ist. Als Beispiel wurde, wenn ich mich richtig erinnere, die Tastaturen genommen. Ein Anschlag auf die Taste "Y" ist codiert, mit beispielsweise Wert 86 (für das Y). Wenn Du nun eine deutsche Tastatur hast, erzeugt der Anschlag von Y den Wert 54 (Beispiel, nicht gegoogelt), eben da QWERTZ statt QWERTY vorhanden ist.

Die syslocal geht nun hin und mappt die 54 im Hintergrund mit 86, damit es wieder passt.
Vermutlich ist dies immernoch so gelöst. Es wurde darauf hingewiesen, dass dies beim programmieren immer wieder systemweit zu Problemen führen kann. Gerade im osteuropäischen Bereich. Schau dir mal zB eine ungarische Tastatur an.. da passt an Sonderzeichen etc gar nichts mehr.
Jenachdem, wie tiefgreifend dieses Mapping windows-intern arbeitet, kann eben auch der Zellinhalt von Excel entsprechend gemappt werden.

Je mehr ich darüber nachdenke, ergibt dies auch Sinn.
Warum? Tippe eine Wenn-Dann oder sonstwas in Excel und öffne diese auf einem englischen System. Obwohl das englische Excel die Begriffe Wenn/Dann überhaupt nicht kennt, funktionieren die Formeln perfekt. Was bedeutet, dass anscheinend Zellinhalte und Formeln im Hintergrund auch gemappt werden. Weiteres Beispiel / Hinweis dazu wären Datumszellen, die ja in Wirklichkeit immer Dezimalzahlen enthalten.

Aufgrund dessen, wurde immer empfohlen mit Indizes oder Charmaps zu arbeiten. Da hier die INT-Werte einheitlich über zB UNICODE vergeben sind. Da klappts dann auch international.

 

[cumulonimbus8]

Fürchterlich…

Da ich Klartext (..!) so nehmen muss wie er kommt (und dafür gibt es wiederum andere Gründe) musst ich zum Holzhammer greifen:

Sub BuchstabeZuHTML()
Tausch 1
End Sub
Sub HTMLZuBuchstabe()
Tausch 2
End Sub

Sub Tausch(Schalter As Byte)
Dim Blatt As Integer
Dim Bereich As Range
Dim Zelle As Range
Dim Inhalt As String
Dim I As Integer
Dim P0 As Integer
Dim Von As String
Dim Durch As String
Dim Zeichen As Variant
Zeichen = Array(261, 269, 281, 279, 303, 353, 371, 363, 382, 260, 268, 280, 278, 302, 352, 370, 362, 381, 257, 291, 299, 311, 316, 326, 256, 298, 315, 325)
Application.ScreenUpdating = False
For Blatt = 1 To Worksheets.Count
  Set Bereich = Worksheets(Blatt).UsedRange
  For Each Zelle In Bereich
   If Zelle <> "" Then
    Inhalt = Zelle
    For I = LBound(Zeichen) To UBound(Zeichen)
     Select Case Schalter
      Case 1
       Von = ChrW(Zeichen(I))
       Durch = "&#" & CStr(Zeichen(I)) & ";"
      Case 2
       Von = "&#" & CStr(Zeichen(I)) & ";"
       Durch = ChrW(Zeichen(I))
     End Select
     P0 = InStr(Inhalt, Von)
     While P0 > 0 'könnte ja mehrmals vorkommen
      Inhalt = Left(Inhalt, P0 - 1) & Durch & Mid(Inhalt, P0 + Len(Von))
      P0 = InStr(P0 + 1, Inhalt, Von)
     Wend
    Next
    Zelle = Inhalt : REM Bug korrigiert
   End If
 Next
Next
Application.ScreenUpdating = False
Worksheets(1).Activate
Cells(1, 1).Select
End Sub

Das Array ist auf Baltische Buchstaben getrimmt. Immerhin, es tut.

CN8


Ich muss noch mal nahchaken: diese Systemlocale Language erwische ich effektiv überhaupt nicht per VBA, außer ich würde obskure externe Skripte aufrufen, und dann wäre noch nicht sicher, dass meine geöffnete Instanz das mitbekommt?

 

[Sun_set_1]

Ja, das ist einfach maximal bescheuert gelöst.
Wenn ich mich richtig erinnere, stand in dem Buch auch dass das nen Überbleibsel von Windows 95 ist... geil

Doch, es gibt eine Klasse dafür die Du Abfragen kannst. Ist natürlich read only. Aber damit kannst Du zumindest feststellen in welcher Umgebung Du dich befindest.

https://docs.microsoft.com/en-us/office/vba/api/excel.application.languagesettings

Aber wie man mit der Info dann weiter umgeht.. keine Ahnung. Wenn Du verschiedene Indizes per Land aufbaust, nach dem Motto If, syslocal ger then zeichen = Array.... bla bla, kannste auch gleich direkt auf die komplette Unicode Tabelle gehen und die Bedingungen sparen. Was Du ja jetzt auch im Prinzip gemacht hast.

Eine elegantere Lösung als deine Umsetzung fällt mir daher grad auch nicht wirklich ein. Da Windows anscheinend selbst intern mit den entsprechenden INT Werten arbeitet... aber evtl nochmal bei den Profis anfragen?

Hier ist nen Ansatz, die scheinen den Zeichensatz per RegEx festgelegt zu haben:

https://stackoverflow.com/questions/8588728/find-the-current-user-language

 

[Sun_set_1]

Nachtrag, ein Gedanke kam mir gerade noch.

Schau mal in dem stacko-thread. Bei dem Code-Beispiel wird der Array von Buchstaben in der RegEx z.B. a-f abgekürzt. Vllt sparst Du dir so das Ausschreiben der INTs im Array?

Dann könntest Du über die languagesettingsclass die syslocal ermitteln und dann im weiteren Code die zu verwendenden Char-Ranges halt je nach Region bedingt festlegen..?

Ganz grob gedacht

 

[cumulonimbus8]

Danke für die Mühe.
Ich bastele durchaus gerne, aber bei dieser «Methode Microsoft» streiche ich die Segel und belasse es bei meinem Notbehelf.
Warum eine (›die‹) Suche nicht unabhängig eine Glyphe erfassen kann wie ich sie in den Text (eine Zelle) tippe, das ist mir durchaus zu hoch. Alles ANSI, das sollte doch kein Hexenwerk sein?

CN8

 

[Sun_set_1]

Immer gerne.

Das kannste dir halt ähnlich mühsehlig über eine RegEx basteln, ist aber genauso kompliziert wie in JS gelöst. An solchen Momenten versteht man die Schimpferei über solche Sprachen dann doch eher..
(Immer erster Gedanke und Hinweis: Alter, warum gibt’s hier keine Platzhalter-Zeichen?!!”)

Ergänzung (13. Dezember 2018)

Auf der anderen Seite ist VBA eine Script-Sprache und bezieht sich als solche auf das Abfragen von Klassen. Ergo, kann man es MS nicht mal vorwerfen.

 

[cumulonimbus8]

Die Aufgabe kam von einem Kollegen der es mit dem Umstellen der Sprache gelöst hatt[e] - eine Methode die meinen Beifall nicht fand. Und den man nicht so einfach umsetzen kann, wie Sun_set_1 erklärt (ich wüsste nicht mal ob ich die Lösung des Kollegen selber gefunden hätte).
Also suchte ich einen Weg der das umschifft. Leider geriet auf einem nicht sehr eleganten Kurs. Aber ohne Unmengen an Klimmzügen.
CN8