101 LINQ Beispiele fuer C# Programmierer
Wer Datenbankprogrammierung mit C# betreibt wird früher oder später nicht an LINQ vorbeikommen. Wer sich damit etwas auseinandersetzt wird schnell merken, dass diese Queries schnell recht komplex werden.
Hier bietet Mocrosofts MSDN eine tolle Beispielsammlung an, in der fast alle Anwendungsfälle beschrieben sind. Das ganze findet ihr im MSDN Visual C# Developer Center.
.NET: Projekte fuer Mobile Geraete koennen auf dem Desktop ausgefuehrt werden
Ich denke, dass viele von euch es schon längst gewusst haben, aber heute habe ich zufällig entdeckt, dass man die Projekte, die für Smartphones mit Windows Mobile programmiert wurden direkt auf dem Desktop ausführen kann.
Dabei bedarf es keinerlei Anpassung oder Modifikation des Codes. Einfach doppelklicken und ab geht's!
![]()
Bild 1: Das selbe Programm auf beiden Plattformen (Bild von Tom Wendel)
Das ist (so weit ich weiß) einzigartig in der Programmierwelt oder? Denn Java Programme können nicht direkt auf den Desktop ausgeführt werden, und genauso iPhone Apps!
Ich bin mal gespannt, wie lange es dauert bis das Ganze auch umgekehrt möglich ist!
Wirklich genial!
.NET Administratorrechte fuer eigenes Programm einfordern
Wenn man mit .NET entwickelt wird man schnell feststellen, dass man zur Laufzeit bestimmte Ordner nicht öffnen kann, bestimmte Dateien nicht löschen oderbestimmte Systemfunktionen nicht ausführen kann!
Das liegt daran, dass dem Programm die nötigen Rechte fehlen, denn seit Windows Vista werden alle Programme ohne Administratorrechte ausgeführt. Braucht ein Programm dann aber doch diese Rechte sieht man diesen wenig gemochten Dialog von Windows:
Bild 1: Windows Benutzerkontensteuerung in Aktion
Das Angezeigte unterscheidet sich dann natürlich je nach Programm, aber sobald man hier auf Zulassen geklickt hat wird das Programm mit den Vollen Rechten gestartet.
Aber woran kann ich erkennen, dass ich volle Rechte benötige? - Ganz einfach, wenn man Fehlermeldungen erhält, die besagen, dass man keine Rechte besitzt um auf die Dienste zuzugreifen, oder wenn Systemfunktionen (zB. WMI) nicht mehr korrekt ausgeführt werden.
Wie sorge ich nun dafür, dass mein Programm Adminrechte erhält? - Hier gibt es zwei Möglichkeiten. Die erste ist es das Programm mit rechter Maustaste anzuklicken und dann "Als Administrator ausführen" zu wählen:
Bild 2: So kann man jedem Programm Administratorrechte geben
Natürlich kann man die Adminrechte direkt in unserem Programm beantragen, in dem man in den Projekteinstellungen im Tab "Anwendung" auf den Button "Einstellungen für die Benutzerkonstensteuerung anzeigen" klickt. Dazu wird die Datei "app.manifest" im Projektordner generiert, die dann folgende Einstellungen beinhaltet:
<!-- UAC-Manifestoptionen
Wenn Sie die Ebene der Benutzerkontensteuerung für Windows ändern
möchten, ersetzen Sie den Knoten "requestedExecutionLevel" wie folgt:
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />
Wenn Sie aus Gründen der Abwärtskompatibilität Datei- und Registrierungsvirtualisierung
verwenden möchten, löschen Sie den Knoten "requestedExecutionLevel".
-->
Wie man in dem Grünen Kommentarblock erkennen kann, gibt es drei verschiedene Einstellungsmöglichkeiten, nämlich level="asInvoker" (welcher voreingestellt ist), level="requireAdministrator" und level="highestAvailable".
requestedExecutionLevel level="requireAdministrator" uiAccess="false"
Wenn man nun den unter dem Kommentarblock stehenden Eintrag requestedExecutionLevel auf requireAdministrator ändert, wird unser Programm bei jedem Start automatisch Administratorrechte einfordern, und man wird bei jedem Start diesen unschönen Windows Dialog aus Bild 1 zu sehen bekommen.
Wie ihr euch sicher grade denkt ist das sehr unangenehm für den Benutzer, der später mit der Software arbeiten muss. Dieser muss jedes Mal die Ausführung dieses Programms bestätigen. Außerdem sollte man im Hinterkopf behalten, dass Microsoft diesen Dialog nicht zum Spaß eingeführt hat.
So sollte man immer versuchen seine Software so zu gestalten, dass man auch ohne Administratorreche auskommt. Sollte es aber nicht anders gehen, sollte man den Teil, der diese Rechte benötigt stets aus dem Programm auslagern, sodass dieser Spezielle Fall dann gesondert aufgerufen werden kann und man den Benutzer ggf darauf vorbereiten kann, dass gleich eine Meldung von Windows kommt.
Das Hauptprogramm kann und sollte dann auch weiterhin mit dem geminderten Rechten laufen. So verwirrt man den Benutzer nicht und kann Fehlerquellen später besser eingrenzen.
Programmfortschritt in der Windows Taskleiste anzeigen
Wenn ihr Windows 7 bereits verwendet, werden euch sicherlich einige Neuerungen aufgefallen sein. Einige von denen ist die neue Funktion der Taskleiste den Fortschritt eines Programms darzustellen.
Ihr werdet dies beobachten, wenn ihr z.B. eine Datei mit dem Internet Explorer 8 herunterladet oder eine Datei kopiert. Das Programm zeigt den eigenen Fortschritt dann unter dem Eigenen Symbol in der Taskleiste an.
Diese Funktion ist extrem praktisch, so kann man sie benutzen um den Benutzer immer aktuell zu halten, ohne dass er das eigentliche Programm offen hat. Mögliche Anwendungsfälle wären Dateidownloads, Kopiervorgänge, Bildererzeugung und allgemeine Vorgänge, die etwas Zeit in Anspruch nehmen.
Natürlich können auch wir diese Funktionen in unseren Projekten nutzen. Leider werden die Aufrufe an das Betriebssystem unmanaged gestartet, was bedeutet, dass diese Aufrufe umgewandelt (gewrapped) werden müssen. Da das ein sehr komplexer Vorgang ist hat Microsoft uns diesen gespart und schon einige vorgefertigte Klasse angefertigt auf die wir zurückgreifen können.
Diese Librarys finden wir im MSDN in der .NET Interop Sample Library. Diese Beispielsammlung enthällt viele weitere Beispiele. Wir betrachten hier nur das was mit dem Fortschrittsbalken in der Taskleiste zu tun hat.
Deswegen brauchen wir auch nicht alle Klassen, sondern nur diese:
Vista Bridge Sample Library
Windows7.DesktopIntegration
Windows7.DesktopIntegration. Registration.
Windows7.DesktopIntegration enthält hierbei die Klasse WindowsFormsExtensions, welche uns die nötigen "Extensions"-Funktionen zur Verfügung stellt um das Aussehen der Taskleiste ändern zu können.
In unserem (einfachen) Fall werden wir nur die beiden Methoden benötigen:
SetTaskbarProgress(float percent)
SetTaskbarProgressState(ThumbnailProgressState state)
Mit der Ersten Methode können wir den Fortschritt der Progressbar steuern, und mit der zweiten das Aussehen. Für die zweite Funktion müssen wir neben dem Zustands Parameters auch das Handle des Fensters angeben, für das die Aktion ausgeführt wird.
So könnten die Aufrufe folgendermaßen aussehen:
WindowsFormsExtensions.SetTaskbarProgress(Me.ProgressBar1)
WindowsFormsExtensions.SetTaskbarProgressState(Me, _
Windows7Taskbar.ThumbnailProgressState.Error)
Garnicht mal so kompliziert oder?
Dabei kann das Taskleistensymbol unseres Programms 5 verschiedene Werte annehmen:
Wenn wir nun also ein neues Windows Forms Projekt erstellen müssen wir ersteinmal die drei oben erwähnten Class Librarys importieren. Das machen wir in dem wir über Datei->Hinzufügen->Vorhandenes Projekt wählen
Auf diese Weise fügen wir alle drei oben erwähnten Projekte dem unseren hinzu. Wenn das geschafft ist müssen wir noch die nötigen Verweise hinzufügen. Dazu wählen wir Projekt->Verweis hinzufügen... und dann den Tab "Projekte"
Hier wählen wir alle drei Projekte aus und klicken auf "OK"!
Wie ihr nun im Projektmappen Explorer erkennen werdet ist das Projekt gleich mal um einiges gewachsen! Ihr könnt dieses Vorgehen auch umgehen, indem ihr die importierten Class Librarys als DLL kompiliert und direkt in das Projekt einbindet. Das schafft vielleicht mehr Übersicht.
Nun haben wir schon das größte Hindernis schon überwunden! Nun gehts ans Programmieren, wofür ihr die oben vorgestellten Funktionen benutzen könnt um eurem Programm den nötigen Windows 7 Look zu verpassen!
Ich habe dazu wie immer eine kleine Demo angefertigt. Meine sieht so aus:
Bild 4: Das Demoprojekt in Aktion
Das Demoprojekt könnt ihr hier laden: Download [VS 2008]
Kostenloses E-Book von Microsoft zum Thema VB.NET
Es ist wieder soweit. Microsoft bietet wiedermal ein Buch komplett gratis zum Download an. Dieses Mal ist Visual Basic.NET das Thema.
Das Buch ist von dem Hauseigenen Verlag MicrosoftPress, welches einen sehr guten Ruf genießt. Ich selber habe mehrere Bücher von denen.
Dieses Buch kostet normalerweise 59 € und ist somit ein sehr gutes "Schnäppchen". Dabei kann es sich vom Inhalt sehen lassen. Dieses Buch vermittelt alles von den Grundlagen, bishin zur fortgeschrittenen Programmierung mit Datenbanken.
Auch wenn ihr kein VB.NET Programmierer Seit kann ich es euch trotzdem empfehlen dieses Buch zu laden, den man weiß ja nie!
Download: Hier
Mod_Rewrite unter Microsoft IIS nutzbar machen
Ein Umstieg von Unix & Apache auf Windows & IIS kann ganz schön stressig sein. Da ich letzte Woche selber mit dem Blog von UNIX auf eine Windows Plattform umgestiegen bin musste ich das an meinem eigenen Leib erfahren.
Das was einem am IIS wohl am meisten fehlt ist wohl die mod_rewrite funktion, die man über die .htaccess Datei konfiguriert. Diese wird dann dementsprechend unbrauchbar.
Microsoft bietet zwar auch sowas ähnliches an, aber mich überkommt immer ein ungutes Gefühl sobald ich mit mod_rewrite auseinandersetzen muss, und da hat man natürlich noch weniger Lust das ganze umzuschreiben.
Die beste Lösung wäre da natürlich, wenn man die alten Definitionen benutzen könnte. Und das geht auch tatsächlich!
Nach etwas googeln habe ich eine schöne, kostenlose Software gefunden, die und die dafür benötigte ISAPI Erweiterung für den IIS liefert! Diese findet ihr hier:
Wenn ihr die Installation durchlaufen habt, könnt ihr schnell mal checken ob der Dienst läuft in dem Ihr auf die Eigenschaften von "Websites" im IIS klickt und dann ISAPI Filters wählt. Gegebenenfalls den IIS neustarten.
Nun könnt ihr eure Definitionen über die mitgelieferte (und wie ich finde etwas eingestaubte) Software erledigen:
Bild 2: Das Tool von Helicon zum verwalten der Rewrite-Regeln
Hier (Bild 2) sehr ihr eine Globale Einstellung, die sich auf alle Sites auswirkt. Es können aber auch einzelne Regeln erstellt werden, so wie man es auch gewohnt ist! Alternativ kann man auch in dem Webseiteneigenschaften (siehe Bild 1) Direkt den Tab "ISAPI_Rewrite" wählen.
Die Software ist kostenlos und erfüllt hervorragend ihren Zweck! Ich kanns nur weiterempfehlen!
Windows Aero Glass in eigenen Projekten nutzen Teil 2
In dem ersten Teil dieses Beitrags, der nun schon einige Monate her ist habe ich gezeigt, wie man die Aero Glas Effekte auch in eigene Projekte einbauen kann. Doch leider waren da noch einige Probleme, so konnten wir nur das ganze Formular in Glas verwandeln und die Darstellung der Steuerelemente war falsch.
Genau hier möchte ich den zweiten Teil ansetzen und diese letzten Probleme aus der Welt schaffen!
Wir beginnen genauso wie im ersten Teil nur nennen wir unsere Klasse diesmal GlassForm um nicht durcheinander zu kommen.
Diesmal importieren wir eine weitere Methode aus der Windows API, nämlich DwmIsCompositionEnabled() die es uns ermöglicht zu prüfen, ob diese Effekte, die wir nutzen möchten auch verfügbar sind.
Die zweite Funktion DwmExtendFrameIntoClientArea müsste aus Teil 1 schon bekannt sein, diese hilft uns die Formränder zu vergrößern und somit die Glasoberfläche ins Formularinnere zu holen.
Da wir dieses Mal die eine Option für alle Ränder haben möchten, sodass wir zB. nur den oberen Rand in Glas verwandeln, benötigen wir ein Structure, in dem wir die Werte für jeden Rand speichern können und den wir dann später der Funktion DwmExtendFrameIntoClientArea übergeben.
So sieht unsere Klasse aus:
Imports System.Runtime.InteropServices
Public Class GlassForm
_
Private Shared Sub DwmExtendFrameIntoClientArea _
(ByVal hwnd As IntPtr, ByRef margin As AeroDemo2.MARGINS)
End Sub
_
Public Shared Function DwmIsCompositionEnabled() As Boolean
End Function
Public Shared Function ExtendGlassFrame _
(ByVal hwnd As IntPtr, ByVal margin As AeroDemo2.MARGINS) As Boolean
GlassForm.DwmExtendFrameIntoClientArea(hwnd, margin)
Return True
End Function
End Class
Public Structure MARGINS
Public left As Integer
Public right As Integer
Public top As Integer
Public bottom As Integer
Public Sub New(ByVal l As Integer, ByVal r As Integer, _
ByVal t As Integer, ByVal b As Integer)
left = l
right = r
top = t
bottom = b
End Sub
End Structure
Wie man sieht enthält die Structure MARGINS je eine Variable für jede Seite des Formulars, wobei der Wert den sie beinhaltet den Abstand zum eigentlichen Rahmen angibt!
Wechseln wir nun zur Klasse Form1, da wir hier fertig sind. In der Form_Load Methode können wir uns nun einen neuen Structure erstellen und diesem unsere gewünschten Rahmenabstände übergeben. Daraufhin rufen wir unsere Funktion auf die für sns das Glas herzaubern soll.
Doch wenn wir das Programm nun starten werden wir kein Glas vorfinden! Das liegt daran, dass Windows die Farbe Schwarz für Transparente Darstellung auf Glas verwendet. Das bedeutet, dass alle Steuerelemente, die Schwarze Farbe enthalten transparent und somit zu Glas werden! Das konntet ihr aber auch im ersten Teil schon beobachten!
Dieses Problem nehmen wir aber später nocheinmal in Angriff! Kommen wir ersteinmal zu unserem Glasfenster!
Damit wir auch wirklich Glas sehen, müssen wir ersteinmal das Fenster mit schwarzer Farbe füllen. Dazu schreiben wir folgendes in die Form_Paint Methode:
Dim margins As AeroDemo2.MARGINS
Private Sub Form1_Load() Handles MyBase.Load
'Den "normalen" Bereich festlegen
margins = New AeroDemo2.MARGINS(0, 0, 35, 50)
'Die Fensterränder erweitern
GlassForm.ExtendGlassFrame(Me.Handle, margins)
End Sub
Wenn man das Programm startet, müsste das ca so aussehen:
Bild 1: Alles ist schwarz, bis auf den Glasteil
Bitte nicht erschrecken, denn eigentlich ist es keine Überraschung, dass wir nur schwarz sehen, denn wir haben im letzten Schritt alles Schwarz gefärbt. Der Aero Teil ist dadurch nun transparent geworden!
Da das Schwarze aber ziemlich blöd aussieht möchten wir das natürlich wieder auf unsere Standardeinstellung ändern. Dazu müssen wir diesen schwarzen Rechteck da oben nun wieder mit der Ausgangsfarbe füllen! Das machen wir so:
Private Sub Form1_Paint(ByVal sender As Object, _
ByVal e As System.Windows.Forms.PaintEventArgs) Handles Me.Paint
If GlassForm.DwmIsCompositionEnabled() = True Then
'Hintergrund Schwarz füllen, um den Glass effenkt zu erhalten
e.Graphics.Clear(Color.Black)
'Nun das Stück, dass nicht aus Glas sein soll wieder "zurückmalen"
Dim clientArea As New Rectangle(margins.left, margins.top, _
Me.ClientRectangle.Width - margins.left - margins.right, _
Me.ClientRectangle.Height - margins.top - margins.bottom)
Dim b As Brush = New SolidBrush(Me.BackColor)
e.Graphics.FillRectangle(b, clientArea)
End If
End Sub
Nachdem wir das Rechteck wieder mit der Ausgangsfarbe bemalt haben sieht das schon viel angenehmer aus:
Bild 2: Das Fenster hat nun wieder die "Normale" Farbe
Was natürlich nun auffällt ist das Komplett schwarze Label (ja, es ist wirklich eins) und der nicht lesbare Button.
Dies sind die oben besagten Probleme von GDI Objekten. Diese werden Standardmäßig genutzt um Abwärtskompabilität zu gewährleisten. Schaltet man aber das TextRendering auf GDI+ so werden auch die Schriften korrekt dargestellt.
Um das zu ändern muss die Option SetCompatibleTextRenderingDefault auf true gesetzt werden. Dies muss aber geschehen bevor das Programm gestartet wird. Also klicken wir mit der Rechten Maustaste auf unser Projekt -> Hinzufügen -> Modul
In das Modul schreibt ihr nun folgendes rein:
Sub Main()
Application.EnableVisualStyles()
Application.SetCompatibleTextRenderingDefault(True)
Application.Run(New Form1) 'Name eurer Form
End Sub
Nun müssen wir nurnoch dafür sorgen, dass unser Projekt durch das Modul gestartet wird. Das machen wir in dem wir auf "Projekt" oben im Menü klicken und dann auf Eigenschaften. Hier muss nun der Haken bei "Anwendungsframework aktivieren" herausnehmen und dann bei "Startobjekt" "Sub Main" wählen:
Bild 3: Das Projekt über das Modul starten
Wenn wir das Programm nun starten sollte man die Texte und auch den Button lesen können!
Nun sind wir eigentlich schon durch. Was noch zu sagen bleibt ist, dass man es möglichst vermeiden sollte Steuerelemente auf dem Glas zu platzieren, da diese sehr oft falsch dargestellt werden.
Wenn ihr unbedingt Schrift auf Glas haben wollt solltet ihr diese Schrift auf das Formular Zeichnen und nicht einfach über ein Label dort platzieren. Das selbe gilt auch für Grafiken. Leider kann man nicht einfach mit der Graphics.DrawString() Methode Zeichnen sondern muss den Text erst in ein GraphicsPath Objekt "zeichnen" bevor man es dem Glas übergibt. So stellt man sicher, dass die Textverläufe richtig dargestellt werden!
Hier ein Beispiel:
'Text zeichnen
Dim txt = Me.CreateGraphics()
Dim path = New GraphicsPath()
path.AddString("Ich bin ein gezeichneter Text", _
New FontFamily("Tahoma"), CInt(FontStyle.Regular), _
20, New Point(60, 0), StringFormat.GenericDefault)
Dim brush = New PathGradientBrush(path)
Dim clr As Color() = {Color.Transparent}
txt.SmoothingMode = SmoothingMode.HighQuality
brush.CenterColor = Color.White
brush.SurroundColors = clr
txt.FillPath(Brushes.Black, path)
brush.Dispose()
path.Dispose()
txt.Dispose()
Und wie es aussehen könnte:
Bild 4: So könnte ein Aero Formular aussehen
Weitere Informationen auch mit Beispielen findet ihr hier: (englisch & C#)
Microsoft
CodeProject
CodeProject
Wie üblich habe ich das Ganze in ein kleines Demoprojekt verpackt: Download
Wie hats euch gefallen, möchtet ihr einen dritten Teil? Freue mich auf euer Feedback!
Teil 1 des Tutorials gibts hier
Zum dritten Teil gehts hier lang
Windows Lizenzschlüssel aus der Registry auslesen
Da der Beitrag über das Auslesen des Office Schlüssels sehr beliebt ist, habe ich nun auch das Lesen des Windows Schlüssels als Beispiel verfasst.
Das Vorgehen hierbei ist sogar noch einfacher als beim Office Schlüssel, da es keine Aufteilungen in Versionen gibt! In allen Windows NT Versionen (also alle ab XP) befindet sich der Schlüssel in der Registry unter diesem Pfad:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
Bild 1: Der Registryordner mit dem Windows Schlüssel
In diesem Ordner finden wir den Binärwert "DigitalProductId", der viele Hexadezimalzeichen enthält!
Der Code ist hierbei dem aus dem Officebeispiel sehr ähnlich, da er ja auch nichts anderes macht, als den im HEX-Code vorhandenen Key in lesbare Schrift umzuwandeln! Die einzige Schwierigkeit hierbei besteht darin, den Key richtig zusammen zusetzen, denn es wird nicht das komplette Alphabet verwendet um einen Windows Key zu generieren sondern nur diese Zeichen:
B C D F G H J K M P Q R T V W X Y 2 3 4 6 7 8 9
Wenn man das beachtet steht einem nichts mehr im Wege! Der Code aus diesem Beispiel stammt ausnahmsweise nicht von mir sondern von vcware.de - danke dafür an dieser Stelle!
Ich habe diesbezüglich wie immer ein kleines Demoprojekt angefertigt, das ihr euch herunterladenkönnt! Download
Bitte berichtet ob es bei euch gut geklappt hat.
Hier könnt ihr euch das komplette kostenlose Programm zum auslesen von Windows & Office key herunterladen. (English & Deutsch)
Windows 7 und seine Schönheitsfehler Teil 2: Die Taskleiste
Letzte Woche habe ich unter Windows 7 etwas sehr seltsames beobachtet. Nach dem ich ein kleines Programm geschrieben hatte, dass ich zwischendurch nutzen wollte, wollte ich dieses an die Taskleiste "pinnen", damit ich es immer schnell griffbereit habe!
Bild 1: Links: Wie es sein sollte. Rechts: So sieht das "Problem" aus
Doch Pustekuchen! Ich konnte das Programm, ja nicht mal eine Verknüpfung, die auf das Programm linkte an die Taskleiste pinnen! Seltsam, denn andere Programme, auch selbstgeschriebene, konnte ich problemlos anpinnen!
Woran kann das liegen? Alle Optionen, die man von anderen Programmen kennt waren nicht da! Die ganze Jumplist hatte nur den Eintrag "Fenster schließen". Die anderen Optionen wie "Programm an die Taskleiste pinnen" waren alle weg!
Die erste Vermutung war natürlich, es liegt am Code! - Son Mist - Also habe ich losgelegt und das Programm Stück für Stück von verschiedenen Codeteilen befreit bis ich garkeinen Code mehr im Programm hatte. Aber das "Problem" war immernoch nicht behoben!
Wie gesagt konnte ich andere Programme, die ich selbst gemacht habe anpinnen, nur dieses eine nicht. Also habe ich das getan, was jeder kompetente Programmierer tun würde, ich befragte Google!
Leider konnte ich nichts wirklich brauchbares finden, das meinen Fall bestätigte. Schließlich wollte ich schon aufgeben und das Projekt neu anlegen, in der Hoffnung es würde nicht wieder auftauchen.
Zu meinem Glück habe ich davor ein Skript (an dem ich zur Zeit etwas herum spiel) verwendet, dass dieses Programm (zusammen mit vielen anderen Dateien) umbenannt hatte. Nun hieß das Programm "ax4b.exe". und Überraschung - ich konnte es anpinnen.
Es lag am Namen!
Als ich dem Programm wieder seinen Originalnamen verlieh konnte ich es wieder nicht anpinnen! Achja, das Programm heißt "Uploadhelper.exe"
Wie es also scheint, sind bestimmte Programme unter Windows 7 von der Fähigkeit befreit sich an die Taskleiste pinnen zu können.
Wie ich dann nach einer weiteren Internetrecherche herausgefunden habe gibt es einen Registryeintrag namens "AddRemovenames" derhier zu finden ist:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileAssociation\AddRemoveNames
Bild 2: Der Registryeintrag mit den "verbotenen" Namen
Dieser enthält alle Schlüsselwörter, die alle Programme, die eins dieser Wörter im Namen beinhalten, nicht an die Taskleiste pinnen lässt! Diese Wörter sind:
Documentation;Help;Install;More Info;Readme;Read me;Read First;Setup;Support;What's New;Remove
Und da mein Programm das Wort "help" im Namen hatte wurde es von dieser Regel betroffen.
Es scheint so zu sein, dass Microsoft keine Hilfe oder Setup Programme in der Taskleiste sehen will. Wobei ich wirklich nicht verstehen kann, warum "Documentation" in der Liste steht!
Also hat man als Entwickler nun die Wahl: Entweder man benennt sein Programm um, oder man löscht den entsprechenden Eintrag aus diesem Registryeintrag. Von dem letzteren würde ich allerdings abraten, da es ein enormer Eingriff in die Benutzereinstellungen wäre, und wer weiß, vielleicht benutzen noch andere Dienste diesen Eintrag und funktionieren dann eventuell nicht mehr!
Wenn man von dieser Beschränkung nichts weiß, kann es einen schon in den Wahnsinn treiben, denn wer vermutet denn bitte, dass es an dem Namen liegt?
Windows 7 und seine Schönheitsfehler Teil 1: Ordnerpfade
Seit einiger Zeit ist nun Microsofts neues Betriebssystem Windows 7 auf dem Markt und schlägt sich bisher sehr gut! Ich nutze es selber jeden Tag und bin begeistert von der Geschwindigkeit und den neuen Features die es bietet. Doch leider gibt es auch hier ein paar (wenn auch wenige) Schattenseiten, über die ich in dieser Reihe berichten möchte!
In diesem Ersten Teil geht es um ein kleines "Feature", dass einem nicht gleich ins Auge springt und teilweise auch schon in Windows Vista vorzufinden war. Der "normale" Nutzer würde es wahrscheinlich garnicht bemerken, doch wir als Programmierer müssen desöfteren mit konkreten Pfaden arbeiten, und das ist genau die Sache!
Blicken wir kurz zurück auf Windows XP und seine NT-Vorgänger. Jede Windows XP Version, egal in welcher Sprache sie vorliegt hat den selben Aufbau, zB. wird man immer den Ordner C:\Programme vorfinden, in dem die ganzen installierten Programme liegen.
Wenn wir nun also diesen Pfad fest in unser Programm einbauen, da wir ja davon ausgehen, dass dieser Pfad konstant ist müsste es ja "immer" laufen! Doch das ist leider nicht so, denn wenn man unser Programm auf einem Rechner mit einer Englischen Kopie von Windows (XP) startet, wird das Programm abstürzen, da es den Ordner C:\Programme nicht finden wird!
Warum? Ganz einfach, denn im Englischen gibts das Wort "Programme" nicht! Dort heißt der Ordner "Program Files" und müsste dementsprehend über "C:\Program Files" angesprochen werden! - Ja, ich weiß, ein normaler Mensch würde hier die Umgebungsvariable "ProgramFiles" nutzen, die immer auf den richtigen Ordnerpfad zeigt, aber das würde das Problem nicht verdeutlichen! (dazu kommen wir noch)
Also zurück zu Windows 7. Microsoft dachte sich auch, dass das wohl blöd ist und entschied sich dazu alles einheitlich zu machen! - Gute Idee, doch etwas komisch umgesetzt!
Schauen wir uns doch mal einen Typischen Windows 7 Ordnerpfad an:
Bild 1: Der Ordner "Eigene Bilder" ausgewählt im WIndows Explorer
Wenn ich Sie nun nach dem Pfad zu dem ausgewählten Ordner frage, würden Sie wohl wie folgt antworten:
C:\Benutzer\Basti\Eigene Bilder
Ich kann Sie beruhigen, diese Angabe ist völlig korrekt, so scheint es. Denn an dieser Stelle täuscht uns Windows 7 bzw. der Windows Explorer.
Denn würden Sie den o.g. Pfad aufrufen wollen, würde Windows eine Fehlermeldung ausgeben, die besagen würde, dass der Ordner nicht existiert! - Wie kann das sein?
Das liegt daran, dass Windows uns die deutsche Sprache nur vortäuscht! Denn der echte Pfad sieht so aus:
Bild 2: Der wahre Pfad steht oben
Nach einem Klick in die Adresszeile wird man feststellen, dass der Ordnerpfad komplett nur aus Englischen Wörtern besteht!
Das macht es manchmal umständlich eine Datei zu finden, auch wenn es für den eigentlichen Nutzer angenehmer erscheint!
Wie kann man sich schützen?
ALs Programmierer sollte man seinen Code immer so schreiben, dass es auf allen Windows Versionen lauffähig ist, doch wie macht man das wenn die Ordner immer anders heißen?
Die Antwort ist relativ leicht und lautet "Umgebungsvariable"! Denn Windows übersetzt nicht alle Ordner, sondern nur die so genannten "Special Folders". Das sind Ordner, die für das System von Bedeutung sind!
Dazu gehören der Windows Ordner Selbst, der Systemordner, der Programmordner oder der "Eigene Dateien" Ordner. Aber woher weis ich, ob ein Ordner ein "Special Folder" ist oder nicht?
Das kann man ganz einfach herausfinden, indem man in die Liste der Umgebungsvariablen (Environmentvariables in English) schaut. Diese findet ihr zb so: [Start]+[R] Tippt nun "cmd" ein und drückt auf [ENTER] um in die Eingabeaufforderung von Windows zu gelangen. Nun tippt "set" ein und drückt erneut auf [ENTER].
Bild 3: Die Liste mit den Umgebungsvariablen unter Windows
Hier sehr ihr eine komplette Liste mit allen dem Benutzer zugänglichen Umgebungsvariablen. Alternativ könnt ihr auch so vorgehen: [Start] und nun tippt ihr in das Suchfeld von Windows Vista oder 7 "erweitert" ein und lasst Windows ein paar Sekunden suchen, dann klickt ihr auf den Eintrag "Erweiterte Systemeinstellungen Anzeigen", wählt nun oben den Tab "Erweitert" auf und klickt unten auf "Umgebungsvariablen" ihr bekommt folgendes zu sehen:
Bild 4: Die Grafische Oberfläche der Umgebungsvariablen
Unter Windows XP Erreicht ihr dieses Fenster mit einem Rechtsklick auf Arbeitsplatz und dann Erweitert!
Auf diese Variablen kann man auch sehr bequem vom Code aus zugreifen, und da diese auf jedem System stimmen hat man keine Probleme zu erwarten!
'
'
'Pfad zum Programmordner
Dim ProgrammPfad As String
ProgrammPfad = Environment.GetEnvironmentVariable("ProgramFiles")
Wie man sieht kann man so sehr einfach den Programmordner auslesen.
Windows 7 bietet noch weitere kleine Überraschungen über die ich im Nächsten Teil schreiben werde!
Hat euch diese Beitrag gefallen? Schreibt mir einen Kommentar!






