Thomas Wölfers Baustatik-Blog

Thomas Wölfers Baustatik Blog

Update: Biegedrillknicken


Bei XRST (Das Programm zur Berechnung räumlicher Stabtragwerke) wurden die Federsteifigkeiten von Trapezblechen im Rahmen des Biegedrillknicknachweises zu gering angesetzt. Die bisherigen Berechnungen lagen damit zwar auf der sicheren Seite, waren aber nicht optimal.

Dieses Update korrigiert das Problem. Sie brauchen nicht das Programm XRST selbst herunterzuladen, sondern nur eine einzelne DLL. (Alternativ können Sie das CD-Rom Image herunterladen und installieren.)


Fehler beim runterladen der Statikprogramme


Wie die Downloads der Baustatik-Software von D.I.E. funktionieren

Wenn Sie einen Work&Cash Vertrag, einen Wartungsvertrag oder eine (kostenlose) (Hoch)-Schulversion unserer Baustatikprogramme haben, dann können Sie die Programme, neue Versionen und Updates ja von unserem Server herunterladen.

Hier ein kurzer Überblick wie das geht, was dabei manchmal schiefgehen kann, und was man dagegen tun kann.

Die Programme liegen auf einem Download-Server in unserem Münchner Büro der über eine 2MBit Standleitung ans Internet angeschlossen ist. Beim Server für die Downloads handelt es sich um den gleichen Server, von dem Sie auch dieses Blog und unsere Webseiten unter www.die.de herunterladen.

Mit anderen Worten: Wenn Sie diesen Server sehen, aber Probleme mit den Downloads haben, dann liegt das zunächst mal nicht an der Anbindung des Servers. :-)

Von Haus aus ist die Sache mit dem Download ganz einfach: Zusammen mit Ihrer Lizenz haben Sie einen Zugangscode erhalten. Den geben Sie auf der Eingangs-Seite für die Downloads ein, und gelangen dann zu einer weiteren Seite. Dort finden Sie die einzelnen Downloads aufgelistet.

Welche Komponenten der Statikprogramme Sie am besten runterladen habe ich an einer anderen Stelle bereits erläutert.

Nun ist es so das der Download manchmal abbricht oder langsam wird. Das kann verschiedene Gründe haben:

Die 2MBit Anbindung ist zwar ganz gut, aber alle Kunden teilen sich diese Anbindung. Im Monat werden momentan etwa 1000 Programme/Pakete heruntergeladen, also etwa 30 am Tag. Nachdem Nachts weniger runtergeladen wird als tagsüber kann man wohl davon ausgehen, das pro Stunde etwa 3-4 mal etwas runtergeladen wird. Treffen nun zwei, drei oder gar vier Anwender zufällig zum gleichen Zeitpunkt die Entscheidung etwas runterzuladen, dann geht die verfügbare Bandbreite pro Download auf 500 MBit runter - und das ist kann dann (in Abhängigkeit von Ihrer Anbindung) als 'langsamer werdend' gespürt werden. Dagegen kann man nicht viel tun ausser eben ein paar Minuten länger zu warten. ;-)

Dann ist es so das auch unser Server einfach nur ein Server im Internet ist und darum allen möglichen Problemen unterliegt denen auch alle anderen Servern im Internet unterliegen. So kann zum Beispiel der von Ihnen benutzte DNS Server kurzfristig Probleme haben - das merkt man beim normalen surfen nicht: Die Sache hakt einfach nur kurz. Bei einem größeren Download kann das 'haken' aber einen Abbruch des Downloads zur Folge haben. Aergerlich - aber nicht zu ändern. Hier gilt: Download nochmal starten, sorry. :(

Dann kann natürlich auch auf unserer Seite irgendwas schief gegangen sein: Unser ISP kann Probleme haben, die Server-Hardware kann streiken oder die Putzfrau hat schlicht und ergreifend das Kabel rausgezogen. (Letzteres ist unwahrscheinlich, denn das Ding steckt in einem massivem Stahlschrank und sämtliche Kabel sind gesicht... aber wer weiss,... :-) )

