Ich habe heute eine kleiner Änderung an der Baustatik vorgenommen (die aber im großen und ganze die Sache nicht ändert: Trotzdem gilt die Beschreibung aus diesem Eintrag so erst ab dem nächsten Update.)

Wenn man eine Flächeneinwirkung definiert, dann muss man dafür auch ein Faltwerkselement angeben. Nun ist es so, das die Angabe dieses Elements “eigentlich” nur für die Festlegung des lokalen Koordinatensystems wichtig ist. Hat man zwei Faltwerkselemente (A und B)in der gleichen Ebene, dann kann man Flächeneinwirkungen auf beiden definieren, indem man entweder einmal A und einmal B verwendet, oder für beide A oder B.

Nun will die Baustatik möglichst viel Arbeit automatisieren, und versucht daher “automatisch” das “richtige” Faltwerkselement zu ermitteln, damit der Anwender selbiges nicht selbst eintragen muss.

Und das geht so:

Im einfachsten Fall hat man den Befehl “Flächeneinwirkung auf Auswahl” ausgewählt und zuvor ein Faltwerkselement ausgewählt – dann wird logischerweise dieses verwendet.

Komplizierter wird es, wenn man eine “Flächeneinwirkung graphisch” erzeugt. Dabei  prüft das Programm zunächst, ob es mehr als ein Faltwerkselement gibt. Ist das nicht der Fall – gibt es also nur eines – dann wird dieses verwendet.

Gibt es mehrere, dann untersucht das Programm, ob diese in Bezug aufs Koordinatensystem gleichwertig sind. (Das ist zum Beispiel immer dann der Fall, wenn man reine Platten definiert, und manuell nichts an der Ausrichtung der Platten ändert.)

Ist das nicht der Fall, dann erfragt das Programm, welches Faltwerkselement als “Ziel” gewünscht ist.

Sind die Faltwerkselemente gleichwertig, dann wird überprüft, ob bereits andere Flächeneinwirkungen eingegeben wurden. Ist das der Fall, dann wird das Faltwerkselement der zuletzt definierten Flächeneinwirkung verwendet – sofern in dieser ein Faltwerkselement gesetzt ist.

Wenn alle Betrachtungen bisher kein eindeutiges Element liefern konnten, dann wir das zuletzt erzeugte Faltwerkselement verwendet.

Ergebnis: Hinterher hat man (fast) immer automatisch “das richtige” Element, ohne es selbst eingeben zu müssen.

Im großen und ganzen scheint die jetzt seit fast 3 Wochen verfügbare 64bit Version der Baustatik nur sehr wenig Ärger zu machen – eigentlich gab es bisher nur kleinere Ärgerlichkeiten, die wir korrigiert haben.

Heute bin ich auch noch so einen Fall aufmerksam geworden – in diesem Fall nicht wirklich eine Kleinigkeit, aber wohl ein Fall, der nur sehr wenige Kunden betrifft.

Damit das Problem eintritt, müssen drei Voraussetzungen erfüllt sein. Zum einen muss der eingesetzte Rechner ein 64bit Windows Rechner sein. (Nur dann wird auch mit der 64bit Version der Baustatik gearbeitet, und nur in dieser Version tritt das Problem auf.). Zweitens muss die Software per Work&Cash verwendet werden. Bei allen anderen Lizenz-Arten tritt das Problem ebenfalls nicht auf. Und schließlich darf der verwendete Timeserver kein lokal installierter sein – er muss sich statt dessen auf einem anderem Rechner im Netzwerk befinden.

In diesem Fall kann man zwar die alten Programme “einfach so” verwenden, bei der Verwendung der Baustatik erhält man aber eine Fehlermeldung, das der Timeserver “keine Zeiteinheiten” mehr übrig hat.

Wer dieses Problem mit der Baustatik hat, der kann hier eine Zwischenversion herunterladen, bei der dieses Problem behoben ist. (Zum installieren der Zwischenversion muss zunächst die vorhandene Version manuell über die Systemsteuerung deinstalliert werden. Danach kann die Zwischenversion installiert werden.)

Wieso tritt das auf, und warum haben wir (ich) das beim testen nicht gefunden?

Um das zu verstehen, muss man einige Dinge über die beteiligten Komponenten wissen. Die “alten” Programme laufen immer als 32bit Programme, während die Baustatik auf 32bit Windows als 32bit Programm und unter 64bit Windows als 64bit Programm läuft. (Das ist seit dem letzten Update so: Davor war die Baustatik auch immer ein 32bit Prozess.)

Der Timeserver selbst ist grundsätzlich ein 32bit Programm. (Man hätte auch keine Vorteile davon, wenn er unter 64bit Windows ein 64bit Programm wäre – der Speicherbedarf des Timeservers ist minimal.)

Die Client-seitige Konfiguration des Timeservers – also der Teil, der sich damit beschäftigt wie die Programme mit dem Timeserver kommunizieren – erfolgt also auch als 32bit Prozess. Die Konfigurationsdaten werden dabei in der Registry hinterlegt.

Nun ist es so, das 64bit Programme und 32bit Programme für einige Einstellungen in der Registry unterschiedliche Äste verwenden. (Der Grund dafür ist die Rückwärtskompatibilität für 32bit.). Das gilt auch für den TimeServer – der schreibt seine Konfigurationsdaten immer in den 32bit-Teil der Registry. Darum können die alten Programme diese Konfiguration auch lesen und funktionierten klaglos. Die 64bit Variante der Baustatik versuchte aber die Konfigurationsdaten aus dem 64bit Teil der Registry zu lesen: Nur, das da eben nichts stand.

