Namo  WebEditor  Info
HomeWebEditorFreeMotionTrickkisteForumLinks
 

Namo WebEditor

Die Geschichte 
WebEditor 3 
WebEditor 4 
WebEditor 5 
WebEditor 6 
Features - WE4 
Features - WE5 
Features - WE6 
 

 

 

Bug-Listen aller Versionen auf einem Blatt

Es gehört zum Allgemeinwissen der Computeranwender, dass jede Software Fehler enthält. Namo WebEditor macht da keine Ausnahme - im Gegenteil! Da ist es gut, wenn man diese Programmfehler kennt. Sicher würde es uns und die Firma Namo einen großen Schritt voran bringen, wenn sie selbst eine komplette Bugliste (ggf. mit Termin für ein Bugfix) veröffentlichen würde. Da dies aber nicht der Fall ist (wiederum ganz im Gegenteil!), zeige ich hier zumindest die Fehler auf, die ich selbst in Namo WebEditor gefunden habe oder die Ihr mir im Forum berichtet habt (vielen Dank).

Die Programmierer von SJ-Namo haben sich in den letzten 5 Jahren enorm viel Zeit bei der Weiterentwicklung gelassen. Da sollte man neben einigen Programmverbesserungen wohl auch eine weitgehende Fehlerbeseitigung erwarten können. Als erstes habe ich daher natürlich überprüft, welche der alten Bugs noch 'funktionieren'... Aber bei der Gelegenheit stieß ich auch wieder auf neue Bugs und Unzulänglichkeiten.

Wenn man diese Fehler hier so komprimiert veröffentlicht, dann könnte natürlich der Eindruck entstehen, dass die Software gar nichts taugt. Bitte verteht dies nicht derart falsch. Wie eingangs gesagt, hat jedes große Softwareprojekt gewisse Fehler. Diese fallen (zumindest bei Namo WebEditor) aber nicht bei der täglichen Anwendung auf. Man stößt darauf, wenn man spezielle Dinge tun möchte oder - so wie ich - ganz gezielt nach Fehlern sucht. Tatsächlich ist Namo WebEditor ein sehr zuverlässiges Programm, das sich bei mir täglich bewährt.

Genug Vorgeplänkel - kommen wir nun zu den harten Fakten:

Schneller Sprung zu Version [ 9 | 8 | 2006 | 6 | 5.5 | 5.0 | 4 | 3 ]


Namo WebEditor 9

Neue Bugs:
Sind in Arbeit...

Text erscheint in Kürze...

Nicht behobene Bugs und Unzulänglichkeiten älterer Versionen:
  • Menübefehl "Externe Programme" hat keine Funktion mehr (ab Version 8)
  • Programmhilfe enthält Link zu einem Script bei einer verdächtigen externen Adresse! (ab Vers.8)
  • Fotoalbum: Miniaturansichten "mit einheitlicher Größe" werden verzerrt.
  • Fotoalbum - "Diashow": Mozilla/Netscape meldet Fehler wenn man die automatische Weiterschaltung nicht aktiviert (seit Version 6).
  • Fotoalbum "Framestil (1bis4)" funktioniert nach dem Publizieren nicht (ab 2006).
  • Excel-Tabellen-Import: Falsches Datumsformat (schon seit Version 5)
  • Skript-Assistent: kein deutsches Anzeigenformat für die Uhr (seit Version 6)
  • Im Site-Manager ist die Sortierung der Dateien nach " Type" nicht möglich
  • Schlechte Darstellung von Listenpunkten bei großen Schriften
  • Update der Software über den Menübefehl [Hilfe    -    Namo  WebEditor-Updates] geht nicht. Update-Patches müssen stets manuell von Namo.com heruntergeladen werden.
  • Navigationsmenü 'Navigationsstruktur' verschwindet!
  • Flash-Navigation wird in Firefox nicht angezeigt (seit Version 6)
  • Übertriebene zwangsweise Kleinschreibung in XHTML
  • Selbst vermehrende und falsche Abschlusstags für Kommentare in XHTML
  • Zwangsweiser Zeilenumbruch im HTML-Quelltext nach ca. 470 Zeichen
  • Programmabsturz bei Verwendung des CSS-Attributes 'float' für Textobjekte
  • Hirnrissige Funktion beim Publizieren: "Auswahl aller geöffneten Dokumente mit nicht gespeicherten Änderungen" an Stelle der Funktion "Alle neuen oder geänderten Dateien auswählen" beim Publizieren.
Folgende Bugs von Namo 2006 sind nun behoben:
  • Beim Umbenennen von Navigationsnamen im Site-Manager sind jetzt auch Ä oder ß möglich.
  • In Layouttabellen ist jetzt ist auch die Auswahl mehrerer Layoutboxen gleichzeitig möglich
  • Backslash [\] im PHP-Code wird jetzt korrekt erkannt.
  • Kommentare im HTML-Code werden jetzt auch im XHTML-Format korrekt gespeichert ohne </!-->.
  • Die Verwendung von nicht vorhandenen Schriftarten führt nicht mehr zum Programmabsturz.

 

Schneller Sprung zu Version [ 8 | 2006 | 6 | 5.5 | 5.0 | 4 | 3 ]

Namo WebEditor 8

Neue Bugs:
Menübefehl "Externe Programme" funktioniert nicht

Zusätzlich zum Ribbonmenü kann man Symbolleisten einblenden. So ist u.a. eine Symbolleiste "Werkzeuge" vorhanden. Diese enthält den Befehl "Externe Programme". Schaut man dort hinein, dann ist diese entweder leer oder man findet dort alte Bekannte aus Namo-2006-Zeiten. Wie dem auch sei - diese externen Programme sind außer Funktion. Kommt man auf die geniale Idee, diese FDunktion in der Namo-Hilfe zu suchen, dann stößt man tatsächlich auf einen Eintrag, der behauptet, man könne die Externen Programme einstellen und findet dazu einen "Reiter" in den Einstellungen. Aber in der Navigation vom Einstellungen-Menü gibt es keine "Externe Programme".

Es hat den Anschein, als ob es ab Namo 8 keine externen Programmaufrufe mehr gibt. Nur haben die Programmierer es versäumt, diesen Menüpunkt aus der Menüauswahl heraus zu nehmen und die Programmhilfe entsprechend zu aktualisieren. Vielleicht handelt es sich auch um einen Bug. Die Anfrage beim Namo-Support läuft noch...

Album-Assistent: Miniaturansichten mit "einheitlicher Größe" werden verzerrt.
- Die Option "Proportionen beibehalten" funktioniert offenbar nicht.

Wählt man im Fotoalbum-Assistenten einen Albumstil, der Miniaturbilder verwendet, also z.B. den Typ "Mehrfachansicht" und wählt man in den Miniaturoptionen eine "einheitliche Größe", dann setzt man normalerweise ein Häkchen bei "Proportionen beibehalten". Somit sollen die Miniaturen automatisch eingestellt werden, so dass sie ohne Verzerrung - also in korrekten Proportionen ausgegeben werden.

