Die Zeitspanne “Tick”

Ich arbeite jetzt ja seit Wochen wieder mehr mit ASP.net, da kommt man schon auf nette Sachen drauf 😉 Leider bin ich einfach zu lusch um das immer zu posten, trotzdem hier mal ein kleiner Beitrag zur Zeiteinheit Tick

Im .Net Framework folge die Zeitmessung in Einheiten zu 100 Nanosekunden, dem sogenannten Tick. Start dieser Zeitmessung war der 1.1.00001 und die Anzahl der Ticks seit Beginn dieser Zeitrechnung können in einer long Variable gespeichert werden. Somit sollt sich eine Zeitrechnung bis zum Jahre 9999 ausgehen.

Was aber nun interessanter ist, wie kommt man zu den aktuellen Ticks bzw. wie kann man Ticks in ein Datum / Zeit Format zurückrechnen?

Aktuelle Zeit:
Console.WriteLine(DateTime.Now.Ticks);
Ticks in Datum / Zeit verwandeln:
DateTime actualDate = new DateTime(631452984963219664);
Console.WriteLine(actualDate.ToString());

Ausgabe:
30.12.2001 08:41:36

Converting Web-Site Projects to Web-Application Projects using VS2005

Nach langem hin und her hab ich mich entschieden das für die Firma entstandene Web-Site Project in ein Web-Application Project (welches man als Plugin für VS2005 nachinstallieren muss) zu konvertieren. Warum ich das gemacht habe werd ich bei Zeiten einmal erläutern.

Doch für alle die dies auch vorhaben hier einie Links und Tipps für ein schnelleres Konvertieren.
Zu aller erst liest man sich mal die Site “Visual Studio 2005 Web Application Project” durch. Hier wird schon vieles erklärt.

Auch das Thema Namespaces wird kurz angerissen, leider nur für Class Files für die es klar ist, dass hier Namespaces angegeben werden müssen. Was ich zum Beispiel vergessen habe, waren auch die Namespaces bei den ASPX oder ASCX Files anzugeben und dort nicht nur im CodeBehind Teil, sondern viel mehr im HTML Part. Hier gehört für die Property Inherits auch jedesmal der Namespace vorne angefügt. Sollte man nicht genau wissen wie dieser heißt, einfach eine leere Seite anlegen und von dort abschreiben.

Die Designer Files welche auch jeder ASP.Net Datei beiligen nicht vergessen auch hier gehören für UserControls auch die Namespaces importiert oder einfach vor dem Namen des UserControls angefügt.

Danach sollten die Fehler schon um einiges weniger sein – was noch passieren kann ist, das eine nette “System.Security.SecurityException” auf euch wartet. Hier wurde ich in der MSDN fündig, einfach auf der lokalen Maschine bzw. der Maschine auf jener der WebServer läuft die nötigen Schritte durchführen.

Aja und der wichtigste Teil – nicht vergessen bei Typed Datasets im XSD Schema alle Connection Strings auf den neu entstandenen abändern. Sonst ärgert man sich grün und blau.

Der bessere Include

Andreas Rauch:

Kennen Sie den schon…? Es war einmal ein . Wers benutzt weiß, daß das Include File immer geladen wird und zwar komplett.  Nicht, daß es schlecht gewesen wäre, aber wesentlich komfortabler wäre es doch, wenn man bestimmen kann, was wann geladen wird. Dazu gibt es unter dem IIS 5 oder ASP 3 zwei wichtige neue Befehle (die es in sich haben) …

Der Artikel “Der besser Include” erklärt kurz und bündig wie es besser gehen kann und vor allem warum 😉

Problem beim Updaten eines GridViews bei Verwendung einer ObjectDataSource

Gestern hab ich mich mind. 2 Stunden mit der Error: “… could not find a non-generic method …” abgeärgert bis ich dann zu folgenden Blogeintrag gelangt bin, der dies auf perfekte Art und Weise erklärt und nun geht auch wieder alles 😉