Wenn diese Konfigurationsdaten nicht gefunden werden, dann versucht die Software grundsätzlich eine lokale Verbindung herzustellen – ganz egal, was man “eigentlich” eingestellt hat. Das tut natürlich weiter nicht weh, wenn man ohnehin eine lokale Verbindung wünscht.

Will man aber eine “entfernte” zu einem anderen Host, dann kamen diese Einstellungen bei der Software gar nicht erst an – und sie stellte eine lokale her. Die lokale Verbindung ging aber, denn einen lokalen TimeServer gibt es ja immer. Nur war – im Fall der betroffenen Kunden – dort keine Zeit eingetragen. Warum auch: Die sollte ja zentral verwaltet werden. Das Resultat war dann die eingangs genannte Fehlermeldung.

Beim testen habe ich das aus einem einfachen Grund nicht gemerkt: Ich habe mir die Sache zu einfach gemacht. Statt tatsächlich einen anderen Rechner als Remotehost zu verwenden, habe ich auf meiner lokalen Workstation den Timeserver so konfiguriert, das er auch per Netzwerk kommunizieren kann. In der Client-Konfiguration haben ich dann auch “Netzwerk” eingestellt – und die Sache funktionierte. Nur eben nicht per Netzwerk, sondern lokal – weil das der Rückfallmechanismus ist, der dann eintritt, wenn die Konfigurationsdaten nicht gefunden werden. Sah aber “richtig” aus. Sorry

Ab dem nächsten Update funktioniert das auch in der genannten Kombination richtig, bis dahin kann man die oben verlinkte Zwischenversion verwenden, in der das auch korrigiert ist.

Ab sofort gibt es ein neues Update für die Baustatik auf Version 1.81. Nachdem erst Ende letzter Woche die Version 1.80 freigegeben wurde stellt sich die Frage: Warum.

Folgendes ist passiert: Das Installationsprogramm der Baustatik wird seit geraumer Zeit auf einem speziellen Rechner hergestellt (und zwar auf meiner Workstation ) – der größte Teil des Prozesses ist dabei automatisiert. Um in der Zukunft einfacher in der Lage zu sein “Zwischenversionen” zu veröffentlichen, wurde der gesamte Prozess auf einen anderen Computer umgezogen. Zumindest in der Theorie. In der Praxis fehlte beim Umzug leider ein Teil – und zwar der vom Timeserver. Darum verschwanden bei einigen Kunden die Timeserver-Installationen direkt nach dem Update.

Die jetzt verfügbare Version beseitigt dieses Problem. Und nachdem es nun einen dedizierten Rechner dafür gibt, sollten derlei Problem in der Zukunft eigentlich nicht mehr auftreten können.

Sorry für die Verwirrung.

In der Baustatik gibt es einen Erweiterungsmechanismus per Makros. Wer mag, kann damit eigenen Befehle oder Fenster für die Baustatik programmieren – die zur Verfügung stehenden Wege sind hier dokumentiert.

Im allgemeinen wird das aber hauptsächlich von uns dafür verwendet, “auf die Schnelle” kleinere Problemlösungen für Einzelkunden zu bauen. Die Makros werden dann von uns veröffentlicht, aber nicht weiter dauerhaft gepflegt. Als Beispiel für eigene Makros kann man sie aber auf jeden Fall verwenden.

Dazu gibt es ein eigenes Makro-Menü im Programm, und mit dem kann man diese Makros auch runterladen und ausführen.

Abgesehen davon, das das in den letzten beiden Tagen nicht ging.

Grund: Wir haben die IT Infrastruktur im Münchner Büro konsolidiert – statt 3 physischer Maschinen gibt es jetzt nur noch eine einzelne, auf der dafür jede Menge virtueller Maschinen betrieben werden. Und einer der “abgeschafften” Rechner betrieb auch den Webserver, über den man an die Makros kam.

Seit heute läuft aber wieder alles im alten Umfang (abgesehen natürlich von den Dingen, die ich vergessen habe ) – und man kann auch wieder Makros runterladen.

Wenn wir mit dem telefonischen Support bei einzelnen Problemen einfach nicht weiterkommen, dann haben wir auch die Möglichkeit, uns direkt mit dem problematischen Computer zu verbinden: In diesem Fall kann unser Mitarbeiter den Computer des Kunden (fast ganz) so bedienen, als würde er davor sitzen. Erklärungen die übers Telefon extrem kompliziert sind (zum Beispiel eine Änderung in der Windows-Registry) können dadurch vollständig entfallen.

Der Kunde kann dabei am eigenen Bildschirm genau verfolgen, was eigentlich passiert.

Damit das klappt, muss zuvor eine Verbindung zwischen dem PC des Support-Mitarbeiters und dem Kunden-PC hergestellt werden. Und das geht so:

Der Kunde geht zunächst auf die Webseite www.copilot.com.

Dort angekommen landet man von selbst auf einem Formular, in das man einen “Invitation Code” eingeben kann. Diese Code bekommt man von unserem Support-Mitarbeiter per Telefon.

So sieht der Code in etwa aus (der abgebildete ist aber ungültig). Ist der Code eingegeben, drückt man auf “GO”.

Dadurch landet man auf der Folgeseite: Hier steht auch schon der Name des Kollegen (hier: Meiner), mit dem man verbunden wird.