Leider funktioniert das ab Namo WebEditor 8 nicht mehr richtig. Man sieht es schon in der Vorschau des Assistenten - und tatsächlich: Bei der Ausgabe im HTML-Dokument werden grundsätzlich die Größenangaben ohne Berücksichtigung der Proportionen übernommen. Die Bilder erscheinen dadurch verzerrt.

Dabei werden die Miniaturren durchaus in der richtigen Größe erzeugt und gespeichert. Nur im HTML-Dokument werden leider die falschen Größenwerte verwendet.

Abhilfe: Man kann die Miniaturen von Hand nachbessern, indem man in den Bildeigenschaften der Minibildchen auf [Originalgröße wiederherstellen] klickt. Leider muss man diese Korrektur für jedes einzelne Minibild durchführen. Um das Problem von vorn herein zu umgehen, muss man auf die Einstellung "einheitliche Größe" im Albumassistenten verzichten und statt dessen auf die Verkleinerung mittels Prozentwert zurückgreifen. Außerdem macht es grundsätzlich Sinn, wenn man die Originalbilder zuvor bearbeitet und sie in einheitlicher Größe ablegt, statt die Berechnung und Veränderung der Bildgrößen dem Albumassistenten zu überlassen.

Programmhilfe erzeugt ständig einen öminösen Skriptfehler!

Beim Aufruf beliebiger Themen in der Programmhilfe wurde stets ein sehr ominöser Skriptfehler angezeigt. Demnach wird versucht, eine Skriptdatei "1.js" von der Adresse vntkr.com/img/btn/ zu laden! Derzeit wird diese Adresse nicht verwendet und somit kein Skriptfehler angezeigt. Da diese aber jederzeit und von jedermann wieder in Betrieb genommen werden könnte, besteht hier die Gefahr, sich einen Trojaner einzuhandeln. Die Hilfedatei muss also bereinigt werden. Die Programmentwickler haben davon aber Kenntnis genommen, als Namo 9 schon in der Mache war. Daher wird es für Namo 8 keinen Patch mehr geben. Anwender der Version 8 sollten daher dringend den Zugriff auf die URL vntkr.com blockieren. Mehr dazu in der Trickkiste.
 

Nicht behobene Bugs und Unzulänglichkeiten älterer Versionen:
  • Fotoalbum " Diashow", Mozilla/Netscape meldet Fehler wenn man die automatische Weiterschaltung nicht aktiviert (seit Version 6).
  • Fotoalbum "Framestil (1bis4)" funktioniert nach dem Publizieren nicht (ab 2006).
  • Excel-Tabellen-Import: Falsches Datumsformat (schon seit Version 5)
  • Skript-Assistent: kein deutsches Anzeigenformat für die Uhr (seit Version 6)
  • Im Site-Manager ist die Sortierung der Dateien nach " Type" nicht möglich
  • Schlechte Darstellung von Listenpunkten bei großen Schriften
  • Update der Software über den Menübefehl [Hilfe    -    Namo  WebEditor-Updates] geht nicht. Update-Patches müssen stets manuell von Namo.com heruntergeladen werden.
  • Navigationsmenü 'Navigationsstruktur' verschwindet!
  • Flash-Navigation wird in Firefox nicht angezeigt (seit Version 6)
  • Übertriebene zwangsweise Kleinschreibung in XHTML
  • Selbst vermehrende und falsche Abschlusstags für Kommentare in XHTML
  • Zwangsweiser Zeilenumbruch im HTML-Quelltext nach ca. 470 Zeichen
  • Programmabsturz bei Verwendung des CSS-Attributes 'float' für Textobjekte
  • Hirnrissige Funktion beim Publizieren: "Auswahl aller geöffneten Dokumente mit nicht gespeicherten Änderungen" an Stelle der Funktion "Alle neuen oder geänderten Dateien auswählen" beim Publizieren.
Folgende Bugs von Namo 2006 sind nun behoben:
  • Beim Umbenennen von Navigationsnamen im Site-Manager sind jetzt auch Ä oder ß möglich.
  • In Layouttabellen ist jetzt ist auch die Auswahl mehrerer Layoutboxen gleichzeitig möglich
  • Backslash [\] im PHP-Code wird jetzt korrekt erkannt.
  • Kommentare im HTML-Code werden jetzt auch im XHTML-Format korrekt gespeichert ohne </!-->.
  • Die Verwendung von nicht vorhandenen Schriftarten führt nicht mehr zum Programmabsturz.

 

Schneller Sprung zu Version [ 8 | 2006 | 6 | 5.5 | 5.0 | 4 | 3 ]

Namo WebEditor 2006

Einige Bugs und Unzulänglichkeiten aus Version 6 wurden nicht behoben
  • Netscape meldet Fehler bei Fotoalbum " Diashow" .
  • Firefox zeigt Flash-Navigationsleisten nicht an.
  • Ä oder ß nicht möglich beim Umbenennen von Navigationsnamen (Site-Manager)
  • Excel-Tabellen-Import: Falsches Datumsformat (schon seit Version 5)
  • Skript-Assistent: kein deutsches Anzeigenformat für die Uhr
  • Im Site-Manager ist die Sortierung der Dateien nach " Type" nicht möglich
  • Schlechte Darstellung von Listenpunkten
  • Update der Software über den Menübefehl [Hilfe    -    Namo  WebEditor-Updates] geht nicht. Update-Patches müssen stets manuell von Namo.com heruntergeladen werden.
  • Dateiliste beim Publizieren: Sortierung nach "Type" ist jetzt auch möglich.
     
Neue Bugs:
dieser bug wird durch den update-patch behoben
Album-Assistent: Diashow " Getrennte neue Fenster" :
Statt alles auszublenden, werden alle Fensteroptionen aktiviert.

Wählt man im Fotoalbum-Assistenten den Albumstil " Diashow" mit der Option " Getrennte neue Fenster" , dann erhält man eine Fensterauswahl. Dort kann man einzeln auswählen, ob die Symbolleiste, das Menü, die Statusleiste, und der Scrollbalken angezeigt werden und die Fenster skalierbar sein sollen. Will man alles deaktivieren, dann wird man alle Häkchen entfernen. Hat man das Album aber fertig erstellt, dann erlebt man eine Überaschung: Alle Fensteroptionen sind aktiviert! Man kann das Problem umgehen, indem man zumindest eine Fensteroption auswählt. Später kann man dann den HTML-Code nachbearbeiten und die noch aktive Fensteroption per Hand oder mittels Suchen/Ersetzen deaktivieren. Durch den kostenlosen Update-Patch wird das Problem behoben.
 

Album-Assistent: Albumtyp Framestil (1bis4):
Album wird auf dem lokalen Rechner noch korrekt angezeigt, aber nach dem Publizieren leeres Browserfenster - Firefox gibt dazu merkwürdige Fehlermeldung aus