Issues updating a DataGrid row when using an ObjectDataSource and DataSet

I have been having issues using the DataGrid’s built in Edit and Update features when the DataGrid was using the ObjectDataSource.  The code generated by the IDE was causing a “could not find a non-generic method” error when committing the changes to an edited row in a DataGrid control.

Here is my analysis and solution:

The root of the problem has to do with the TableAdapter and its configuration wizard within the DataSet.xsd.

By default, Visual Studio will enable the “Refresh the data table” option on the “Advanced Options” dialog accessible via a button in the lower left corner of the “Enter a SQL Statement” page of the TableAdapter Configuration Wizard.  If the “Refresh the data table” checkbox is checked, it will append a SELECT statement to the end of the UPDATE and INSERT statements to “retrieve identity column values, default values, and other values calculated by the database” of the row that was just updated.  To do this, it needs the “<PKField>” in addition to the “original_<PKField>” to be sent from the DataGrid control .  When the column property for the primary key is set to ReadOnly = True, the DataGrid will not include the “<PKField>” in its Parameters collection during the Update method call.  (note: <PKField> is the field name of your primary key as in “ID”, or “original_ID”)

When ever we Update from the DataGrid, the “original_<PKField>” will be sent.  This is good. It’s the additional requirement of sending the “<PKField>” for the additional SELECT statement at the end of the Update query that is messing up our DataGrid’s functionality.

In other words, if the DataGrid is bound to the methods in the TableAdapter via an ObjectDataSource, and if the primary key column of the DataGrid is set ReadOnly=True, the DataGrid control will not pass the primary key to the Update and Insert methods of the TableAdapter even though those methods require it.  Instead, it will only include the “original_<PKField>”which it will use to locate the correct record to update.

Disabling the “Refresh the data table” checkbox on the “Advanced Options” dialog during configuration of the TableAdapter makes the most sense to me and has the least impact on design and functionality while still allowing the IDE to generate most of the code.

Some people have suggested changing the OldValuesParameterFormatString of the ObjectDataSource from “original_{0}” to simply “{0}”, but this then causes the “original_<PKFieldName>” (i.e. “original_ID”), which is still there in the parameters collection of the ObjectDataSource, to never be initialized (i.e. null will be passed in the Parameters collection during the Update and Insert) by the GridView, resulting in the “Value cannot be null” error if your field cannot be null.  Some people benifited from the OldValuesParameterFormatString fix, but I believe it was because their fields could be null.

Explicite Localization and Master Pages in ASP.Net 2.0

Localization mit ASP.Net 2.0 in Verbindung mit dem Visual Studio 2005 stellt kein großes Problem dar. Einzig und allein die Entscheidung ob man implizite oder explizite Localization verwenden soll könnte zum Problem werden 😉

Mein Problem bei der Nutzung von expliziter Localization in Verbindung mit Master Pages war, dass es nicht erlaubt ist die Settings für Culture und UICulture in der Page directive zu setzen. Die Möglichkeit dieses Einstellungen bei jeder einzelnen ASP-Site zu tätigen wäre möglich, aber in meinem Fall wenig praktikabel.

Die Lösung ist folgenden Eintrag in die web.conf zu setzen um so die ganze WebApplication für die Localization vorzubereiten.

 

 

 

Und für alle die zu faul sind ihren Browser immer und immer wieder zwischen der einen und der anderen Sprache umzustellen gibt es die Möglichkeit programmatisch die Sprach und die Kultur zu ändern.

Einfach in der Page_Load Methode (oder wo jeder will) folgende Zeile einfügen:

System.Threading.Thread.CurrentThread.CurrendCulture = new System.Globalization.CultureInfo(“en-GB”, false);

Auslesen der CulturInfo schafft man mit dieser Zeile:

System.Globalization.CulturInfo.CurrentCulture.Name;