Damit das eingeleitet wird, drückt man auf “Download now” (Das grüne Symbol.). Je nach verwendeter Windows-Version und Browser erscheint dann ein Fenster, in dem man angeben kann, ob man die Datei ausführen oder speichern möchte.

Hier drückt man auf “Ausführen”.

Das Verbindungsprogramm wird dann heruntergeladen. Ist es komplett vorhanden, fragt der Browser nochmals nach, ob es ausgeführt werden soll. Hier drückt man wieder auf “ausführen”.

Daraufhin bekommt man ein Fenster, in dem man darauf hingewiesen wird, mit wem man sich gerade verbindet. Ist die Gegenseite die “richtige”, drückt man auf “Yes”.

Dann geht eine Art “Fortschrittsmelder” auf: Es wird nun darauf gewartet, das die Verbindung hergestellt wird.

Sobald das der Fall ist, gibt es ein neues Fenster mit einem “Disconnect” Button – der trennt die Verbindung am Ende der Sitzung: Solange dieses Fenster geöffnet ist, kann der Support-Mitarbeiter mit dem Rechner arbeiten.

Im Durchlaufträger der Baustatik kann man die Ergebnisse sowohl graphisch als auch tabellarisch ausgeben lassen. Anders als in anderen Fällen bei der Baustatik, kann man bei den Eigenschaften der graphischen Elemente in der Ausgabesteuerung aber nicht einstellen, welcher Maßstab verwendet werden soll: Im wesentlichen kann man sich dafür entscheiden, ob zum Beispiel die Graphik der Schnittgrößen mit ausgedruckt wird oder nicht – und das wars.

Aber: Dafür das es so ist, wie es ist, gibt es natürlich einen Grund – und natürlich kann man den Maßstab eben doch einstellen.

Zunächst der Grund: Wenn man den Ausdruck mit Graphiken erstellt, dann will man sicherlich nicht nur eine Graphik drucken, sondern mehrere. Die stehen dann untereinander – und damit das Sinn macht, müssen die auch alle den gleichen Maßstab haben, denn sonst passen sie nicht zusammen. Zusammenpassen sollen sie aber – und zwar auch mit der Systemgraphik: Alle abgebildeten Träger müssen also die gleiche Breite haben, darum macht es auch keinen Sinn das man bei einer einzelnen Graphik einen Maßstab einstellen kann.

Und dort – bei der Systemgraphik – findet man dann auch die Lösung: Hier kann man einen Maßstab einstellen, und der hier eingestellte Maßstab wird dann für alle anderen Bilder verwendet.

Wenn man die Baustatik installiert, dann erscheint immer als erstes ein kleines Fenster mit der Meldung “Überprüfe die Integrität (MD5)”. Was bedeutet das?

Im Wesentlichen geht es darum herauszufinden, ob die Daten des Installationsprogramms in Ordnung sind. Die können nämlich auf viele unterschiedliche Arten defekt werden: Zum Beispiel, weil der Download des Installationsprogramms nicht richtig funktioniert hat, und nur ein Teil des eigentlichen Installationsprogramms vorliegt. Ebenso kann das auftreten, wenn das Medium beschädigt wurde – also die CD zum Beispiel verkratzt ist.

Alle solche Fälle führen zu “interessanten” Fehlermeldung bei der Installation, deren eigentliche Ursache nur sehr schwer zu finden ist.

Darum passiert folgendes: Wenn das Installationsprogramm hergestellt wird, dann wird eine MD5-Prüfsumme ausgerechnet. Diese Prüfsumme identifiziert die Datei (mehr oder weniger) eindeutig.

Wird das Installationsprogramm dann gestartet, dann rechnet es diese Prüfsumme auch nochmals aus. Die neue ausgerechnete wird dann mit der verglichen, die bei der Herstellung ermittelt worden war: Stimmen die beiden nicht überein, dann ist die Datei defekt – und das Programm startet den eigentlichen Installationsvorgang auch nicht.

Eigentlich ist heute der 1. des Monats: Zeit für das regelmäßige Update der Baustatik. Damit es niemand für einen Aprilscherz hält: Es gibt keins – kommt aber nächste Woche…

Die Baustatik hat eine Menge Fenster. Diese Fenster kann man grob in einige Kategorien unterteilen: Es gib natürlich das Hauptfenster der Anwendung - das ist das, wo die Hauptwerkzeugleiste und das Hauptmenü drin ist, und in dem sich alle Arbeitsfenster befinden. Dann gibt es eben diese Arbeitsfenster: Das sind die, in denen die Graphiken angezeigt werden und in denen konstruiert werden kann. Dann gibt es die Ansichtsfenster: Das sind die, die man am Rand andocken oder auch auf einen anderen Monitor ziehen kann.

Alles andere sind "Dialogboxen". Also zum Beispiel die Fenster aus denen eine Berechnungsergebnis ausgewählt werden kann. Oder die, die sich öffnen, wenn man auf ein Objekt doppelklickt.

Und diese Fenster haben es in sich: Auch wenn man es oft nicht sieht, vergeht eine ganze Menge Zeit bis so ein Ding mal "fertig" ist. Um mal zu demonstrieren, was da eigentlich passiert, habe ich hier die "Werdung" des Lastfallgruppen-Fensters fürs das Stützendokument mitgeführt.

Version 1