Wählt man im Fotoalbum-Assistenten den Albumstil "Framestil1", "Framestil2" u.s.w, denn werden die Miniaturen und die großen Bilder jeweils in einem Iframe dargestellt. Und das Ganze wird außerdem noch in einem normalen Frameset angezeigt; das wiederum wird in ein Iframe gepackt...

Hoch kompliziert - aber auf dem eigenen Rechner funktioniert das prima. Nach dem Publizieren schaut der verdutzte Webmaster dann aber auf ein leeres Fenster! Mozilla Firefox einen Hinweis, der aber sehr merkwürdig klingt: "Firefox weiß nicht, wie diese Adresse geöffnet werden soll, da das Protokoll (d) mit keinem Programm verknüpft ist."

Schuld daran ist eine falsche Adressangabe für die Seiten, die in dem Frameset angezeigt werden sollen. Wenn man im Albumassistenten nichts anderes eingestellt hat, dann heißt das Frameset "FrameIndex_view.htm". Dieses enthält je ein Frame für die Vorschaubilder und das jeweilige große Bilder. Es wird aber jeweils auf den kompletten Pfad auf der eigenen Festplatte verwiesen. Also beispielsweise "d:\webseiten\projekt1\fotoalbum\album1\FrameView_view.htm" anstatt nur einfach "FrameView_view.htm". Damit kann kein Browser etwas anfangen. c:\ oder d:\ sind keine bekannten Protokolle. Es wird http://... erwartet oder einfach nur "FrameView_view.htm".

Wer sich genügend mit HTML auskennt, kann den Fehler von Hand im HTML-Quellcode des Framesets beheben. Für alle anderen wird das framegesteuerte Fotoalbum komplett nutzlos.
 


Layoutbox: Gleichzeitige Auswahl mehrerer Layoutzellen schlägt fehl

Wenn man mehrere Layoutzellen gleichzeitig auswählen will, um sie z.B. aneinander auszurichten, dann klappt das nicht. Jedenfalls nicht so, wie das (auch laut Handbuch) eigentlich gehen sollte, nämlich durch Anklicken der Layoutzellen bei gleichzeitigem Halten der Umschalt-Taste (Shift).

Workaround:
Verwende einfach die rechte Maustaste! Also [Shift]-Rechtsklick. Dann klappt es.
Durch den Rechtsklick klappt allerdings jedesmal auch das Kontextmenü auf. Das kann ganz schön nerven.
Hat man alle gewünschten Zellen ausgewählt, dann wählt man gleich die gewünschte Aktion aus dem noch offenen Kontextmenü aus. Benötigt man das Kontextmenü aber nicht, dann muss man es los werden. Dies geschieht mittels [Esc]-Taste. Danach kann man z.B. mit den Pfeil-Tasten die Layoutzellen alle miteinander verschieben. Mausaktionen dürften derweil aber schwer fallen, denn man kann ja nichts anklicken, ohne dass die Markierung gleich wieder aufgehoben wird. Hier kann man sich nur behelfen, wenn man das Kontextmenü einfach aufgeklappt lässt und sofort die gewünschte Aktion mit der Maus durchführt. Das kann recht fummelig werden.
 

Navigationsmenü " Navigationsstruktur" verschwindet!

Wenn man über Einfügen - Navigation > Navigationsstruktur ein Navigationsmenü eingefügt hatte und die Seite zu einem späteren Zeitpunkt nochmals zur Bearbeitung öffnet, dann erlebt man eine böse Überaschung: Namo 2006 hat sämtliche JavaScript Funktionen des Menüs aus dem HTML-Code rausgeschmissen und diese Änderung auch sofort abgespeichert. Es bleibt nur eine leere Ebene zurück, so dass einem nichts anderes übrig bleibt, als die leere Ebene zu löschen und die Navigationsstruktur erneut einzufügen. Doch wozu? Das hält eh wieder nur bis zum nächsten Öffnen der HTML-Seite. Außerdem haben ältere Mozilla- bzw. Netscapeversionen Probleme, das Menü anzuzeigen.
 


PHP-Code wird nicht erkannt, wenn er \" enthält

Beispiel:
< ?php
                echo " < div align=\" center\" > Hallo Welt< /div> "
?>

Dieser einfache Code wurde in Version 5 oder 6 noch einwandfrei erkannt und im Editor erschien das Platzhalter-Symbol [PHP]. Aber Namo WebEditor 2006, der ja ein verbessertes Syntax-Highlighting besitzen soll und daher für PHP und JavaScript-Fans besonders interessant erschien, hat damit nun ein Problem. Er erkennt die Zeichenfolge \" nicht mehr und verwirft den ganzen PHP-Code. Er zeigt nur noch das Symbol [?] - also ein unbekanntes Tag. Dadurch lässt sich der PHP-Code nicht aus dem Editor heraus bearbeiten, das Syntax-Highlighting im Quelltext funktioniert nicht ordnungsgemäß und es besteht die Gefahr, dass der PHP-Code von Namo WebEditor 2006 kaputt-korrigiert wird.
 

XHTML - Zwangsweise Kleinschreibung

In XHTML gelten strengere Regeln als in HTML 4. So sollen u.A. alle Tags und deren Attribute klein geschrieben werden. Namo WebEditor achtet automatisch darauf und korrigiert ggf. den Quelltext von XHTML-Dokumenten. Diese Autokorrektur ist leider nicht abschaltbar.
Leider - denn:   Namo WebEditor 2006 erkennt nicht die Attribut-Werte.

Beispiele:

    • Alternativtexte für Bilder
    • Link-Info-Texte (auch Quickinfo genannt)
    • Bildadressen (Bildpfade)
    • Links

Während man sich bei den ersten beiden ärgern mag, aber noch damit leben kann, ist es bei den Links und Bildadressen schon schwieriger. Insbesondere bei externen Links kann man sich die Schreibweise nunmal nicht aussuchen. Man kann somit keine Links zu Angeboten setzen, die Großbuchstaben enthalten. Hier hilft nur der Umweg über eine normale HTML4-Seite.
 

XHTML - Kommentare im Quelltext

Wiederum wird die strikte Befolgung des "wohlgeformten Quelltextes" zur Stolperfalle für Namo WebEditor 2006. Es darf ja keine ungeschlossenen Tags geben. Zu jedem <p> gibt es ein </p> und zu jedem <br> gibt es ein </br> - ach nein, dafür gibt es ja die Kurzform: <br/>.

Aber diese Regel gilt nicht für Kommentare. Die sehen auch in XHTML genau so aus wie in HTML, nämlich so:
<!-- Kommentar -->.

Namo 2006 erkennt das aber nicht und will ein Abschlusstag setzen. Der Kommentar sieht dann zunächst so aus:
<!-- Kommentar -->
</!-->
Und nachdem man ggf noch etwas im Quellcode geändert und wieder in den WYSIWYG-Modus umgeschaltet hat, fügt Namo gleich noch ein weiteres Abschlusstag ein:
<!-- Kommentar -->
</!--></!-->

