Ein- und Ausblenden von Rahmen in RDLC-Reports

Ich hatte folgende Anforderung. In einem Report, in welchem Detailzeilen bereits über ein anderes Element ein- und ausgeblendet werden konnten (Plus/Minus-Knopf) sollte eine Summenzeile rein. Diese sollte, wenn die Details ausgeklappt waren, oben mit einer Rahmenlinie abgesetzt sein, aber keine Rahmenlinie haben, wenn der Detailbereich eingeklappt war.

Nun, leider kann man zwar den Rahmentyp dynamisch durch einen Ausdruck anpassen, aber ob nun der Detailbereich ein- oder ausgeklappt ist, lässt sich so nicht feststellen.

Die Lösung hierfür ist: Duplizieren der Summenzeile.

Man hat nun zwei Zeilen mit demselben Inhalt. Die erste Zeile designt man so, wie sie im ausgeklappten Zustand erscheinen soll, die zweite, so wie sie im eingeklappten Zustand erscheinen soll.

Nun wählt man durch Rechtsklick für jede Zeile den Menüpunkt „Row Visibility“. Je nach Anfangszustand stellt man folgende Parameter für jede der zwei Zeilen ein:

Die Zeile, die anfangs sichtbar sein soll, erhält den Zustand „Show“ und „Display can be toggled by this report item“ mit dem entsprechenden Feld, welches auch die Details ein- und ausblendet.

Die Zeile, die bei Statusänderung sichtbar sein soll, erhält den Zustand „Hide“ und „Display can be toggled by this report item“ mit demselben Feld, welches auch die Details und die andere Report-Summenzeile steuert.

Und schon klappt es…

@IBDesignable: Using class UIView for object with custom class

Aktuell programmiere ich eine kleine iOS Anwendung für meine Tochter. Im Zuge der Entwicklung fand ich heraus, dass es schon seit Längerem möglich ist, eigene Views auch im Interface Builder per @IBDesignable Attribut anzeigen zu lassen. Das ging früher nicht. Natürlich hat mich das sehr gefreut und spontan habe ich das mit einem selbstgezeichneten Control ausprobiert…

Nur hat es leider gar nicht funktioniert. Immer bekam ich eine Warnung:

Using class UIView for object with custom class because the class … does not exist

Nach 1 1/2 Stunden intensiven Ausprobierens, Lesen von Tutorials (in denen natürlich alles super klappt) und dem kurzen Gedanken, den ganzen Mist einfach bleiben zu lassen, kam dann die Erleuchtung und damit auch die Lösung:

Die Modulbezeichnung darf keine Leerzeichen oder Sonderzeichen beinhalten. Also merke:

Wenn Du ein neues Projekt anlegst, verzichte auf Leerzeichen und Sonderzeichen…

nuget.exe in Visual Studio 2017 verwenden

In früheren Versionen von Visual Studio konnte ich nuget Packages erzeugen, indem ich ein Post-Build-Ereignis hinzufügt, das das alte Paket löschte und ein neues durch Aufrufen von nuget.exe erzeugte:

nuget pack "$(ProjectPath)"

Das hat mit einem Mal in Visual Studio 2017 nicht mehr funktioniert. Stattdessen begrüßte mich ein Fehler #9009 in der entsprechenden Zeile, was bedeutet, dass nuget.exe von Visual Studio nicht gefunden werden konnte. Ich kopierte die neueste Verson von nuget.exe in C:\Windows\System32 und konnte das Programm auch erfolgreich von der Windows Console aufrufen. Aber was soll ich sagen? Der Fehler in Visual Studio kam immernoch. Auch in der Visual Studio Nuget Console.

Langer Rede kurzer Sinn (und Facepalm): Da Visual Studio ein 32-bit Programm ist, muss nuget.exe natürlich in C:\Windows\System32\SysWOW64 um es zum Laufen zu kriegen…

Man sollte sein Framework kennen

Man lernt ja auch jeden Tag was neues. Heute habe ich gelernt, dass es to tatsächlich eine nützliche Klasse namens TextFieldParser im .NET Framework gibt, genauer, im Namespace Microsoft.VisualBasic.FileIo. Anders als der Name vermuten lässt, kann man diese natürlich auch in C# nutzen

Sie hilft beim Parsen von Festlängen- oder feldgetrennten Textdateien und ist hier dokumentiert.

Nochmal zum Windows PATH

Kürzlich habe ich schon einmal einen Beitrag geschrieben, in dem es darum ging, dass die PATH-Umgebungsvariable in Windows eine bestimmte Länge nicht überschreiten darf.

Die logische Konsequenz ist, andere Umgebungsvariablen zur Verkürzung heranzuziehen. Beispielsweise kann man das Präfix C:\Program Files (x86) in einer neuen Pfadvariablen namens PA1 und C:\Program Files in PA2 hinterlegen.

Dann kann man in der PATH-Variable %PA1%\Microsoft\… schreiben und muss nicht den kompletten Pfad C:\Program Files (x86)\Microsoft\… hinterlegen. Dies verkürzt den Inhalt der PATH-Variable.

Hinweis: Die neuen Umgebungsvariablen müssen vom System vor der PATH-Umgebungsvariablen verarbeitet werden, was bedeutet, dass sie bei alphanummerischer Sortierung vor der PATH-Umgebungsvariablen einsortiert werden müssen.