Das passiert zwar selten, aber es passiert. Zum Beispiel wenn der Server im Rahmen der automatischen Windows-Updates gebootet werden muss. Nun wäre es schön wenn er das nicht täte, während Sie gerade ein Download vornehmen: Aber Sie können es sich schon denken - er tuts trotzdem. Auch dann gilt: Sorry, leider nochmal von vorn. (Allerdings: Die Kiste ist in diesem Jahr genau dreimal wg. sowas gebootet worden, und das war immer um 03.00.)

Und dann gibts da noch die Unwägbarkeiten auf Ihrem eigenen Rechner. Die kommt in der Form von Antivirus-Software zum Zuge, denn solche Programme wollen natürlich während der runterladens schon in die runtergeladenen Daten sehen. Bei kleinen Dateien geht das schnell und man merkt es kaum - beim 32 MB großen CD-Image der Baustatiksoftware kann das hingegen ein deutliches Verzögern des Downloads zur Folge haben. Das ist aber kein Grund die Antivirus-Software auszuschalten! Lieber ein bisschen langsamer, aber dafür sicherer!

Letzten Endes...

läuft es immer auf das gleiche hinaus: Sorry wenns nicht ging - aber wir sind wirklich nur extrem selten die Schuldigen dabei. Im Normalfall wirds reichen, wenn Sie den download einfach ein paar Minuten später nochmal starten. :-)

Und wo ich gerade dabei bin: Der Fleissigste Download-Monat der letzten Zeit war der November 2003: Da wurden 1181 Programme bzw. Images runtergeladen. Bei unserer Webseite sieht das ein bisschen anders aus: Da war der April 2004 am stärksten besucht - und zwaqr mit etwas über 20.000 heruntergeladenen Webseiten.


DevDays in München


Wie gestern angekündigt hier ein Kurzbericht zu den DevDays in München. Allerdings wirklich nur sehr kurz... Es gab zwei parallele Tracks mit Vorträgen, sodass ich nur zu etwa der Hälfte der Vorträge was sagen kann - dazu kann ich allerdings sagen, das sie sehr dünn, sehr untechnisch und nach meinem Empfinden sehr enttäuschend waren.

Teilweise hatte ich den Eindruck in einer Veranstaltung für Anwender, und nicht in einer für Entwickler zu sitzen.

Wer noch nie was von .NET, Webservices, Windows Forms oder Sicherheit beim entwickeln von (Server)Anwendungen gehört hat - der war auf dieser Veranstaltung sicher gut aufgehoben. Wer allerdings einfach nur ein paar gängige Informationsquellen verfolgt - zum Beispiel regelmäßig ein paar Blicke in aktuelle MSDN Artikel wirft - der wird nach meinem dafürhalten nichts dazugelernt haben.

Hatte mir wirklich mehr versprochen. Schade: Ein ganzer Tag verschwendet. 


Morgen: DevDays in München


Morgen sind die DevDays in München. Das schau ich mir an; wenn es etwas wirklich interessantes gibt, dann werde ich hinterher hier darüber berichten. Bin schon ewig nicht mehr auf so einer Veranstaltung gewesen: Lass mich also überraschen.


Kostenloser Profiler für .NET Anwendungen


Duncan Mackenzie weist auf einen kostenlosen Profiler für .NET Anwendungen hin. Der DevPartner Profiler in der Community Edition ist kostenlos, integriert sich mit Visual Studio und liefert die typischen Profiler-Daten über Anwendungen.

Das Ding hat einen Installer der ein wenig komisch funktioniert (wenn es so aussieht als wäre das Ding in einer Endlosschleife gelandet: Es ist es nicht) und hat außerdem eine etwas wenig aussagekräftige Art und Weise in der er aktiviert wird: Im Visual Studio gibts nach der Installation im Toos-Menu unter anderem einen Punkt 'Profiler'. Wenn man da einmal draufklickt, dann wird der Profiler für die folgenden Programmläufe aktiviert. Das kann man aber leider nicht sehen, denn es erscheint keine passende Markierung im Menu - allerdings wird der Debug-Lauf der Anwendung langsamer. (Bei größeren Anwendungen macht das die Sache fast unbrauchbar, aber das ist bei solchen Tools normal.)