So sah die allererste Version aus: Es gibt noch keinen richtigen Rahmen, diverse Texte fehlen und das Layout der Elemente darauf lässt auch zu wünschen übrig. Im wesentlichen handelt es sich hier um eine Version, bei der es zunächst mal darum ging, die gewünschte Funktionalität irgendwie abzubilden. Darum gibt es eine List von Bemessungssituation aus der man auswählen kann, eine Liste der Lastfälle (für die später geplante "Vereinfachung" der zu erzeugenden Berechnungsgruppen) und eine einfach Liste der Berechnungsgruppen, die aus der Auswahl resultieren.

Weil es noch keinen anderen Mechanismus zum anstoßen der gewünschten Funktion gab, gibt es einen einfachen "Button", der die eigentliche Funktion des Fensters aktiviert: Er füllt die rechte Liste. Allerdings noch falsch und ohne tatsächlich auf die Auswahl der Bemessungssituation zu reagieren.

Version 2

Hier ist die Situation schon etwas besser: Von Layout ist noch immer nichts zu sehen, dafür gibt es aber in der Liste der Bemessungssituationen schon mal die "richtigen" Texte, und die Liste der Gruppen enthält auch die bereits richtig gruppierten dynamisch erzeugten Gruppen.

Dabei reagiert er auch schon auf die ausgewählte Bemessungssituation. Dabei wird die "Brandeinwirkung" aber noch nicht berücksichtigt: Die ist nämlich in der verfügbaren Bemessungssituationen der Baustatik noch gar nicht drin - und muss darum noch irgendwie gesondert gehandhabt werden.

Version 3

In dieser Version haben sich einige Veränderungen ergeben: Zum einen wird die Anzahl der Lastfallgruppen in der Liste mit angegeben. Dann würden die vorhandenen Listboxen (links) durch "Listviews" ersetzt. Dabei handelt es sich einfach um 2 unterschiedliche Windows-Kontrollelemente: Die zuvor verwendeten Listboxen haben ein etwas eigentümliches Verhalten, was das einschalten der Options-Felder angeht. Die ListViews sind da besser - darum wurden die einen durch die anderen ausgetauscht.

Außerdem machte sich eine zusätzlich benötigte Funktion bemerkbar: Nachdem die Anzahl der erzeugten Lastfallgruppen tendenziell sehr groß werden kann, braucht man eine Möglichkeit, diese Anzahl irgendwie einzuschränken.

Dafür gibt es die beiden Liste "Zu berücksichtigende Lastfälle" und "Erzwungene Lastfälle". In der ersten List soll dann später angegeben werden können, welche Lastfälle berücksichtigt werden sollen. Damit wird es dann möglich, nicht grundsätzlich alle Lastfälle eines Dokuments zu berücksichtigen - sondern nur eine Untermenge davon.

Unter "Erzwungene Lastfälle" kann man noch eine weitere Einschränkung vornehmen: Es werden dann nur noch solche Lastfallgruppen erzeugt, die die "erzwungenen" Lastfälle enthalten. (Ein Eintrag in der zweiten Liste setzt also einen in der ersten voraus.)

Nun kann man also ein Set bestehend aus einer oder mehreren Bemessungssituationen, einer Liste von zu berücksichtigenden Lastfälle und einer aus erzwungenen Lastfällen zusammenstellen: Daraus resultiert dann eine Menge an Lastfallgruppen.

Dummerweise wird man davon mehr als eins benötigen. Das führt dann zur nächsten Version des Fensters.

Version 4

Nachdem man mehr als einen solchen Satz benötigt, macht es Sinn, alle Eingabedaten zusammenzufassen, und wie ein "normales" Objekt der Baustatik (also wie einen Knoten oder Stab) zu behandeln. Diese verwenden aber alle die gleiche Fenster-Vorlage, und darum muss ein völlig neues Fenster auf Basis dieser Vorlage gebaut werden.

Weil die Objekt-Eigenschaften Fenster nicht "allzu" groß werden sollen, haben die im allgemeinen eine feste Größe: Da passt dann aber die Vorschau der erzeugten Gruppen nicht mehr drauf, und darum kommt die in dieser Version auf einen zweiten Reiter. Die Abbildung zeigt wie das Fenster im Fenster-Designer vom Visual Studio aussieht. Zur Laufzeit ist das ein bisschen anders, weil da dann noch die "richtigen" Texte und Icons eingeblendet werden, die zu dem Zeitpunkt als die beiden folgenden Shots  gemacht wurden, noch nicht vollständig "da" waren.

Version 5

Leider stellte sich zu diesem Zeitpunkt heraus, das auch noch Ausschlussgruppen benötigt wurden - also auf zur nächsten Version des Fensters:

Hier gibt es dann auch schon mal den richtigen Text in der Titelleiste und eine Spalte fürs definieren von Ausschlussgruppen.

Ich bin mir relativ sicher, dass es bis zur endgültigen Fertigstellung dieses Fensters noch weitere Änderungen geben wird: Aber um nicht jedermann zu Tode zu langweilen, beende ich die Ausführung an dieser Stelle: Das wirklich "fertige"  Fenster können Sie dann sehen, sobald die Stütze fertig in die Baustatik integriert ist.

Ich hatte heute bei einem Kunden folgende Situation: Er hatte einen Rechner, auf dem noch nie eine “Baustatik” installiert war, und installierte Sie dort mit Hilfe einer runtergeladenen Datei. Wenn er dann versuchte die Baustatik zu starten, gab es nur das hier:

Dafür gibt es natürlich einen Grund: Es gibt zwei Dateien, die man fürs installieren der Baustatik herunterladen kann. Die eine ist die Datei, die man nach dem anmelden im Download-Bereich auf www.die.de erhält. (Das ist die gleiche, die sich auch auf der Installations-CD befindet.) (Das sei mal Datei “A”).

