Archiv für den Monat: Oktober 2009

Debuggen oder Starten mit Lazarus nicht möglich

Schreibe eine Antwort

Habe Lazarus neu installiert, eine kleine Anwendung erstellt und das ganze per STRG+F9 kompiliert. Alles okay.

Nun versuche ich, per F9 das ganze zu starten oder zu debuggen und siehe da, folgende Meldung taucht auf:

lazarus_schmiert_ab

Am besten finde ich die letzte Zeile.

… hoffen Sie auf einen Fix für diesen Bug.“

 

Wohin _genau_ soll ich denn meine Hoffnungen wenden? Naja, wird grade wieder sehr philosophisch hier, also überlasse ich nun jedem selbst, was er/sie/es darüber denken möchte.

Für mich ist Lazarus erstmal wieder gestorben; evtl. sehe ich es mir nach dem Weltuntergang 2012 wieder an *g*

Und was nun?

Schreibe eine Antwort

Und wieder ein Fall aus der Gattung:

Was will uns der Autor sagen ???

Die Meldung stammt aus Adobe Acrobat Reader, nachdem ich versucht habe, von Version 9.0.2 auf die heute aktuelle upzudaten:

acrobat reader fehler - was nun

eBesucher verbietet NoScript-Addon

Schreibe eine Antwort

Mein Besuchertausch „eBesucher“ verbietet seit neuestem das Firefox AddOn „NoScript„.
Da dies m.E. nicht recht so sein kann, da ja immerhin viele eBesucher Seiten ziemlich … naja … lästigen Code enthalten (Framebrecher, Cookie-Räuber, Malware-Meldungen, usw.) habe ich das ganze mal mit „Firebug“ gedubbed und hier die Lösung zum Problem.

  • Rechtsklick auf das NoScript „S“ im Statusbereich, dann auf „Einstellungen“
  • Dort auf den Reiter „Plug-ins“ und dort den Haken bei „ verbieten“ rausmachen.
  • Dann mit OK bestätigen.

Das Prototype-Javascript-Script prüft nur nach, ob die IFrames geblockt werden, in dem geprüft wird, ob der entsprechene NoScript-Platzhalter gesetzt ist („__noscript_placeholder__“). Dieser wird nur gesetzt, wenn diese Option aktiviert ist.
Macht man den Hacken raus, kann man NoScript weiterhin mit eBesucher ganz normal benutzen.

Alternativ kann man auch die Lösung von Daniel Roß benutzen, die lediglich den Platzhalter entfernt, was die Zielseite erst gar nicht lädt. Zu finden ist die Anleitung im Blog von Daniel.

Eine JS-Prüfung auf ein installieres AddOn im Firefox ist AFAIK nicht möglich.

Auch Profis machen Fehler *grins*

1 Antwort

Ich wühle mich durch die Dokumentation zu den we-Tags von webEdition. Dabei fiel mir auf, dass auch gestandene Profis im Webbereich Fehler machen, die diese eigentlich nicht machen dürften.

Ein Beispiel aus der Doku zum we-Tag “we:keywords”:

Mit htmlspecialchars=“true“ werden Sonderzeichen in HTML-Entities umgewandelt (z.B. wird „&“ zu „&“). Ist htmlspecialchars nicht gesetzt, wird diese Umwandlung nicht vorgenommen.

Sicherlich ist gemeint, dass ein & zu einem & wird, aber da hat wohl der Editor dem Autor einen Streich gespielt und das & nicht richtig “escaped” und der Browser stellt das & (ganz korrekt übrigens) als & dar.

Also, liebe Profis bei webEdition, durchcrawled mal eure Doku und korrigiert dies bitte, damit auch Amateure den Mehrwert des Attributes “htmlspecialchars=true” kennenlernen dürfen.

Irgendwie bin aber doch beruhigt, dass sowas auch anderen passiert, sind also doch alles auch nur Menschen am anderen Ende der Doku *wink*