Blog Home  Home Feed your aggregator (RSS 2.0)  
HP's Blog - DotNetNukeEntwicklung
Hans-Peter Schelian's Weblog
 
# Wednesday, July 22, 2009

Wenn man die Source Version von DotNetNuke Version 4.09.04 in Visual Studio ausführt und als Browser den Internet Explorer 8 einsetzt, kommt es beim überfahren der Menüs (Admin und Systemmenü) mit der Maus zu folgendem Fehler:

image

Dieser Fehler tritt in der Datei dnn.dom.positioning.js auf.

Die Zeile in welcher der Fehler auftritt lautet:

oIFR.style.zIndex=iIndex-1
Was geschieht ist, dass in der Variablen iIndex anstelle eines Wertes, das Wort “Auto” enthalten ist. Wenn nun versucht wird von dem String “Auto” den Wert 1 abzuziehen, kommt es natürlich zu einem Fehler.

Ich habe eine Lösung gefunden, die für mich funktioniert und nicht die Zeile einfach auskommentiert.

Die Lösung sieht wie folgt aus:

Ich füge am Ende der Datei dnn.dom.positioning.js die Funktion IsNumeric ein:

function IsNumeric(sText)

{
   var ValidChars = "0123456789.";
   var IsNumber=true;
   var Char;

 
   for (i = 0; i < sText.length && IsNumber == true; i++) 
      { 
      Char = sText.charAt(i); 
      if (ValidChars.indexOf(Char) == -1) 
         {
         IsNumber = false;
         }
      }
   return IsNumber;
   
   }

Und verwende diese Funktion wie folgt um den Inhalt der Variable iIndex zu prüfen und im Falle das darin kein numerischer Wert enthalten ist, führe ich die Subtraktion nicht aus.

Anstelle der Zeile (250) mit dem Inhalt oIFR.style.zIndex=iIndex-1;

füge ich nachfolgende 4 Zeilen ein, das sieht dann so aus:

if (IsNumeric(iIndex))
    oIFR.style.zIndex = iIndex - 1;
else
    oCont.style.zIndex = 1;

Nun einfach die Datei dnn.dom.positioning.js speichern und auch Fehlerfrei mit dem IE 8 und der Source Version von DotNetNuke arbeiten.

DotNetNuke | Entwicklung
Wednesday, July 22, 2009 8:52:05 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]  
Autor: Hans-Peter Schelian  |  Trackback
# Tuesday, July 21, 2009

Wenn man versucht die Source Version von DotNetNuke 4.09.04 in Visual Studio 2008 zu öffnen und anschließend zu übersetzen, kommt es zu folgender Fehlermeldung:

Fehler	1	Datei "Controls\AJAX\bin\System.Web.Extensions.dll" kann nicht in "..\Website\bin\System.Web.Extensions.dll" kopiert werden. Ein Teil des Pfades "Controls\AJAX\bin\System.Web.Extensions.dll" konnte nicht gefunden werden.	C:\dnn494\Library\DotNetNuke.Library.vbproj	987	5	DotNetNuke.Library

Das Problem entsteht dadurch, dass versucht wird nach dem Übersetzungslauf die Datei System.Web.Extensions.dll aus dem Verzeichnis Controls\AJAX\bin\ in das BIN Verzeichnis von DotNetNuke zu  kopieren.

Dies ist aber gar nicht notwendig, da sich die Datei System.Web.Extensions.dll im GAC befindet.

Um den Fehler zu beheben, kann man die Datei DotNetNuke.Library.vbproj im Library Verzeichnis von DotNetNuke mit einem Texteditor öffnen, und nach dem Eintrag

<Copy SourceFiles="Controls\AJAX\bin\System.Web.Extensions.dll" DestinationFolder="..\Website\bin\" />

suchen, der Steht normal in der Zeile 987.

Diese Eintrag entfernt man und speichert anschließend die Datei ab.

Wenn man nun das Source Projekt mit Visual Studio öffnet und übersetzt sollte das Problem gelöst sein.

DotNetNuke | Entwicklung
Tuesday, July 21, 2009 10:23:55 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [1]  
Autor: Hans-Peter Schelian  |  Trackback
# Thursday, February 12, 2009