Die andere Datei ist die, die man per “automatischen Updates” herunterlädt: Wenn die Baustatik startet, dann überprüft sie, ob es eine neuere Version gibt, und bietet die dann gegebenenfalls zum herunterladen an. (Das sei mal Datei “B”)

Diese beiden Dateien unterscheiden sich. Die “manuell” runterladbare enthält alle Systemkomponenten, die die Baustatik zum Betrieb benötigt. Dazu gehört zum Beispiel das “Managed DirectX”, eine Windows-Installer Komponente, Datenbank-Treiber und die Visual C++ Laufzeitbibliothek.

Wenn eine dieser Komponenten nicht auf dem Rechner installiert ist, dann wird sie im Zuge der Installation von Datei “A” automatisch mit installiert. Im Normalfall sind aber alle diese Komponenten bereits vorhanden – ausgenommen der VC++ Laufzeitbibliothek.

Datei “B” hingegen ist ein “Update”, und zwar eines das genau für den Rechner gedacht ist, auf dem es heruntergeladen wurde. Befindet man sich z.b. auf einem Rechner mit veralteter VC++ Laufzeit, dann bekommt man ein Update, wo selbige drin ist. Ist man auf einem Rechner, bei dem bereits alle Systemkomponenten vorliegen, dann bekommt man ein Update, das ausschließlich die Baustatik selbst enthält. Grund: Dadurch wird die Größe des Downloads (teilweise dramatisch) verkleinert. (Der “große” Fall umfasst knapp 200 MB, der kleinste etwa 70.)

Nimmt man nun ein Update von einem Rechner mit allen Systemkomponenten und installiert das auf einem Rechner mit fehlenden Systemkomponenten, dann geht es nicht: Die Komponenten fehlen einfach.

Und wenn die VC++ Laufzeitbibliothek fehlt, dann bekommt man genau die Meldung, die ich oben abgebildet habe.

Nun könnte man sich fragen ob es dann nicht sinnvoller wäre, immer einfach das große Paket zu verteilen: Soooo viel sind 200 MB ja nun auch nicht. Allerdings stimmt das nur dann, wenn man einen DSL Anschluss hat – was für alle Anwender in DSL-freien Zonen (von denen es durchaus nicht wenige gibt) nicht zutrifft. Das ist überhaupt der Grund dafür, weswegen wir den Aufwand treiben, und unterschiedliche Updateversionen anbieten.

Ich hatte heute ein “interessantes” Problem in der Baustatik zu beheben: Einige Fenster – im besonderen die zur Auswahl von Bemessungsergebnissen – konnten bei einem Kunden nicht mehr verschoben werden.

Nach einer kurzen Untersuchung stellte sich folgendes heraus: Sobald das Fenster geöffnet wurde, landete es im “Resize” Modus. Dabei handelt es sich um den Zustand, bei dem der Mauscursor zum Doppelpfeil wird um anzudeuten, das man nun den Rand des Fensters anfassen und das Fenster dann in seiner Größe ändern kann.

Das ging auch: Allerdings konnte man nur die Größe ändern. Und egal wie oft man das tat: Der richtige Mauscursor wurde nicht wieder hergestellt – das Fenster blieb in diesem Modus.

Leider habe ich keinen Weg gefunden das zu reproduzieren (und um genau zu sein: Ich glaube das das ein Nebeneffekt des verwendeten Graphikkarten-Treibers oder Maustreibers war – kann ich aber nicht belegen.). Es gibt aber einen Weg das loszuwerden – man muss das Fenster nur zwingen.

Und das geht so: Man klickt mit der Maus auf das Fenster, damit es das “aktuelle” wird. Dann drückt man die Tastenkombination “Alt + Leertaste”. Das ist der Hotkey für das Systemmenü des Fensters, und das klappt dann auch brav auf. In diesem Menü gibt es den Befehl “verschieben”, und den wählt man aus (Notfalls mit der Tastatur: also mit den Cursor-Tasten hinfahren, und dann “Enter” (Return) drücken.).

Das führt dazu, das der Resize-Modus verlassen und der Verschieben-Modus angeworfen wird: Man kann das Fenster dann verschieben.

Beim Kunden war es so, das das Problem danach auch nicht wieder auftauchte. Nachdem ich so etwas bisher auch noch nie von einem anderen Anwender der Baustatik gehört habe, wird das wohl auch nicht besonders oft auftreten: Wenn es doch mal auftritt wissen Sie nun, wie Sie das wieder loswerden. (Es würde mich aber interessieren, wenn das bei Ihnen auftritt: In so einem Fall bitte kurz eine Mail an mich schicken… Danke! )

Die Werkzeugleisten in der Baustatik sind nicht konfigurierbar: Das bedeutet, das diese Leisten eben genau die Befehle enthalten, die wir für sinnvoll halten – und Kunden können nichts daran ändern.

Dafür gibt es einen guten Grund: In den ersten (Beta)Versionen der Baustatik lieferte wir eine Möglichkeit, mit der man diese Leisten ändern konnte. Das wurde dann auch getan – mit dem Problem, das danach natürlich eine vom Kunden per Hand geänderte Leiste vorlag. Das Problem trat dann beim nächsten Update auf: Weil es ja eine anwenderspezifische Leiste gab, wurde die auch vom Programm verwendet. Mit der Konsequenz, das neue Befehle von uns darin nicht auftauchten – wie auch: Dazu müssten wir ja programmatisch die vom Kunden extra hergestellte Leiste verändern, und das ist sicherlich nicht wünschenswert. Resultat: Neue Befehle wurden nicht “gefunden”, weil sie “nicht da” waren.

