Moin,
ein .DriveType eines mit DriveInfo geholten Laufwerks, liefert auf meinem deutschen Windows 8.1 nur englische Namen.
Kann man das irgendwie lokalisieren?
Also, dass Jeder diese Info in seiner Systemsprache erhält?

Hier meine Beispiel-Methode zum Füllen eines TreeView mit allen Laufwerken:

Hier ein ScreenShot, um das zu verdeutlichen:


LG,
Bruno

DriveType ist eine Enumeration aus dem FrameWork, d.h. die Werte sind fix. Du musst den Typ des jeweiligen Laufwerkes abfragen und selbst übersetzen.

Nö, kann man nicht, das musst du dann selbst machen. Bei nem Enum-Typ liefert ToString einfach den Namen der Konstante, so wie er im Code steht, und der ist nunmal überall englisch.

xtts02 schrieb:

Du musst den Typ des jeweiligen Laufwerkes abfragen und selbst übersetzen.

Arrrgs - das wollte ich nicht hören - aber danke.
Gibts da nicht etwas aus der p/invoke Ecke oder von Ratiopharm ?

LG,
Bruno

DriveInfo.DriveType basiert wohl auf GetDriveType, welches einen einfachen Integer zurückgibt, also eher nein.

Wie bereits erwähnt, kannst du bei einem Enum-Member nicht einfach ToString() aufrufen und dann erwarten, dass was lokalisiertes rauskommt (wenn das so wäre, wäre das grausam).

Du kannst es entweder selbst übersetzen, oder Windows/explorer.exe reversen, nachschauen, welche MUI-Datei mit welchen Parametern benutzt wird, und dieses Verhalten dann nachbilden. Ich würde mir den Aufwand von letzterem aber sparen und ersteres nicht machen, weil es sich nicht automatisch auf andere Sprachen anpasst.

Muss es wirklich ein eigener Explorer sein? Im WindowsAPICodePack findest du ein Control, das einfach nur ein Explorer-Frame (wie aus dem Windows Explorer) ist, das man auf eine Form packen kann. Alles inklusive die Lokalisierung der Datenträger ist damit schon fertig.
Nicht-Endanwender-User regen sich auch gerne über miserabel selbstimplementierte Explorer auf (z. B. der von Java, der ist ganz schlimm). Ich würde bei sowas immer auf das zurückgreifen, was Windows schon hat - vorausgesetzt es entspricht den Anforderungen. Das gilt aber nicht nur für Explorer-Fenster, sondern auch für alle anderen Controls, da man es nie wirklich schafft, exakt das Verhalten von Windows-nativen Controls nachzubilden. Ein gutes Beispiel ist hier immer eine Textbox, die - wenn sie jemand komplett selber macht, z. B. in einem Spiel - sich nie so verhält wie eine normale Textbox (Beispiele: Pos1/Ende-Tasten gehen nicht/nur halb, Shift+Arrow-Tasten springen nicht über Wörter... oder anders als bei Windows, Textselektion verhält sich anders beim Klicken, nur manche Tastenkombinationen gehen, weil der Entwickler selbst nicht alle kannte und sie deshalb nicht implementiert hat, Lokalisierungsprobleme, Drag&Drop funktioniert nicht, unter bestimmten Windows Themes sieht es anders/doof aus). Sowas kann einen unglaublich nerven - wieder hier als Beispiel der Java-OpenFileDialog.

nikeee13 schrieb:

Du kannst es entweder selbst übersetzen...

Jo - habe ich jetzt gemacht.

nikeee13 schrieb:

Muss es wirklich ein eigener Explorer sein?

Das Teil ist ein eigener OpenFileDialog, geboren aus diesem Thread und nur zu Lernzwecken, da ich bislang wenig mit dem TreeView gemacht habe/machen musste (ist ja ganz putzig das Teil ).

LG,
Bruno