Nachdem man, Vorausgesetzt man hat das DotNetNuke Starterkit installiert, mit Visual Studio 2008 eine neue Webseite “DotNetNuke Application Framework” erstellt und konfiguriert hat, kommt es dazu (eventuell kommt es auch nur in bestimmten Fällen dazu), dass nach dem ersten Aufruf der fertig eingerichteten Webseite beim nächsten Start (Kompilierung) folgende 6 Fehler in Visual Studio angezeigt werden und die Webseite nicht mehr aufgerufen werden kann:

Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.fcklinkgallery" konnte nicht geladen werden.	Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.fckCSS" konnte nicht geladen werden Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.FckHtmlEditorOptions" konnte nicht geladen werden.	Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.fckinstanceoptions" konnte nicht geladen werden.	Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.fckimagegallery" konnte nicht geladen werden.	Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.fckStyles" konnte nicht geladen werden.

Da ich an dieser Stelle keine umfangreiche Abhandlung über die Gründe dieses Problems halten möchte folgt hier einfach kurz und knapp ein Workaround.

Man kopiert die Datei “DotNetNuke.FckHtmlEditorProvider.dll” aus dem BIN\Provider Verzeichnis der DotNetNuke Installation in das BIN Verzeichnis der DotNetNuke Installation.

Nun einfach das Projekt neu übersetzen “Webseite erstellen” – Fertig !!!!

Dieser Workaround trifft auf folgende Konfiguration zu:

  • Windows XP SP3
  • Visual Studio 2008 SP1
  • DotNetNuke Version 5.00.00
  • FckHtmlEditorProvider Version 2.0.2.1
DotNetNuke | Entwicklung
Thursday, February 12, 2009 2:55:25 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [0]  
Autor: Hans-Peter Schelian  |  Trackback
# Monday, November 05, 2007

Auch wenn wir bereits seit vielen Monaten eigentlich nur noch über DotNetNuke 4.X (ja schon bald über die Version 5.X) reden, sind noch viele Installationen unter den Versionen 3.X vorhanden.

Viele dieser Installationen werden wohl auch noch lange Zeit stabil und sicher weiter betrieben werden.

Nun gibt es aber immer häufiger das Problem, dass Menschen die mit diesen Portalen arbeiten auch den Internet Explorer Version 7 einsetzen.

Nun kommt es bei der in DotNetNuke verwendeten Version des FTB Texteditors zu einer Unverträglichkeit mit dem IE 7. Dies führt dazu, dass anstelle des komfortablen Editors nur einfach ein freies einfaches Textfeld zur Eingabe zur Verfügung steht.

Entweder man stellt den Provider auf den FCK Editor, den neuen Standardeditor, um oder man kann wie nachfolgend beschrieben, dass Problem lösen.

Abhilfe kann man hier ganz einfach schaffen indem man auf einen, bereits seit langem verfügbaren, angepassten Provider zugreift.

Advanced FTB Provider Version 3.2.0

Einfach herunterladen, den Inhalt des ZIP Files entpacken und dann die beiden Verzeichnisse BIN und Providers in das Root Verzeichnis der DotNetNuke 3.X Installation kopieren.

Getestet ist das mit DNN 3.1.X. und DNN 3.2.X mit DNN 3.3.X sollte es aber auch funktionieren.

Einfach vorher das BIN und Providers Verzeichnis sichern, dann kann nichts passieren. Wenn es wirklich einen Fehler geben sollte nachdem man den Advanced FTB Provider installiert hat, kan man einfach die beiden Verzeichnisse wieder zurück kopieren.

Der Grund warum der von mir veröffentlichte Provider das Problem mit dem IE 7 löst, liegt daran, dass in dem Provider eine aktuellere Version des FTB Editors integriert ist.

DotNetNuke | Entwicklung
Monday, November 05, 2007 8:52:45 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [1]  
Autor: Hans-Peter Schelian  |  Trackback
# Tuesday, October 23, 2007
Welches Format aus welcher CSS Datei wird wann und vor welcher berücksichtigt?

Diese Frage möchte ich mit diesem Beitrag ein wenig näher erläutern.

Hier die Reihenfolge in welcher die CSS Dateien von DotNetNuke verarbeitet werden:
  1. module.css der jeweiligen Module auf der Seite werden geladen (wenn Module eigene CSS Dateien haben).
  2. default.css aus dem Verzeichnis [DNNRoot]\Portals\_default
  3. skin.css aus dem Skin Verzeichnis. Im Beispiel den DNN-Blue Standard-Skin ist das [DNNRoot]\Portals\_default\Skins\DNN-BLUE
  4. container.css aus dem Container Verzeichnis. Im Beispiel des DNN-Blue Containers ist das [DNNRoot]\Portals\_default\Containers\DNN-BLUE
  5. portal.css aus dem Portal Verzeichnis. Im Beispiel des Standard-Portals nach der Installation von DotNetNuke ist das [DNNRoot]\Portals\0