So kann das glatt noch weiter gehen. Mit jedem Speichern aus dem HTML-Quelltext heraus wird eine weitere Sequenz </!--> nach jedem Kommentar eingefügt...
 

Ungewollter Zeilenumbruch im HTML-Quelltext

Sollte man aus irgend einem Grunde mal mehr als 470 Zeichen in eine Zeile des HTML-Quellcodes schreiben wollen, dann kann es sein, dass Namo WebEditor nach dem Umschalten zurück zum WYSIWYG-Mode bzw. nach dem Speichern diese Zeile in mehrere Zeilen aufgeteilt hat. Das passiert nicht, wenn man keine Leerzeichen verwendet hat. Und je nach dem, wie lang die letzte Zeichenkette ohne Leerzeichen ist, kann Namo auch mehr als 500 Zeichen pro Zeile erlauben. Dieser Effekt dürfte den meisten Anwendern gar nicht auffallen oder nicht stören. Aber wenn es mal unbedingt sein muss, dass 500 oder mehr Zeichen in einer einzigen Zeile verbleiben, dann ist das ärgerlich.

Aber Namo macht das nur, wenn man in den Bearbeitungsoptionen des Quelltextes " weiche Zeilenumbrüche" aktiviert hat. Dies dürfte sich eigentlich nur auf die Darstellung des Quelltextes im Bearbeitungsfenster auswirken, so dass man nicht mehr horizontal scrollen muss. ´Benötigt man also eine Mammutzeile, so muss man diese weichen Zeilenumbrüche. deaktivieren.
 

Publizieren: Automatische Auswahl der geänderten Dateien funktioniert nicht

Wenn man bei jeder Publikation sämtliche Dateien zum Server schickt, dann erzeugt man unnötigen Traffic und verschwendet je nach Datenmenge auch sehr viel Zeit. Sinnvoll ist es daher, nur die neuen und geänderten Dateien zu publizieren. In Namo WebEditor kann man zu diesem Zweck über das Menü "Bearbeiten" automatisch ganz bestimmte Dateien auswählen. Um nur neue Dateien zum Server zu schicken, verwendet man z.B. "Eindeutig lokale Dateien auswählen". Will man aber aus den bereits vorhandenen Dateien nur diejenigen auswählen, die man seit der letzten Publikation verändert hat, dann verwendete man "Geänderte Dokumente auswählen". Aber das Programm reagiert nicht. Auch ein Klick auf "Nicht übertragene Dateien auswählen" führt nicht zur gewünschten Markierung der neuen und geänderten Dateien.

Also ein weiterer Programm-Bug. Oder eigentlich eher ein Programmierer-Bug. Denn schaut man in die Programmhilfe, dann heißt es dort:

Besondere Auswahlbefehle

Im Publikationsfenster sind folgende
Befehle im Menü Bearbeiten immer verfügbar.

  • Alles auswählen: Wählt alle Dateien und Ordner aus.
  • Geöffnete Dokumente auswählen: Wählt alle in Namo WebEditor geöffneten Dokumente aus.
  • Geänderte Dokumente auswählen: Wählt alle geöffneten Dokumente mit nicht gespeicherten Änderungen aus.
  • Verknüpfte Dateien auswählen: Wählt alle Dokumente und Ressourcendateien aus, mit denen die aktuell markierten Dokumente verknüpft sind.
  • Nicht übertragene Dateien auswählen: Wählt alle Dateien aus, die während des letzten Upload oder Download nicht übertragen werden konnten.
  • Auswahl umkehren: Kehrt die aktuelle Auswahl um (die Auswahl der aktuell ausgewählten Elemente wird aufgehoben, und die aktuell nicht ausgewählten Elemente werden ausgewählt).

Man soll also die Dateien nicht speichern und im Editor geöffnet lassen, damit man sie über diesen Menpbefehl für den Upload markieren kann. Das ist absolut hirnrissig, aber genau so haben es sich wohl die Programmierer gedacht.

Abhilfe: Leider nicht möglich. Bei sehr großen Projekten rate ich dazu, ein anderes FTP-Programm zu verwenden. Bei mittleren Projekten versuche alle Dateien in einem Ordner zu halten und sortiere die Dateien vor dem Upload nach Datum. So kannst Du leicht erkennen, welche Dateien neueren Datums sind und diese dann entsprechend von Hand auswählen. Bei kleinen Projekten spare Dir die Mühe und publiziere einfach immer sämtliche Dateien. Dafür gibt es dann auch einen schnellen Befehl unter "Datei"/ "Gesamte Site publizieren".
 

Programmabstürze:
Schwierigkeiten mit eingeschränkten Benutzerkonten in Windows XP


Verwendet ein HTML-Dokument eine Schriftart, die im System nicht vorhanden ist, dann erscheint im Normalfall folgende Warnmeldung, sobald man die Seite mit Namo WebEditor 2006 im WYSIWYG-Modus öffnet:
die schriftart 'arial blue' wurde für eine temporäre nutzung registriert.
Läuft Namo WebEditor 2006 aber unter Windows XP mit einem eingeschränkten Benutzerkonto, dann klappt diese temporäre Schriftartregistrierung nicht. Die Folge: Namo WebEditor stürzt ab, sobald man die HTML-Datei im WYSIWYG-Modus öffnen will.
Nun mag man sich vielleicht fragen, wieso jemand eine nicht installierte Schriftart verwenden sollte. Aber das kann vorkommen, wenn man die Schriftart im HTML-Quelltext festlegt hat und sich dabei vertippt. In meinem Beispiel habe ich statt " Arial Black" einfach " Arial Blue" im HTML-Quelltext eingegeben. Als ich dann von " HTML" auf " Bearbeiten" umschalten wollte, stürzte Namo einfach ab. Genau so gut kann es vorkommen, dass man eine fremde HTML-Datei öffnen will und schier verzweifelt, weil Namo WebEditor auch in diesem Fall einfach abstürzt. Selbstverständlich sucht man dann nach fehlerhaftem HTML-Code. Dass es an der Schriftart liegt, darauf kommt man so schnell nicht!

Auch Namo WebCanvas reagiert allergisch auf eingeschränkte Benutzerkonten. Das Grafiktool lässt sich grundsätzlich nur starten, wenn man als Administrator bei Windows eingeloggt ist.
 

Probleme mit einigen manuellen Eingaben im HTML-Quelltext

Auf die CSS-Anweisung " float" reagiert Namo 2006 wohl empfindlich. Folgendes kleines HTML-Beispiel bringt Namo WebEditor unweigerlich zum Absturz:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
  <title>float-Test</title>
</head>
<body>
  <h1 style="width:300px; float:left; color:blue">&TEXT-LOGO</h1>
  <p style="font-size:120%">Nicht nur Bilder können vom Text umflossen werden.