Das ist der Grund, weshalb man die Werkzeugleisten nicht ändern kann.

Was man aber kann ist, die Werkzeug-Palette verändern: Die Palette ist ausdrücklich für solche anwenderspezifischen Änderungen gedacht, und deren Inhalt wird von uns weder angefasst noch sonst wie verändert.

So legt man fest, was in der Palette erscheint:

Die Anzahl an verfügbaren Spalten kann man übrigens auch einstellen, und zwar hier:

Kunden mit einen Work&Cash Vertrag nutzen alle unsere Statik-Programme rein zeitbasiert. Es gibt also keinen Kaufpreis – alle Programme sind “einfach verfügbar” – sondern man bezahlt nur die reine Arbeitszeit.

Die Verwaltung dieser Arbeitszeit läuft über den TimeServer. Das ist ein Programm, das im Status-Bereich von Windows über ein rotes “D” erreichbar ist: Mit einem Rechtsklick auf das D erhält man ein Menü, über das die Zeit verwaltet oder Statistiken über den Verbrauch erhoben werden können.

Nun hatten einige Kunden im Zuge der letzten Monate das Problem, das dieses rote D nach einem Update nicht länger sichtbar war. Das Programm startet über die “Autostart” Gruppe von Windows: Jedes Mal, wenn man sich anmeldet, wird das Programm automatisch gestartet und kann verwendet werden.

Früher war es so, das unser Installationsprogramm grundsätzlich einen Link in der Autostart-Gruppe angelegt hat. Seit einigen Monaten gibt es aber im Installer die Möglichkeit, das anlegen dieses Links in der Autostart-Gruppe per Optionsschalter auszuschalten.

Wenn man das tut, dann wird diese Verknüpfung auch nicht angelegt – und: Das rote D taucht dann nicht länger automatisch auf. Einfache Lösung: Option nicht ausschalten

Man kann das auch ohne Neuinstallation reparieren: Einfach in der “Autostart” Gruppe im Start-Menü eine Verknüpfung auf das Programm anlegen, dann geht es wieder. Zu finden ist der TimeServer (bei einer normalen Installation) im Order “c:\programme\DIE\TimeWise” unter dem Namen “XTimeWiseServer.exe”.

Wenn in der Baustatik eine unerwartete Situation eintritt – also eine, die das Programm nicht behandeln kann, weil sie nicht berücksichtigt wurde – dann tritt eine Fehlermeldung auf. Im Rahmen der Fehlermeldung kann man selbige zusammen mit ein paar Metadaten an uns schicken: Ich bitte ausdrücklich, das immer zu tun. Danke !

Bei uns landet das in einem Datenbank-Server, und für die Datenbank gibt es ein eigenes Interface – und das sieht so aus:

In der oberen Liste stehen die gemeldeten Fehler. Die erste Spalte gibt an, wie oft der betreffenden Fehler gemeldet wurde. (Dabei ist es allerding so, das der identische Fehler auf einem englischen und einen deutschen Windows, zumindest zur Zeit noch, als 2 Fehler gezählt wird.)

Danach gibt es die “Fixed in” Spalte: Die zeigt an, ab welcher Version der Baustatik das Problem behoben wurde. (Da steht im Bild immer 0.1, weil die Abbildung nur “bisher unbekannte” Probleme anzeigt.).

Danach kommt eine Eingabe, mit welcher Version der Baustatik der Fehler aufgetreten war, und wann er aufgetreten ist. Danach kommt eine Spalte in der ein paar Metadaten angezeigt werden – in der Abbildung sind das keine besonders spannenden. Dan gibt es eine Angabe über die verwendete Version von Windows (wichtig, weil bestimmte Fehler nur unter bestimmten Kombinationen von Windows und der Baustatik auftreten. ) Schließlich gibt es noch eine Angabe über die Speicherauslastung zum Zeitpunkt des Fehlers.

Klickt man auf eine solche Zeile, dann kann man sich im unteren Bereich noch ein paar zusätzliche Informationen über das Problem anzeigen lassen.

Damit setzen wir uns dann hin, und beseitigen das Problem: Danach kann man mit dem Interface den Fehlers als “beseitigt” markieren – der taucht dann in Zukunft nicht mehr in der Liste auf.

Ich habe heute (etwa gegen Mittag) die automatischen Updates für Version 1.65 angehalten und auch den Download-Bereich gesperrt. Der Grund dafür ist ein Fehler, der die Baustatik bei der Anzeige der globalen Faltwerksverformungen abstürzen ließ, wenn man das Programm auf einem Mehrkernsystem verwendete. Der Grund dafür ist bereits gefunden und ein Fix sollte in kürze (spätestens Morgen) in Form eines neuen Updates verfügbar sein.

Stellt sich die Frage: Warum haben unsere Testcases diesen Fehler nicht bemerkt? Zur Zeit laufen jeden Tag etwas über  1000 Dokumente im Rahmen der Testfälle durch, und für jedes Dokument werden alle verfügbaren Ergebnisse berechnet, und dann mit Referenzergebnissen verglichen: Dabei hätte rauskommen müssen, das die Faltwerksverformungen nicht mehr funktionieren.