Was wenn nun gleiche Klassen in verschiedenen CSS Dateien unterschiedlich deklariert sind?

DotNetNuke macht keinen Gebrauch von der Möglichkeit sich ergänzender externer CSS Dateien, sondern die CSS Dateien werden von DotNetNuke alle in einer bestimmten bereits oben erwähnten Reihenfolge geladen.

Der Gewinner dabei ist, die Definition einer CSS Klasse in der letzten CSS Datei in welcher die Definition vorgenommen wurde.

Ein einfaches Beispiel:

für H2 wurde in der container.css folgendes definiert:

H2 {
  
FONT-WEIGHT: normal;
  
FONT-SIZE: 20px;
  
COLOR: black;
  
FONT-FAMILY: Tahoma, Arial, Helvetica
  
}

nehmen wir weiter an dass in der portal.css auch das H2 Attribut definiert ist und zwar wie folgt:

H2 {
  
FONT-WEIGHT: bold;
  
FONT-SIZE: 16px;
  
COLOR: red;
  
FONT-FAMILY: Tahoma, Arial, Helvetica
  
}

Dann wird die Ausgabe einer in H2 eingeschlossenen Tags in Roter Fetter Schrift in Schriftgröße 16px in unserem Browser dargestellt.

Hier so wird es aussehen !

und nicht so!

Der Grund dafür ist, dass die letzte Definition in der Reihenfolge der verwendeten CSS Dateien immer als gültig angewendet wird

DotNetNuke | Entwicklung
Tuesday, October 23, 2007 8:36:24 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]  
Autor: Hans-Peter Schelian  |  Trackback
# Saturday, July 02, 2005

Bei der Programmierung von DotNetNuke Modulen gibt es ja wie allseits bekannt die freie Wahl der .NET Programmiersprachen.

Die beiden beliebtesten Sprachen zur Programmierung von DotNetNuke Modulen sind wohl VB.NET und C#.

Bei der Programmierung von User Controls sind jedoch obwohl beides .NET Programmiersprachen sind die Sprachspezifischen Eigenschaften wie zum Beispiel der Unterschied zwischen Groß und Kleinschreibung bei C# im Gegensatz zu VB.NET zu berücksichtigen. Das dies aber nicht die einzigen Unterschiede sind wird spätestens dann ganz deutlich wenn man versucht ein in VB.NET erstelltes User Control als Vorlage für ein C# User Control zu verwenden.

Schauen wir uns das doch einmal am Beispiel des Moduls Event, das ja Bestandteil des Core Produktes DotNetNuke ist, einmal etwas näher an.

Hier der Auszug aus der Events.ascx (mit VB.NET Codebehind)

<TR>

<TD id=colIcon vAlign=top align=center width='<%# DataBinder.Eval(Container.DataItem,"MaxWidth") %>' rowSpan=3 runat="server">

<asp:Image id=imgIcon runat="server" Visible='<%# FormatImage(DataBinder.Eval(Container.DataItem,"IconFile")) <> "" %>' 
ImageUrl='<%# FormatImage(DataBinder.Eval(Container.DataItem,"IconFile")) %>' 
AlternateText='<%# DataBinder.Eval(Container.DataItem,"AltText") %>'> </asp:Image></TD> <TD> <asp:HyperLink id=editLink runat="server" Visible="<%# IsEditable %>"
NavigateUrl='<%# EditURL("ItemID",DataBinder.Eval(Container.DataItem,"ItemID")) %>'> <asp:Image id="editLinkImage" ImageUrl="~/images/edit.gif" Visible="<%# IsEditable %>"
AlternateText="Edit" runat="server" resourcekey="Edit"/> </asp:HyperLink> <asp:Label id=lblTitle text='<%# DataBinder.Eval(Container.DataItem,"Title") %>' Cssclass="SubHead" Runat="server"> </asp:Label></TD> </TR>

Unsere besondere Aufmerksamkeit müssen wir dabei vor allem auf die Funktionen DataBinder.Eval() und EditURL() lenken.

Schauen wir uns Diese Syntax am folgenden Beispiel etwas näher an:

Visible='<%# FormatImage(DataBinder.Eval(Container.DataItem,"IconFile")) <> "" %>'