Mit einem zweiten Klick (der ebenfalls keinerlei optisches Feeback hat) wird der Profiler wieder deaktiviert.

Davon ab: Prima Programm. Kommt mit VB.NET, C#, VC++.NET, JScript 7 und unmanaged VC++ klar.


Neue Longhorn-Version


Es gibt ein neues Build von Longhorn, der nächsten Version von Windows. Longhorn wird erst im Jahre 2006 erwartet, die verfügbare Version ist also noch eine sehr frühe Variante - es kann ja aber trotzdem nicht schaden, sich das mal anzusehen. Was ich auch am Wochenende vor hatte, aber dummerweise scheine ich nicht der einzige zu sein, der die 2.6 GB gerade runterlädt: Mit der aktuellen Download-Geschwindigkeit von etwa 20 KB/s wird es wohl noch bis Montag dauern, bis ich die Sache ausprobieren kann.

Das SDK ist übrigens hier.


Warum man beim FEM Plattenprogramm den Zoom-Ausschnitt nicht per Scrollbar verschieben kann


... und wie das beim Faltwerk und anderen zukünftigen Programmen sein wird.

Die kurze Erklärung: Der zuständige Entwickler hat lange gebraucht um das Problem zu verstehen.

Der lange Erklärung: Der zuständige Entwickler bin ich, und ich habe wirklich sehr lange daran rumgeknabbert. Dabei sieht die Sache eigentlich ganz einfach aus: Man hat einen Detail-Ausschnitt des Bauwerkes am Bildschirm und will nun den Teil sehen der rechts (links, oben oder unten) vom momentan angezeigten Detail liegt. Was wäre da einfacher, als eben den Scrollbar zu verschieben - und damit auch den angezeigten Ausschnitt des Tragwerkes am Bildschirm. Welcher Ausschnitt das ist, kann man dabei recht gut an der Position des Buttons innerhalb des Scrollbars ablesen.

So einfach ist das aber gar nicht. In Wirklichkeit ist es nämlich so, das es zwei völlig unterschiedliche Fälle gibt, die beim verschieben des Ausschnittes per Scrollbar eintreten können.

Der eine Fall ist tatsächlich der eben geschilderte: Dabei sieht man einen Teil des Bauwerkes und kann dann einen Ausschnitt in der momentanen Größe sozusagen über das Bauwerk bewegen: Dabei sieht man dann eben immer einen Teil der Konstruktion.

Der zweite Fall ist hingegen der, das das gesamte Bauwerk vollständig auf dem Bildschirm zu sehen ist.

Nun könnte man argumentieren das man in diesem Fall ja gar keine Scrollbars braucht - schliesslich gibt es nichts zu verschieben: Es ist ja alles sichtbar.

Das stimmt aber nicht. Woher sollte die Software denn wissen was 'alles' ist? Angenommen, es ist am Bildschirm nur ein einzelner Träger sichtbar weil bisher noch nicht mehr eingegeben wurde: Will man dann etwas nicht auch neben diesen Träger scrollen können? Und wenn ja - wie weit eigentlich?

Letztlich läuft das darauf hinaus, das man sich um das vorhandene Bauwerk eine Art Rand denken muss, und der muss groß genug sein um den Teil der Konstruktion der noch gar nicht eingegeben wurde aufnehmen zu können.

Mit anderen Worten: Die Software muss erraten wie groß das Bauwerk sein wird, wenn es fertig eingegeben wurde. Denn nur dann können auch die Scrollbars richtig positioniert werden.

Hinter die Lösung dieses Problems bin ich erst im letzten Jahr gekommen, als der Programmcode für die 3d-Ansichten beim Faltwerksprogramm entstanden ist: Und dort (und in anderen kommenden Programmen) ist die Sache dann auch so gelöst: Ist nur ein Detail des Tragwerkes sichtbar, dann kann man innerhalb des Bauwerkes scrollen. Ist alles sichtbar, dann kann man das gesamte Bauwerk innerhalb eines deutlich größeren Bereiches bewegen. Bei der Gelegenheit hat sich sowieso eine Menge an der Logik getan, mit der man Zoom, Scrollen und die 3d-Ansichten einstellen kann: Doch dazu gibts ein anderes Mal mehr Informationen - jetzt muss ich erstmal wieder an die Arbeit. :-)