Mit der CSS-Anweisung 'float' bringt man auch Absätze oder Überschriften dazu,
dass sie seitlich vom Text stehen. Allerdings mag Namo WebEditor das gar nicht.</p>
</body>
</html>
                                                                                                                                                                                                                                                                                                

 

Nicht nachvollziehbare Abstürze

Hin und wieder friert Namo WebEditor 2006 aber auch einfach ein. Das Problem lässt sich aber jeweils nicht klar reproduzieren. Rein gefühlsmäßig reagiert Namo wohl empfindlich, wenn man all zu schnell mit der Maus herumklickt. Vorzugsweise (wiederholt) ist Namo WebEditor 2006 bei folgenden Aktionen eingefroren:

  • Alt-Klick auf einen Link, der auf ein Lesezeichen auf einer anderen Seite verweist.
  • Erstellen eines Links mit Verweis auf ein nicht vorhandenes Lesezeichen.
  • Markieren, verschieben, editieren von Ebenen.
  • Mehrfaches " Rückgängigmachen" insbesondere wenn man im Split-Screen-Betrieb (WYSIWYG und HTML-Quelltext gleichzeitig) arbeitet.
  • Umbenennen oder Löschen von Dateinamen im Site-Manager.
  • Vermehrt kommt es zu Problemen, wenn man z.B. unter Windows XP als Benutzer mit eingeschränkten Rechten eingeloggt ist. Oft hilft es, wenn man Namo WebEditor mit Admin-Rechten startet. Startet man Namo WebEditor unter Windows XP im Kompatibilitätsmodus für Windows-2000, dann treten Programmabstürze ebenfalls seltener auf. Ganz fehlerlos läuft Namo aber auch im Admin-Konto nicht.

Empfohlene Verhaltensweise: Speichere oft und verwende zur Schadensbegrenzung ggf. die Autosave-Datei (*.asv), die Namo in von jeder HTML-Datei anlegt. Schau zu diesem Zwecke am besten mit dem Windows Explorer in das Homepageverzeichnis und vergleiche die Speicheruhrzeit der jeweiligen .htm-Datei mit der passenden .asv-Datei. Lösche die ältere und falls die asv-Datei neuer ist, dann benenne sie um, so dass sie auf .htm endet. Danach kannst Du sie mit Namo bearbeiten.

 

Schneller Sprung zu Version [2006 | 6 | 5.5 | 5.0 | 4 | 3 ]

Namo WebEditor 6

Hilfe, meine Zeilen werden immer länger. Warum funktioniert der Zeilenumbruch nicht mehr?

Unter bestimmten Umständen fügt Namo WebEditor 6 in den eingegebenen Text lauter " geschützte" Leerzeichen ein, anstatt normale. Hat man erstmal eine solche Mammutzeile eingetippt, dann werden alle anderen Zeilen automatisch an diese Zeilenbreite angepasst und das gesamte Layout wird breiter und breiter.....

Namo WebEditor erzeugt automatisch immer dann ein No-brake-space, wenn man vor oder hinter einem normalen Leerzeichen ein weiteres Leerzeichen einfügt. So weit ist das auch richtig. Aber wenn man in Namo 4 oder 5 ein Leerzeichen VOR einem vorhandenen Leerzeichen einfügt, dann wird stets das letzte Leerzeichen (also das bereits vorhandene) zum No-brake-space und das eingegebene Leerzeichen bleibt normal. Namo 6 wandelt aber stets das Leerzeichen um, das man gerade eingegeben hat. Das vorhandene (normale) Leerzeichen wird vor der Schreibmarke her verschoben und dadurch wird jedes weitere Leerzeichen wieder zum No-brake-space umgewandelt. Und das führt dann zu einem Problem, insbesondere wenn man die Leerzeichenmarkierungen nicht aktiviert hat und daher nichts davon bemerkt... Man kann diesen Effekt also sichtbar machen, wenn man die Leerzeichen-Markierungen einschaltet (Anzeige - Markierungen > Leerzeichenmarkierungen). Im Editor werden dann normale Leerzeichen mit einem kleinen grauen Punkt dargestellt. Geschützte Leerzeichen hingegen sind rot.

Das Problem tritt immer dann auf, wenn man einen bestehenden Text ergänzen will und vor einem Leerzeichen (also links davon) ein weiteres Leerzeichen eingibt um dann weiter zu schreiben. Leider bemerkt man es oft erst, wenn man schon einen ganzen Absatz geschrieben hat und sich schon ein Dutzend geschützte Leerzeichen im Text befinden. Wie man die dann einigermaßen stressfrei wieder los wird, das verrate ich in der Trickkiste.
 

Der HTML-Quelltext wird durch viele leere Zeilen immer mehr aufgeblasen

Unter unbekannten Umständen fügt Namo WebEditor 6 in den Quelltext Leerzeilen ein. Das geschieht wohl während des Editierens, aber auch, sobald man das Dokument speichert. Je öfter man es bearbeitet und speichert, desto stärker scheinen sich die Leerzeilen zu vermehren. Selbst wenn man sich die Mühe macht und alle Leerzeilen von Hand aus dem Quelltext entfernt, sind einige oder alle nach dem Speichern wieder da! Der HTML-Quelltext wird also immer weiter aufgeblasen, ohne dass man es verhindern kann!
 

Hyperlinks in Listen werden im Editor nicht geöffnet! (Alt-Klick)

Wenn man im Editor einen Link mit gedrückter linker Alt-Taste anklickt, dann folgt der Editor diesem Link und öffnet die Seite in einem neuen Fenster. Bei einem Lesezeichen, das sich in einer Aufzählungsliste befindet, funktioniert Alt-Klick aber nicht! Man kann zwar per Rechtsklick auf das Kontextmenü zugreifen und dort " Hyperlink öffnen" auswählen, aber direkt per Alt-Klick kann man den Link nicht öffnen.
 

Schlechte Darstellung von Listen-Punkten

Wenn man eine Liste (Aufzählung) erstellt und sehr große Schrift bzw. unterschiedliche Schriftarten darin verwendet, dann werden die Listenpunkte oft nicht mehr schön mittig, sondern mit zunehmender Schriftgröße immer weiter unten im Editor dargestellt. Das ändert zwar nichts am korrekten HTML-Code, aber im Editor sieht das nicht so gut aus.
 

Skript-Assistent: kein deutsches Anzeigenformat für die Uhr

Will man mittels Skript-Assistent eine Uhr einfügen, so wird nur die amerikanische und englische Schreibweise angeboten. In Namo WebEditor 5 (deutsch) konnte man zwischen verschiedenen Anzeigen in deutschem Format wählen. Namo 6 bietet aber auch in der deutschen Programmversion nur die amerikanische Schreibweise mit Slashes und AM/PM an. Eine vorläufige Lösung für das Problem findest Du in der Trickkiste.
 

Diashow-Bug im Album-Assistenten führt zu Fehlermeldung in Mozilla/Netscape-Browsern