Ist aber nicht rausgekommen. Das ist nicht schön, und darum habe ich mich auch auf die Suche nach dem Grund gemacht. Und der sieht so aus: Das Problem liegt gar nicht daran, das die Testfälle nicht funktionieren würden, denn die klappen tadellos. Die berücksichtigen allerdings eine Tatsache nicht, und das ist die, das in der neuen Version der Baustatik viele Stellen alle verfügbaren CPUs verwenden. Damit das “elegant” funktioniert, gibt es aber keine zentrale Stelle, an der einmalig alle möglichen Ergebnisse mit möglichst vielen CPUs berechnet werden. Statt dessen werden immer nur die Ergebnisse, die gerade in der Programmoberfläche zur Anzeige ausgewählt wurden berechnet. (Das ist übrigens auch der Grund, warum man zum Beispiel Bemessungsgruppen oder Überlagerungsregeln ändern kann, ohne das die komplette Berechnung verworfen wird.)

Die Parallelisierung findet dabei ebenfalls auf Basis der ausgewählten Ergebnisse statt: Werden zum Beispiel Balkenergebnisse angefordert, dann passiert das beispielsweise auf einer 4-Kern CPU mit 4 Kernen gleichzeitig.

Davon wissen die Testfälle aber nichts: Dort wird einfach über alle Elemente und dann über alle dafür verfügbaren Ergebnisse iteriert. Die Testfälle laufen schließlich automatisiert ab, es gibt also keinen Benutzer der die 1000 Dateien von Hand und durch anklicken eines Zielergebnisses berechnet.

Resultat: Ein Fehler im Multicore-Programmcode wird nicht “einfach so” automatisch erkannt.

Nachdem mir das nun bewusst ist werde ich wohl ein paar Überlegungen anstellen müssen, wie man sowas in Zukunft verhindert: Aber darüber denke ich nach, sobald Version 1.66 mit wieder funktionierenden Faltwerksverformungen fertig ist.

Ich hatte kürzlich ein paar Fälle, bei denen bei Kunden die “Echt” Ansicht nicht mehr ging: Das äußerte sich so, das man, wenn man versuchte so ein Fenster zu öffnen, einfach nur eine Fehlermeldung bekam. (Auch dann, wenn man ein Projekt öffnete, das ein geöffnetes Fenster mit einer “Echt” Ansicht enthielt.). Abgesehen von der Fehlermeldung konnte man aber einfach weiterarbeiten.

Ich untersuche das noch – denn der eigentliche Grund dafür ist mir unklar: Aus irgendwelchen Gründen scheint eine DLL die für dieses Fenster zuständig ist zu “verschwinden”. Wie dem auch sein mag: Man wird das los, indem man die “Baustatik” entweder “repariert” (Setup nochmal starten und “reparieren”) oder einmal deinstalliert und dann nochmals installiert.

Danach war die DLL (zumindest bei den Kunden mit denen ich gesprochen habe) wieder da, und die Fenster funktionierten auch wieder. Sobald ich den genauen Grund dafür kennen werden wir den natürlich beseitigen – und vermutlich auch nochmal ein neues Update veröffentlichen: Zumindest dann, wenn das Problem irgendwas damit zu tun hat…

Man sollte eigentlich annehmen, Installationsprogramme sind einfach: Man kopiert halt die benötigten Dateien vom Medium in den Zielordner – fertig.

In der Praxis ist das aber leider nicht so einfach, denn es müssen eine ganze Menge weiterer Dinge getan werden. Im folgenden mal eine kleine Liste, was der neue Installer für die Statikprogramme so tut (aber keine vollständige).

• Vor dem installieren sicherstellen, das die richtigen Betriebssystem-Versionen vorliegen. (Also XP mit SP3, Vista mit SP1, etc.).
• Ebenfalls vor dem installieren sicherstellen, das er mit ausreichenden Rechten für die späteren Operationen ausgeführt wird.
• Nachsehen ob eine Vorgängerversion vorliegt, und die gegebenenfalls entfernen.
• Sicherstellen das alle benötigten Systemkomponenten vorhanden sind, und falls nicht, diese gegebenenfalls installieren. (Dazu gehört .Net 2.0, .Net 4.0, die Visual C++ Runtime, und noch ein paar Komponenten.) Dabei bei Bedarf auch einen Rechner-Neustart durchführen.
• Sicherstellen, das das Installationsmedium nicht beschädigt ist.
• Danach fragen, wohin installiert werden soll.
• Danach fragen, welche Verknüpfungen angelegt werden sollen.
• Jetzt werden dann tatsächlich ein paar Dateien kopiert. Allerdings nicht “einfach so”, weil sich diese bei der Demo- und der Vollversion ein bisschen unterscheiden.
• Dateitypen registrieren. Das ist dafür gut, das man im Explorer einfach auf .baustatik oder .S01-Dateien klicken und das zugehörige Programm starten kann.
• Verknüpfungen anlegen (Startmenü, Schnellstartleiste, Desktop…)
• Sicherstellen, das die Work&Cash Zeitdatenbank erhalten bleibt und die notfalls konvertieren.
• Lizenzdateien kopieren (die müssen gesondert behandelt werden, weil jeder Kunde eigene bekommt.)
• Passende Schreibrechte vergeben (zum Beispiel für die Beispieldateien).
• Datenbankeinträge in der Windows-Installer Datenbank hinterlassen, damit alles brav deinstalliert werden kann.