Update: XDUR, XSAN


XDUR (Durchlaufträger):

Eine nur seitliche Halterung am Trägerende führte zu  unsinnigen Schubnachweisen. Dieses Update korrigiert den Fehler.

XSAN (  Stahlanschluss: Bemessung, Nachweis ):

Beim letzten Update wurden zwei unserer DLLs ersetzt. Dies führte leider zu Inkompatibilitäten mit den DLLs für Xbdk (Biegedrillknicknachweis) und Xsan (Stahlanschlüsse). Beide Programme konnten teilweise keine Nachweise mehr führen.

Um dieses Problem zu beseitigen müssen Sie die DLLs aus dieser Datei extrahieren und in das Sys-Verzeichnis unterhalb Ihres Installationsverzeichnisses kopieren.

Aus dem gleichen Grund muss auch XSAN neu installiert werden.<


Wei immer: Alternativ zu den Einzel-Updates können Sie auch das CD-ROM Abbild mit allen Statikprogrammen installieren.


Kurzabriss: Serialisierung in .NET


Nächster Beitrag (morgen...) : Warum man in XPLA den Zoom-Ausschnitt nicht mit Scrollbars verschieben kann (und wie das beim Faltwerk ist.)

Serialisierung in .NET - bzw: Eben keine

Meiner Ansicht nach nicht besonders gelungen in .NET: Serialisierung von Objekten auf die Platte, mit anderen Worten: Das speichern von Eingabedaten.

Für persistieren gibts drei Klassen in .NET: Den XmlSerializer, den SoapFormatter und den BinaryFormatter. Soap- und BinaryFormatter unterscheiden sich im wesentlichen dadurch, das der SoapFormatter ein von Menschen lesbares (naja, was man im Fall von Soap so lesbar nennt) Format erzeugt, während der BinaryFormatter eben eine Binärdatei anlegt. Die beiden sind ansonstem im Wesentlichen gleich.

Der XmlSerializer ist primär dafür gedacht, stark typisierte Daten als typisierte XML-Files abzubilden. Ergebnis: typische beliebige Objektgraphen sind damit nicht speicherbar. Einer der Gründe ist unter anderem der, das der Formatter alle Typen kennen will die er speichern soll. Das gilt auch für abgeleitete Klassen. Nachdem der Sinn des Ableitens unter anderem in einer späteren Erweiterung einer Klasse besteht, kann man den XmlSerializer also de Facto dafür nicht benutzen. Anders ausgedrückt: Damit kann man nur dann Daten persistieren, wenn man vorher weiss, wie sämtliche zu persistierenden Objekte aussehen, und in welchen Klassen die vorliegen. Das mag bei Datenbank-Daten gehen, bei Anwendungen die durch neue Objekte erweiter werden können geht das schlicht und ergreifen nicht. Bei Daten bei denen es geht, ist das XmlSerializer dafür sehr schnell.

Anders als die *Formatter. :-(

Die können zwar beliebige Graphen persistieren, sind dafür aber lahm. Und obendrein noch geschwätzig, denn die sind eigentlich für den Transport von Daten übers Netz (also z.b. für die Webservice Kommunikation). Darum enthalten dann die Dateien die man damit erzeugt auch massive Menge an Soap-Markup, das fürs 'ganz normale' speichern von Eingabedaten einfach nur sinnloses Overhead bedeutet.

Gelernt: XmlSerializer ist prima für Daten die von Menschen lesbar sein sollen, sofern alle beteiligten Typen vorher bekannt sind. (Also zum Beispiels fürs persistieren einer Menüstruktur.) *Formatter ist eigentlich was für WebServices. Zum Speichern von lokalen Daten gibts nichts spezialisiertes.

Traurige Sache, man sollte eigentlich erwarten das sowas elementares mitlerweile Teil der Infrastruktur ist. Ist es aber eben nicht.