Verwendet man im Album-Assistenten den Album-Stil " Diashow" und aktiviert die automatische Weiterschaltung nicht, weil man nur die manuelle Weiterschaltung wünscht, dann zeigt z.B. Mozilla Firefox eine Fehlermeldung an. Mehr dazu in der Trickkiste.
 

Im Site-Manager werden Dateien nicht nach Type sortiert

Klickt man in der Dateiliste " Sitedateien" auf die Spaltenüberschrift " Name" , dann werden die Dateien nach Namen sortiert. Auch ein Klick auf " Größe" führt zu dem erwarteten Ergebnis.
Aber macht man die Spalte " Typ" sichtbar (durch Rechtsklick und entsprechende Auswahl im Kontextmenü) und versucht dann nach Type zu sortieren, dann klappt das nicht. Es wird immer nach der zuletzt aktiven Sortierungsmethode umgestellt.
 

Falsche Farben im Scrollbar-Farben-Assistenten

Ruft man irgend wann einmal den Scrollbar-Assistenten auf, um die Farben, die man zuvor schon damit bestimmt hatte, zu überarbeiten, dann stimmen die Farben für " Flachen Bereich" und " 3D-Effekt" in der Vorschau nicht mehr. Genau gesagt hat der Flache Bereich nun die Farbe, die vorher 3D-Effekt war. Und der 3D-Effekt wurde auf Standard-Grau zurückgesetzt. Bei genauer Betrachtung ist aber der Quelltext noch in Ordnung. Der Scrollbar-Assistent liest die Farben also nur falsch ein. Wenn man aber den Scrollbar-Assistenten mit den falschen Farben durch Klick auf  [  OK  ] schließt, dann werden die falschen Einstellungen gespeichert. Man muss also die falschen Farben jedes mal korrigieren, bevor man den Assitenten beendet.
 

Navigationsleiste mit Flashbuttons wird nur im IE angezeigt

Namo WebEditor ab Version 6 fügt bei einer Navi-Leiste mit Flashbuttons z.B. folgenden HTML-Code ein:
<param name="movie" value="nav\nav_8_favorite_th.swf">
und
<embed src="nav\nav_8_favorite_th.swf" ......></embed>

Die Verknüpfung zu der Grafik im Unterverzeichnis "nav" wird mittels Backslash \ dargestellt, wie das unter Windows üblich ist. Auf dem WebServer wird aber ein normaler Slash / benötigt. Der Internet-Explorer und ältere Fassungen des Firefox-Browsers ignorieren den Fehler. Ab Version 3 kömmt Mozilla Firefox damit aber nicht mehr klar. Die Flash-Buttons sind nur noch weiße Flächen. Korrekt müssten die beiden Zeilen also wie folgt aussehen:

<param name="movie" value="nav/nav_8_favorite_th.swf">
und
<embed src="nav/nav_8_favorite_th.swf" ......></embed>

 Der Fehler tritt bei normalen Flash-Buttons und Flash-Bannern nicht auf. Nur in der Navigationszeile verwendet Namo WebEditor den Backslash.

Navigationsleiste in Layouttabelle

Fügt man eine Navigationsleiste in eine Layouttabelle ein, so kann es zu seltsamen Effekten kommen. Oftmals verschwindet die Navigationsleiste einfach. Zumindest im Editor wird sie nicht mehr dargestellt. Dies ist ein klarer Bug in Namo 6. Um das Problem zu umgehen, sollte man die Layouttabelle einfach in eine normale Tabelle umwandeln. Wann immer man noch Änderungen an der Tabelle vornehmen will, kann man sie wieder in eine Layouttabelle umwandeln. Natürlich mit dem Effekt, dass dann die Navigationsleiste wieder unsichtbar wird...
 

Probleme bei der Eingabe von Ä oder ß beim Umbenennen von Navigationsnamen oder Seitentiteln in der Sitestruktur

Unter Windows XP oder Windows 2000 kommt es zu einem Problem, wenn man im Site-Manager in der Sitestruktur den Navigationsnamen umbenennen will und dabei bestimmte Umlaute verwendet. So kann es sein, dass man z.B. das ß und das Ä nicht eingeben kann. Es kommt einem vor, als ob die Tastatur defekt sei. Man kann sich aber behelfen, indem man den Navigationsnamen zuvor in irgend einer anderen Anwendung eintippt und von dort über die Windows-Zwischenablage kopiert und in die Eingabezeile einfügt.
 

Programm-Symbolleiste verstümmelt nach Bearbeitung

Füge in eine der Symbolleisten (z.B. die Tabellen-Symbolleiste) einige weitere Schaltflächen und auch einige Separatoren ein. Schließe dann Namo WebEditor und starte das Programm wieder. Du wirst sehen, dass nun die komplette Symbolleistenfläche total verstümmelt ist. Lässt Du die Separatoren weg, dann geht es.
 

Programmabstürze

Bei diversen, teils nicht immer ganz nachvollziehbaren Gelegenheiten hängt sich Namo WebEditor 6 einfach auf. Nach dem Update-Patch sind viele dieser Probleme behoben, bzw. Abstürze kommen viel seltener vor. Es wird allgemein empfohlen, dass man zwischendurch öfter mal abspeichert.

Typische Gründe für Programmabstüze sind:

  • Manuelle Eingabe von nicht korrektem (unvollständigem) HTML-Code im Quelltext *)
  • Mehrfaches Rückgängigmachen kurz hintereinander
  • Einfügen einer neuen Zeile nach einer Überschrift
  • Fehler im Treiber der Grafikkarte
  • Mangelnde Systemressourcen
    (Empfohlen: Nicht unter 500 MB RAM und 1,5 GHz Systemtakt)
  • Betrieb unter Windows XP als Benutzer mit eingeschränkten Rechten

*) Typisches Beispiel für fehlerhaften HTML-Code, der Namo WebEditor 6 unweigerlich zum Absturz bringt (fehlendes Tag </iframe> und dann gleich weiter mit <p>....):

<iframe src="abdefg.htm" height="123" width="123" frameborder="0" scrolling="yes">
<p>Sorry, Dein Browser zeigt keine Iframes an.<p>
 
Nach dem Update-Patch: Programm-Hilfe - Index defekt

Neben einigen unwesentlichen Verbesserungen bringt das Namo WebEditor 6 Update-Patch auch einen neuen Bug mit: In der Programm-Hilfe funktioniert der Index nicht mehr. Soweit noch eine Kopie von alten Namo6-Verzeichnis vorhanden ist, kann man die neue Datei " webedit.chm" aber einfach gegen die alte ausstauschen. Wer leider über keine Kopie der alten Hilfe-Datei mehr verfügt, der kann sie downloaden: <   rechtsklick-Speichern  unter  > > download webeditor.chm (2,74 MB).
 

Fehlerhafter Import von Excel-Tabellen mit Datums-Feldern schon seit Version 5