Mit dieser Zeile wird (in VB.NET ) erreicht dass nur wenn ein IconFile vorhanden ist das Control sichtbar ist, sonst wird der Wert Visible auf false gesetzt

Wenn wir eine solche Zeile in einem User Control einsetzen, welches mit C# zusammenarbeiten soll, dann ergeben sich gleich mehrere Problem (Fehlermeldungen während der Programmausführung, nicht beim übersetzen)

Als erstes wird in C# der Ausdruck nicht als If Ausdruck ausgewertet, da er nicht in () eingeschlossen ist.

Also muss das ganze auf jeden Fall schon mal so aussehen:

Visible='<%# (FormatImage(DataBinder.Eval(Container.DataItem,"IconFile")) <> "") %>'

Zu beachten hierbei sind die Klammern am Anfang und Ende der Auswertung

(FormatImage(DataBinder.Eval(Container.DataItem,"IconFile")) <> "")

Jetzt würden aber noch immer Laufzeitfehler entstehen, da C# bei der Typ Auswertung wesentlich kleinlicher (Gott sei Dank) ist, als dies VB.NET ist.

Das nächste Problem liegt in der Behandlung eines Stringvergleiches. in VB.NET ist der Vergleich string1 <> string2 ein gültiger Vergleich. In C# nicht, also müssen wir einen gültigen Vergleich für C# nehmen, der sieht dann so aus: string1 != string2.

Danach muss unser Ausdruck wie folgt aussehen:

Visible='<%# (FormatImage(DataBinder.Eval(Container.DataItem,"IconFile")) !="") %>'

Wenn Sie nun Denken, dass es nun funktioniert, muss ich Sie leider enttäuschen.

DataBinder.Eval() gibt als Datentyp ein abstraktes Objekt zurück, nun versuchen Sie mal einen Vergleich eines Objekt Datentyps mit "" einem String, das wird C# nicht zulassen.

Also bleibt uns nichts weiter übrig, als das Objekt zu einem String umzuwandeln.

Die Umwandlung können wir wie folgt vornehmen:

DataBinder.Eval(Container.DataItem,"IconFile").ToString()

Somit sieht unser Ausdruck nun wie folgt aus:

Visible='<%# (FormatImage(DataBinder.Eval(Container.DataItem,"IconFile").ToString()) !="") %>'

Der nun hier dargestellte Ausdruck ist nun C# konform und wird keinen Laufzeitfehler mehr erzeugen.

Schauen wir uns nun noch ein zweites Problem unseres Beispiels an:

<asp:HyperLink id=editLink runat="server" Visible="<%# IsEditable %>" 
NavigateUrl='<%# EditURL("ItemID",DataBinder.Eval(Container.DataItem,"ItemID")) %>'>

Der hier dargestellte Ausdruck ist der typische Code für den Hyperlink, der aus dem Anzeige Control das Edit Control aufruft.

Der nicht C# konforme Teil dieses Ausdrucks ist nachfolgend dargestellt:

NavigateUrl='<%# EditURL("ItemID",DataBinder.Eval(Container.DataItem,"ItemID")) %>'

Wenn wir das bisherige aus diesem Artikel anwenden, dann wissen wir dass wir das aus dem DataBinder.Eval() zurückgegeben Objekt in einem String umwandeln müssen.

So das unser Ausdruck wie folgt aussieht:

NavigateUrl='<%# EditURL("ItemID",DataBinder.Eval(Container.DataItem,"ItemID").ToString()) %>'

Wie ich am Anfang schon bemerkt habe berücksichtigt C# im Gegenteil zu VB.NET die Groß und Kleinschreibung, und somit haben wir mit dem Aufruf der Funktion EditURL ein Problem, da diese in Wirklichkeit eigentlich EditUrl heißt.

Also ändern wir den Ausdruck wie folgt ab:

NavigateUrl='<%# EditUrl("ItemID",DataBinder.Eval(Container.DataItem,"ItemID").ToString()) %>'

Mit dem Wissen dieser notwendigen Änderungen wenn Sie ein User Control in C# verwenden möchten, was eigentlich für VB.NET konzipiert war, können Sie nun die notwendigen Änderungen in User Controls vornehmen so dass diese dann in einem C# DotNetNuke Module verwendet werden können.

Entwicklung | C# | VB
Saturday, July 02, 2005 8:35:04 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [1]  
Autor: Hans-Peter Schelian  |  Trackback
Copyright © 2010 Hans-Peter Schelian - Schelian IT Beratung. All rights reserved.