Thomas Wölfers Baustatik-Blog

Thomas Wölfers Baustatik Blog

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.


Thanks to Robert Scoble


Robert,

incase you stumble over this: thanks for pointing here since april. noticed 10 minute ago you did... :-)

might be good for your german skills, having added this to your 1400 (plus some) blogs... ;-)

oh - and yes, you were right. this blog thing is really working on google. amazing. 

WM_THX
thomas woelfer

Roberts Weblog ist hier (und rechts im Blogroll) - aber morgen ist hier wieder alles vollständig auf deutsch.


Halfen-Deha, Setup und die Dateierweiterung HTA


Von Halfen-Deha gibt es nicht nur Produkte die man anfassen kann, sondern auch Software. Im Wesentlichen sind das Bemessungsprogramme, die auf die einzelnen Produkte von Halfen-Deha spezialisiert sind. Zu den Halfen-Deha Produkten gehören auch die Halfenschienen HTA. Und die zugehörige Software macht ein Probleme.

Das Programm registriert nämlich für sich die Dateierweiterung .hta. Das ist aber die gleiche Erweiterung, wie sie von Windows für Hypertext Applications (Hypertext-Anwendungen) verwendet wird. Eine HTA-Anwendung ist im Wesentlichen ein Programm das sich aus HTML und JavaScript zusammensetzt und ein Web-Browser ähnliches Interface hat. (HTA Anwendungen werden in einem besonderen Browser-Fenster ausgeführt.)

HTA-Anwendungen gibt es eine ganze Menge, eine davon ist der neu CD-Browser der beim installieren von unseren Baustatik-Programmen gestartet wird. Legt man die CD ein oder klickt man auf das Programm 'start' auf der CD, dann sollte eben eigentlich dieser Browser gestartet werden. Damit kann dann der Inhalt der Statik-CD angesehen werden und die Statik-Programme können installiert werden.

Es sei denn, man hat das HTA-Programm von Halfen installiert.

In diesem Fall wird nämlich nicht unser HTA-Programm gestartet, sondern das Bemessungsprogramm von Halfen - denn das hat dann die Dateierweiterung .hta vom System übernommen und denkt, es müsse nun unsere Setup-Datei lesen. Was natürlich nicht klappt.

Wir sind wohl nicht die einzigen die deswegen schon mit Halfen kommuniziert haben und Herr Kickstein - der Programmierer des Programms - sagte man werde dieses Problem möglichst noch in der nächsten Version der HTA-Software beheben.

Bis dahin gibt es folgende Möglichkeiten zum installieren unserer Software:

  • Statt das Programm start.hta von der CD zu verwenden, starten Sie setup.exe von der CD: Das installiert die Programme ebenfalls.
  • Oder, Sie geben die Dateierweiterung für HTA-Dateien wieder dem Programm, das sie eigentlich haben sollte. Das geht so:
  1. Im Explorer klicken Sie im Menü auf 'Extras -> Ordneroptionen'
  2. Im dann angezeigten Dialog gehen Sie auf 'Dateitypen'
  3. In der Liste der Dateitypen suchen Sie HTA (dazu können sie in die Liste klicken und dann einfach 'hta' tippen)
  4. Ist HTA markiert, klicken Sie auf den Button 'Aender'. Der öffnet wieder einen Dialog.
  5. Dort finden Sie eine Liste mit einem Ast der unter anderem auch 'Empfohlene Programme' enthält.
  6. Dort wählen Sie 'Microsoft HTML Application Host' aus, klicken OK, und schließen alle Dialoge wieder.

Danach können Sie auch unsere 'start.hta' zur Installation der Programme, und alle anderen Windows-HTA Anwendungen wieder normale ausführen.


Neue Version von dasBlog


dasBlog Version 1.6 ist da

Wer auch dasBlog einsetzt und den zugehörigen RSS Feed abonniert hat: Der wird das neueste Update verpassen, denn offenbar ist der Feed auf dasblog.net nicht länger aktiv. Zumindest erweckt das den Eindruck, denn seit kurzem ist Version 1.6 draußen - und der Feed meldet sich nicht.

Mehr Infos im GotDotNet Workspace. (Da gibts auch einen Feed mit Releases, und der enthält auch tatsächlich Informationen zur neuen Version.) Eigentlich aber besser: Omar Shanines Log.

Bestes neues Feature: Ein Macro für die Anzeige von vergangenen Monaten mit Logs, zweitbestes neues Feature: Alle Statistiken sind parametrisiert abrufbar - man kann also auch ältere Statistiken abrufen. Liste der neuen Features.