Wenn man eine Excel-Tabelle importiert, dann werden die Formate von Datums- und Zeitangaben ignoriert und Namo fügt sie in seinem eigenen (amerikanischen) Format ein. Beispiel: aus 31.12.05 wird 12-31-2005. Bei den Zeitangaben werden führende Nullen gestrichen. Aus 05:59 wird dann 5:49. Das Problem besteht schon seit Version 5 (in Version 4 klappte es noch).

 

Schneller Sprung zu Version [ 8 | 2006 | 6 | 5.5 | 5.0 | 4 | 3 ]

Namo WebEditor 5.5

Layout-Tabellen-Bug
Unter bestimmten Umständen - nämlich immer dann, wenn Layoutzellen den unteren Rand der Layout-Tabelle berühren - kommt es zu folgendem Phänomen:
Wenn man eine Layoutzelle in ihrer Größe verändert, dann werden auch andere (benachbarte oder ähnliche) Layoutzellen mitverändert. Das kann so weit gehen, dass durch eine geringfügige Änderung einer einzelnen Zelle das gesamte Layout verzerrt wird.

Der Bug betrifft nur die Version 5.5 und trat in Version 5.0 noch nicht auf. Ausgelöst wird das Problem, wenn Layoutzellen den unteren Rand der Layouttabelle berühren, folglich kann das Problem beseitigt werden, indem man den unteren Tabellenrand von den Zellen abrückt. Es reicht schon, wenn man die Tabellenhöhe um nur 1 Pixel erhöht. Dies geschieht am zweckmäßigsten, indem man die Layout-Tabelle-Eigenschaften aufruft, und dort den Wert bei " Höhe" um 1 erhöht.
 

GIF-Animator stürzt ab, wenn man mehrere Einzelbilder markiert
Wenn man auf die Idee kommt, dass man die Eigenschaften mehrerer Einzelbilder gleichzeitig festlegen könnte, wenn man sie zuvor einfach alle markiert, dann wird man leider enttäuscht. Der GIF Animator nippelt dann einfach ab.
 

Falsche Übersetzung in der WebCanvas-Hilfe
screenshot webcanvas-ebenen-ÜberblendeffekteIn der Hilfe zu WebCanvas unter Lernprogramm/Arbeiten mit Smart-Schaltflächen/Erstellen eines Banners heißt es in Schritt 2: " Erstellen eines Bannerframes" unter Punkt  7:
" Geben Sie als Überblendungsmodus der Ebenen im Fenster Ebenen die Option Bildschirm an."
Dieses Option " Bildschirm" gibt es bei den Ebenen-Überblendeffekten aber nicht. Dort heißt diese Option " Raster" . Offenbar wurde die englische Bezeichnung " Screen" in der Hilfe zu WebCanvas kurzerhand und ohne jeden Sachverstand mit " Bildschirm" übersetzt. Der selbe fehlerhafte Text wird auch im WebCanvas Tutorial verwendet. Dieser Bug betrifft natürlich auch nur die Version 5.5.
 

Fehlerhafter Import von Excel-Tabellen mit Datums-Feldern
Wenn man eine Excel-Tabelle importiert, dann werden die Formate von Datums- und Zeitangaben ignoriert und Namo fügt sie in seinem eigenen (amerikanischen) Format ein. Beispiel: aus 31.12.05 wird 12-31-2005. Bei den Zeitangaben werden führende Nullen gestichen. Aus 05:59 wird dann 5:49.

Fehlerhaftes < link> -Tag
Wenn man im Stil-Datenblatt Dialog (Format - Stil-Datenblatt) unter " Verbundenes Stil-Datenblatt:" den Dateinamen einer externen CSS-Datei eingibt (beispielsweise " stil.css" ), dann erzeugt Namo WebEditor folgendes HTML-Tag:
< link rel=" stylesheet" href=" stil.css" >
Darin fehlt das Attribut " type" . Dies wird z.B. bei der HTML-Verifizierung angemeckert. Beheben kann man das " Problem" , indem man das Tag im Quelltext manuell wie folgt ergänzt:
< link type=" text/css" rel=" stylesheet" href=" stil.css" >
Die automatische HTML-Korrektur von Namo WebEditor behebt diesen Formfehler ebenfalls.

 

Schneller Sprung zu Version [ 8 | 2006 | 6 | 5.5 | 5.0 | 4 | 3 ]

Namo WebEditor 5.0

Die folgenden Bugs betreffen nur die Version 5.0, da sie in Version 5.5 alle behoben sind.

Flash-Buttons: " Keine Umlaute erlaubt"
Wer mit Version 5.0 ein Banner oder einen Button im Macromedia Flash-Format einfügt, der muss bei dessen Beschriftung leider auf Umlaute (äöü) und auch auf das " ß" verzichten, denn diese werden nicht angezeigt. Offenbar sind nur ASCII-Codes bis Nr. 127 erlaubt. Damit entfallen alle Umlaute und Akzente. Auch das Euro-Zeichen ist betroffen. Für dieses Problem gibt es aber einen Patch, den man von Namo herunterladen kann: Namo WebEditor 5 Flash Button Patch.

[Format - Absatz -Ausrichtung] defekt
Wenn man einen Absatz formatieren will (z.B. Blocksatz), dann kann man u.A. die Funktionen " Ausrichtung" nicht auswählen.
Man kann sich behelfen, indem man den Befehl [Format  -  Absatz-Stil  -  Text] verwendet.

 

Falsche Seiten Wizard Informationen

Dort gibt man nun also gewissenhaft alle Daten ein. Aber wenn die HP fertig erstellt ist, dann sieht man, dass Namo WebEditor alle Eingaben einfach ignoriert hat und wieder seine Default-Werte eingesetzt hat. Letztlich muss man also alle erstellten Seiten bezüglich dieser Informationen nachbearbeiten.

Allein diese Tatsache macht den Wizard unbrauchbar. Doch es kommt noch schlimmer. Wenn man sich die Mühe macht, im Wizard bestehende Seiten umzubenennen und zu kopieren, um daraus neue Seiten abzuleiten, dann wird man wiederum enttäuscht.

Die alten Dateinamen bleiben nämlich bestehen. Am Ende hat man z.B. eine Seite " Neue Seiten" mit dem Dateinamen " Favorites.html" ... Darüber hinaus nervt es auch, dass man die Endung " htm" nicht fest vorbestimmen kann. Alle Wizard-Seiten haben stets die Endung " html" .

So ist eine komplette Homepage zwar in 5 Minuten erstellt. Aber man braucht weitere 20 Minuten pro Seite, um all das nachzubearbeiten, was der Wizard nicht geleistet, bzw. verbockt hat. Erst dann kann man sich den eigentlichen Inhalten der Homepage widmen.

Die Rechtschreibprüfung funktioniert nicht richtig
Es gibt ein sog. Benutzer-Wörterbuch, damit die Rechtschreibprüfung neue Schreibweisen hinzulernen kann:

Klickt man in diesem Popup aber auf [Hinzufügen], dann tut sich scheinbar garnix! Jedoch: Ein Klick auf [Benutzer-Wörterbuch] verrät uns, dass das Wort übernommen wurde. Trotzdem wird das Wort bei der nächsten Prüfung wieder als falsch erkannt. Namo WebEditor ignoriert mit Fleiß die Einträge im Benutzer-Wörterbuch! Aber das ist nicht alles. Das Hauptwörterbuch ist voll von falschen Worten. Man bekommt die hirnrissigsten Korrekturvorschläge. Und so manches falsch geschriebene Wort wird überhaupt nicht gefunden. Kurzum: Die Rechtschreibprüfung ist nicht zu gebrauchen!

Namo fügt u.U. beim Speichern viele Zeilen mit Leerzeichen ein
Bei uns noch nicht vorgekommen, aber im Support-Forum als Bug bestätigt: Es kann passieren, dass eine Datei mit vielen Zeilen voller Leerzeichen unnötig aufgeblasen wird und dann einige hundert Kilobytes größer wird, als es tatsächlich notwendig wäre! Ein bekannter Bug - wie gesagt. Einzige Abhilfe derzeit: Quelltext manuell (evtl mit einem reinen Texteditor) bereinigen.

Texthintergrundfarbe verschwindet, wenn Textfarbe sich ändert
Ändert man zuerst die Texthintergrundfarbe und anschließend auch noch die Textfarbe, dann verschwindet die Hintergrundfarbe wieder. Zumindest zeigt Namo die Texthintergrundfarbe im Bearbeiten-Modus nicht mehr an. Der HTML-Code ist aber OK und somit sieht es im Browser wie beabsichtigt aus.

 

Schneller Sprung zu Version [ 8 | 2006 | 6 | 5.5 | 5.0 | 4 | 3 ]

Namo WebEditor 4

Probleme mit Hintergrund bei sehr großen Tabellen
Bei sehr viel Text und Bildinhalt einer Tabellenzelle kommt es vor, dass der Editor die Tabelle nicht mehr vollständig mit dem Hintergrundbild füllt. Löscht man in einer solchen Mammutzelle auch noch ein paar Zeilen, oder verschachtelt man gar mehrere Tabellen ineinander, so rutschen eine oder mehrere Zeilen von unterhalb der Tabelle hinauf, in die Tabelle hinein. Es kam auch schon vor, dass die Hintergrundfarbe einer Zelle nicht in ihr selbst, sondern wahllos irgendwo außerhalb erschien. Beides sind aber nur Darstellungsprobleme. Der HTML-Code ist einwandfrei und im Preview-Modus oder im Browser wird alles richtig angezeigt. 

< /form> -Tag rutscht innerhalb Tabellen in falsche Zelle
Bei Formularen in Tabellen kann das Tag < /form> unter Umständen in eine andere Zelle rutschen. Das kann dazu führen, dass die Formulardaten nicht mehr korrekt übernommen werden. Ab Version 4 gibt es aber die Einstellung " Bestehende HTML-Quelle nicht verändern" . Ist diese aktiviert, lässt sich das Problem im Quellcode-Editor von Hand beheben.

Textmenü funktioniert nicht (JavaScript)
Erstellt man mit dem Skript-Wizard ein Textmenü, so wird dieses anschließend im Browser nicht angezeigt. Ggf. erhält man eine Fehlermeldung: "target ist null oder kein Objekt". Das liegt an einer Fehlenden Zeile im JavaScript-Code, die man aber nicht von Hand ergänzen kann, da Namo sein Script immer wieder "korrigiert". Einzige Abhilfe ist ein Update. Für die technisch interessierten hier trotzdem die betroffene Funktion:

function namosw_init_menu()
{
  var i, list, layer;
  list = new Array();
  list[list.length] = 'Linkname';
  list[list.length] = 'seitenname.htm';
  list.target = new Array();
  list.target[list.target.length] = '';
  namosw_menu_write(list, 200, 'layer1', 'lightyellow', 'black','', '12', 'none', '', 'underline', '');
}

Im defekten Script fehlt die hervorgehobene Zeile list.target[list.target.length] = '';

Probleme beim Publizieren mit der automatischen Markierung geänderter Dateien

Es gibt eine Funktion zur automatischen Auswahl der geänderten Dateien für die Publikation. Aber Dateien in Unterordnern werden immer komplett zum Upload markiert, es sei denn öffnet die Unterordner zuvor im Remotefenster (auf dem Server).
Manchmal werden aber auch Dateien zum Upload markiert, die mit Sicherheit nicht geändert wurden.

Der Grund: Namo 4 hat ein Problem beim Auslesen der Daten von Unterverzeichnissen vom Server. Daher werden alle Dateien in Unterverzeichnissen pauschal als "geändert" angesehen. Wenn man durch Klick auf das [+] jeweils alle Unterverzeichnisse im Remote-Fenster öffnet, dann kann Namo diese auslesen. Genauso gut kann man aber auch die Markierungen bei den lokalen Verzeichnissen entfernen, wenn man genau weiß, dass man dort nichts verändert hat.

Außerdem hat Namo 4 hat ein "Jahr-2000-Problem". Und zwar werden lokale Dateien mit Datum vor 2001 (also "00" oder "99", etc..) nicht korrekt eingeordnet. Jedes neuere Datum "01", "02" u.s.w. auf dem Server wird als "älter" angesehen. Daher werden diese Dateien fälschlicherweise stets als "geändert" markiert. Das kommt also ganz typisch bei älteren Bildern aus ClipArt-Sammlungen vor, die man auf der Homepage eingebaut hat und deren Änderungs-Datum sich dadurch ja seit Ewigkeiten nicht geändert hat.

 


Nach zwei kostenlosen Updates (Download von www.namo.com) lautete die letzte Versionsnummer 4.04 - oder ganz genau: 4.0.4.34:2113536:45174. Darin sind so ziemlich alle Bugs ausgemerzt.
Namo WebEditor 4 war damit ein superstabiles und extrem fehlerarmes Programm.

 

Schneller Sprung zu Version [ 8 | 2006 | 6 | 5.5 | 5.0 | 4 | 3 ]

Namo WebEditor 3

Die Vollversion (Promotion-Version) von der Heft-CD stürzt ab, wenn man ein neues Projekt anlegen will. Wir haben das Problem bei Windows-98 Systemen beobachtet. Uns wurde gesagt, dass der Fehler unter Windows 2000 nicht auftritt. Es liegt daran, dass zu Promotion-Zwecken nur die Version 3.04 freigegeben wurde. Diese enthält aber den oben genannten Bug. Ab Version 3.08 (erhältlich als Shareware) ist das Problem behoben. Näheres kannst Du in unserer Trickkiste nachlesen.

 

nach oben
[Site-Info][News][Vorwort][Recht][Impressum][Danke Jörg]