Karsten Samaschke: Los jetzt!

Wer kennt das nicht: Manchmal muss es einfach mehr sein. So zum Beispiel im Mac OS, wenn man mehr als eine laufende Instanz einer Applikation (etwa einer Entwicklungsumgebung) benötigt. Nur: So von Haus aus scheint es nicht zu funktionieren, denn die meisten Applikationen sind als Einzelinstanzen designed.

Wer es doch benötigt, kann sich mit dem Terminal behelfen:

open -n /Applications/[Applikationsname].app

Das Geheimnis ist der Schalter -n, der für “new”, also neue Instanz, steht.

open -n /Applications/eclipse/Eclipse.app

Auf diese Art wird beispielsweise eine Eclipse-Instanz geöffnet. Bei den meisten Applikationen funktioniert das dann auch völlig problemlos, nur eben leider nicht von Haus aus.

Eigentlich ist es ganz einfach, wenn man es denn weiß – es geht nämlich doch, die Windows Live Suite (namentlich den Live Writer) auf offiziell nicht supporteten Microsoft-Systemen zu installieren.

Lädt man den Installer herunter (wlsetup-all.exe oder wlsetup-web.exe) und versucht dann die Installation, kommt eine kleine fiese Fehlermeldung, die besagt, dass die Installation auf einem nicht unterstützten Betriebssystem vorgenommen werden soll. Das ist jedoch reine Politik, technisch spricht überhaupt nix gegen W2K3 oder W2K8 als Systeme für den Live Writer.

Um das Setup davon zu überzeugen, sich auf einem nicht unterstützten System installieren zu lassen, ist nicht mehr als ein kleiner Ressourcen-Editor, etwa Resource Hacker, notwendig. In diesem öffnet man dann den Installer und führt folgende Schritte aus:

1. Den Bereich CONFIG > CONFIG0 > 0 suchen
2. Den XML-Bereich mit dem Namen IsValidOs löschen:

   …

3. Kompilieren des Skripts
4. Speichern der geänderten Ressourcen

Einer nun folgenden Installation auf einem W2K3- oder W2K8-System steht nichts im Wege.

PS: Dieses Posting ist per Windows Live Writer auf Windows Server 2003 verfasst worden.

Via.

Windows Server 2003 unterstützt von Haus aus noch das alte und schwache SSL v2. Dies kann eine potentielle Sicherheitslücke darstellen, so das man es besser deaktiviert.

Das funktioniert jedoch nur per regedit-Tool – eine komfortable Oberfläche dafür jibbet nicht. Ist jedoch nicht schwer, folgende Schritte sind ausreichend:

• Start > Ausführen > regedit
• HKLM > CurrentControlSet > Control > System > SecurityProviders > SCHANNEL > SSL2
• Wenn vorhanden, dann den DWORD-Eintrag Enabled auf 0 setzen
• Wenn nicht vorhanden, dann anlegen.

Ab diesem Zeitpunkt können Clients mit SSL v2 nicht mehr auf den sicheren Kanal zugreifen. Aktuelle Clients können natürlich weiterhin auf den Server zugreifen.

Wieder was gelernt.

Das fehlt mir wirklich, wenn ich unter OS X arbeite: Die Möglichkeit, alle laufenden Programme mal eben zu minimieren. Windows kennt das – “Desktop anzeigen” heißt die Funktion in der Schnellstartleiste.

Von Haus aus gibt es sowas nicht für den Mac. Ein kleines Freeware-Tool rüstet es aber nach. Danke dafür.

Wer wie ich komplexe Windows Forms Applikationen schreibt, die dann auch noch – auf speziellen Kundenwunsch hin – transparente Controls o.ä. verwenden, der kennt das Problem: Bei jedem Repaint, Resize oder Paint flackert der Bildschirm, dass es unerträglich ist.

Die einfachste Abhilfe schafft

DoubleBuffered = True

bei allen Formularen und Container-Controls. Zusätzlich (weil gerne auch Controls flackern, die über diese Eigenschaft nicht verfügen), sollte folgender Code in den Konstruktor (VB):

SetStyle(ControlStyles.UserPaint Or _
   ControlStyles.DoubleBuffer Or _
   ControlStyles.AllPaintingInWmPaint, True)

In C# siehts so ähnlich aus:

SetStyle(ControlStyles.UserPaint |
   ControlStyles.DoubleBuffer |
   ControlStyles.AllPaintingInWmPaint, true);

Das geht bei allen Controls, ggf. muss man halt eine Ableitung machen. Und dann beschwert sich auch kein Kunde mehr.

Okay, nach einer Weile hab selbst ich es rausbekommen: Wenn man per ASP.NET AJAX eine Webdienst-Methode in einem JavaScript nutzen möchte, dann sollte man sich nicht nur auf die Dokumentation verlassen. Dort steht nämlich, dass der Webdienst so aussehen sollte:

namespace AJAXSample
{
   ///

      [WebMethod, ScriptMethod]
      public string GoodMorning()
      {
         return “Guten Morgen!”;
      }
   }
}

Die wirklich wichtige Stelle ist mal gefettet und gekursivt . Das Einbinden kann dann per JavaScript in einer Seite (nach der Registrierung des Services im ScriptManager-Control) so aussehen:

Doof nur, dass das nicht funktioniert. Man erhält immer nur die Info, dass der Webservice nicht definiert sei.

Ein wenig googlen brachte mich dann – mal wieder – zur ASP.NET Zone und siehe, ich fand die Lösung: Beim ScriptMethod-Attribut muss explizit der Zugriff per HTTP-GET erlaubt sein:

[WebMethod, ScriptMethod(UseHttpGet=true)]
public string GoodMorning()
{
   return “Guten Morgen!”;
}

Dann funktioniert es auch.

Schon oft benutzt, aber ich vergesse sie immer wieder: Die document()-Funktion erlaubt es, zur Laufzeit weitere XML-Dokumente zum eigentlichen XML-Dokument quasi hinzuzuladen. Sehr nützlich.

Gerade eben hab ich mir nen Wolf gesucht. Situation: DataGridView in Windows-Forms-Applikation auf das Formular gezogen, per automatisch generierter Datenquelle an Datenbank gebunden – und dann der untaugliche Versuch, die Daten nach dem Editieren im DataGridView gepflegt wieder wegspeichern zu lassen. Untauglich deshalb, da es keine geeigneten Events gibt – weder auf Ebene der DataTable, noch des DataGridViews, noch der Datenquelle.

Nach ein wenig rumgooglen hab ich eine Lösung gefunden: An das PositionChanged-Ereignis der BindingSource binden und dort dann die jeweils letzte Zeile speichern. Könnte dann so aussehen:

private DataRow _lastRow;

   // Aktuelle Spalte merken
   LastRow = currentRow;
}

Also, irgendwie nervt mich das. Ich werd wohl wieder auf das Click- bzw. DoubleClick-Ereignis des DataGridViews reagieren und dann den aktuellen Datensatz in einem neuen Fenster anzeigen und bearbeiten lassen. Macht sich alles deutlich einfacher.

Echt, man wird alt wie Sack und lernt doch immer wieder was dazu, wenn man eine Schulung gibt. So geschehen in dieser Woche, als ich eine C#-Schulung für C++-Umsteiger gegeben habe.

Speziell ging es um die #region-Direktive, mit deren Hilfe man Bereiche im Code zusammenklappen und benennen kann. Ich zeige das wie gewohnt für Klassen und Methoden und hab nicht schlecht aus der Wäsche geschaut, als plötzlich die Frage aufkam, ob das nicht auch innerhalb von Methoden oder Eigenschaften ginge. Öhm, eigentlich, … Okay, ausprobiert, geschaut – und es hat funktioniert. Logisch, ist ja eine Prä-Prozessor-Direktive.

Ist mir aber in dem Moment nicht eingefallen. Nun weiß ich es aber.

Hier findet man eine brauchbare Übersicht über die möglichen Patterns der DateTime.ToString()-Methode.

…könnte das unter Umständen auch daran liegen, dass sie nicht aktiviert ist. Dementsprechend kann der Eintrag

…

in der web.config durchaus Wunder bewirken, wie der Kollege in diesem Thread sicherlich bestätigen kann.

Was ich ihm nicht verraten habe: Mir ist es vor einigen Tagen genau so gegangen, deshalb bin ich auch so schnell auf des Rätsels Lösung gekommen.

Gerade habe ich eine Web-Applikation für den Datenbankzugriff per Integrated Security unter Vista und IIS 7 konfigurieren wollen, da steckte ich mal wieder fest: Mein gewohntes Hinzufügen von NT-AUTORITÄT\NETZWERKDIENST half in diesem Fall nix. Stattdessen ging es mit NT-AUTORITÄT\IUSR. Hängt damit zusammen, dass Integrierte Sicherheit im IIS für diese Applikation aktiviert ist.

Ja, klar, natürlich: Per Http-Request, WebClient oder ähnlichen Tools geht es immer. Was aber, wenn eine Seite aus der lokalen Webapplikation aufgerufen werden soll – geht das nicht einfacher und ressourcenschonender?

Tatsächlich geht das. Man muss lediglich die Server.Execute()-Methode ein wenig mißbrauchen – und wissen, dass man da durchaus auch eigene Parameter übergeben kann. Dann sieht der Code sehr simpel aus, denn Server.Execute() verfügt über einen Überladung, bei der eine StringWriter-Instanz als Parameter übergeben werden kann. Und in der steht dann der generierte HTML-Quellcode.

Lange Rede, kurzes Beispiel:

// URL definieren
string url = “~/Foo.aspx?parameter=bla”;

// HTML-Code abrufen
StringWriter sw = new StringWriter();
HttpContext.Current.Server.Execute(url, sw);
string html = sw.GetStringBuilder().ToString();

Fertich.

Gerade eben in einem Newsgroup-Posting dr=FCber gestolpert: Das Visual =
XPath-Tool zum Erstellen von funktionierenden XPath-Abfragen im =
.NET-Framework (Ich sag nur: Default-Namespaces).

Infos dazu hier: http://weblogs.asp.net/nleghari/articles/27951.aspx.

Merken: Page.ResolveUrl und Page.ResolveClientUrl k=F6nnen sehr =
n=FCtzliche Funktionen sein, wenn man URLs f=FCr einen Client absolut =
haben m=F6chte. Ich habs bisher stets von Hand gemacht.=20

Kleiner Tipp, wenn man nur den Pfad zur aktuellen Seite haben m=F6chte: =
Request.Url.AbsolutePath liefert genau das, was man braucht.

Via href=3D"http://blog.thomasbandt.de/39/1712/de/home/aspnet--relative-links=
-in-absolute-links-umwandeln.aspx">Thomas.

Einfach merken: Die IIS_WPG-Gruppe gibt es bei IIS 7 nicht mehr. Hier hei=DFt sie nun =
IIS_IUSRS. Und bitte nicht vergessen: Wer Basic-Authentication oder die =
Integrierte Windows-Authentifizierung bei IIS 7 nicht auf den ersten =
Blick sieht, wird sie schlicht nachinstallieren m=FCssen.