Im Download-Bereich gibt es im Wesentlichen zwei Downloads: Die allgemeingültige Datei, die unsere Software enthält und "personalisierte" Daten: Diese personalisierten Daten enthalten die Lizenzdateien der einzelnen Kunden. Jeder Kunde kann dadurch seine Lizenzen einfach runterladen, sofern die einmal verloren gegangen sind, oder für einen neuen Rechner benötigt werden.

Diese private Datei ist zur Zeit nicht verfügbar. Grund: Im Rahmen des neuen Installationsprogrammes gibt es auch ein neues Installationsprogramm für die Lizenzen - die bisher vorliegende Datei enthält aber das "alte" Installationsprogramm, und das kommt mit dem neuen Installer nicht klar. (Es geht zwar zunächst, führt aber unweigerlich zu einem späteren Zeitpunkt zu Problemen.).

Darum haben wir diese alten Dateien heute entfernt und sind dabei, jedem Kunden ein neues Download zur Verfügung zu stellen: Im Laufe der nächsten Woche sollten alle Dateien wieder zur Verfügung stehen.

Die Ursache dafür liegt darin, das das neue Installationsprogramm die Programme ein bisschen anders installiert als das alte. (Seit Version 1.59 werden die Xfemily-Programme zusammen mit der Baustatik installiert und nicht mehr von einem separaten Installationsprogamm.)

Der Ordner „DIE Anwendungen“ wird vom neuen Programm nicht entfernt, weil er möglicherweise Kunden-Daten enthalten könnte. Sofern da keine Daten drin sind, kann man den Ordner einfach löschen. (Gleiches gilt für die „roten“ DIE-Icons auf dem Desktop, sofern die da sind.).

Das neue Installationsprogramm fragt (im ersten Fenster) nach, ob ein Desktop-Icon für die Programme angelegt werden soll. Wenn man diese Option einschaltet, wird ein Ordner auf dem Desktop angelegt, in dem sich passende Links zu den „alten“ Programmen befinden. Wenn Sie dieses Icon nicht haben, können Sie folgendes tun:

Gehen Sie im Start-Menü nach „Start -> Alle Programme -> D.I.E. Anwendungen“. Klicken Sie dort mit der rechten Maustaste drauf, halten Sie die Taste gedrückt, und ziehen Sie die Maus dann auf den Desktop. Lassen Sie die Maustaste dann los und wählen Sie aus dem daraufhin angezeigten Menü den Befehl „hierher kopieren“.  Danach haben Sie wieder einen Ordner mit funktionierenden Links zu den Xfemily-Programmen.

Bekanntes Problem: Ein Programm zeigt eine Fehlermeldung an, aber die ist nicht wirklich aussagekräftig, sondern enthält nur einen Text der Art "Irgendwas ging nich. Sorry.". Warum passiert sowas? Die einfache Antwort: Der Programmierer war faul, hatte zu wenig Zeit, oder hat nicht wirklich damit gerechnet, das an der betroffenen Stelle im Program irgendwas schief gehen könnte.

Ein anderer Grund ist der, das die Dinge manchmal einfach wirklich kompliziert werden können - und aus Zeitgründen dann in der Tat nicht alle möglichen Fälle abgehandelt werden. Die Liste der Dinge die an verschiedensten Stellen schiefgehen können ist bsiweilen überraschend lang. Das viel mir heute mal wieder auf, als ich ein Problem mit der PDF-Ausgabe untersucht habe.

Wenn man mit der Baustatik in ein PDF druckt, dann kann folgendes schiefgehen:

• Es gibt überhaupt nichts auszugeben, weil das in der Ausgabesteuerung so eingestellt ist
• Es gäbe zwar was auszugeben, das geht aber nicht, weil die zugehörige Berechnung nicht durchgeführt werden kann
• Es gäbe zwar was auszugeben, aber bei der Berechnung geht der Speicher aus
• Die Stil-Datei fehlt
• Die Stil-Datei ist zwar da, aber kaputt
• Die Stil-Datei ist zwar da und OK - aber ein darin eingetragenen Font liegt auf dem System nicht mehr vor
• Die Briefpapier-Datei (ist nicht da, ist kaputt, enthält Bilder die es nicht [mehr] gibt)
• Beim erzeugen eines der Bilder im Ausdruck geht der Speicher aus
• Beim konvertieren eines der Bilder in S/W geht der Speicher aus
• Beim erzeugen des echten PDF-Datei geht der Speicher aus
• Es gibt zwar genug Arbeitsspeicher, aber am Speicherort für die PDF-Datei gibt es keinen Platz mehr auf der Festplatte
• Die Installation ist defekt und eine der verwendeten DLLs fehlt oder hat die falsche Version (Ist echt schon vorgekommen :-) )
• Die eingestellten Ränder führen dazu, das kein Platz mehr für den Ausdruck ist
• Das eingestellte Hintergrund-Bitmap fehlt
• Das eingestellte Hintergrund-PDF fehlt
• Das Hintergrund-PDF ist zwar da, aber kein PDF
• Das Tool zum anbringen von Hintergrund-PDFs ist nicht (oder falsch) installiert
• Die Konfiguration fürs Hintergrund-Tool stimmt nicht
• Das zu erzeugenden PDF gibts unter diesem Namen schon - kann aber nicht überschrieben werden, weil es im Adobe Reader nicht geöffnet ist
• Das fertige PDF kann nicht angezeigt werden, weil der Adobe Reader nicht installiert ist

... und ich habe mit Sicherheit noch ein paar Dinge vergessen. Das sind dann die, wo die "komische" Fehlermeldungsbox kommt. Sorry. :-)