Probleme mit Hotspots ...

  • Hallo Leute,


    habe ein ungewöhnliches Problem mit Hotspots nach dem Notes Client Update von R5 auf R6.53.
    In einer Datenbank wurden (warum auch immer) Hotspots mit berechneten Links angelegt, bei denen statt slash "/" backslash "\" verwendet wurden. Beim Notes 5 Client wurde beim Klick auf den Link der IE gestartet und es erfolgte eine Umsetzung von "\" nach "/" (also z.B.: http:\\server\verz\datei.html -> http://server/verz/datei.html). Jetzt nach dem Update scheint diese Umsetzung nicht mehr zu passieren. Es erscheinen in der Adreßzeile die Zeichen "%5C". Leider gibt es in dieser Datenbank sehr viele Dokumente mit diversen Links - wobei eine manuelle Korrektur nicht möglich ist (freigegebene Dokumente am Ende eines Workflows ...).


    Und jetzt meine Frage: Kann ich dem 6.5er Client die Umsetzung wieder beibringen? Oder - wo stehen die Informationen/Formeln zu berechneten Hotspot Links und kann ich die programmatisch verändern?


    Vielen Dank im voraus ...



    Gruß
    Thom

    • Offizieller Beitrag

    an der Umsetzung von Notes hat sich nichts geändert.


    Habs gerade nochmal im 6.5.3. und 6.5.4 probiert, beide Varianten funktionieren.


    Gruß
    Dirk

    Rein logisches Denken verschafft uns keine Erkenntnis über die wirkliche Welt.
    Alle Erkenntnis der Wirklichkeit beginnt mit der Erfahrung und endet mit ihr.
    Alle Aussagen, zu denen man auf rein logischen Wegen kommt, sind, was die Realität angeht, vollkommen leer.
    Albert Einstein

  • Vermutlich hilft dir die Funktion @URLDecode da weiter, um die "alte Umsetzung" wieder hinzubekommen.


    Kleiner Ausschnitt aus dem IBM-Kommentar zu den neuen @Funktionen
    http://www-128.ibm.com/develop…/ls-formula_enhancements/


    (dabei waren @URLEncode und @URLDecode bereits seit 4.6 - damals noch als undokumentierte Funktionen - verwendbar).


    Relief for Web developers
    Goodbye @SubString. Notes/Domino 6 introduces a group of new functions that translate human-readable Notes titles and URL commands into Web-readable formats without requiring the use of @SubString to replace backslashes with forward slashes or worrying about whether the browser prefers plus signs over ampersands. Perhaps the longest anticipated of these new functions is @WebDbName, which returns the current database name converted to a URL-friendly format. It returns, for example, "Stuff/Customer%20List" if the current database name is called Customer List.nsf and resides in the Stuff subdirectory. What does this mean to you? It means that instead of writing:
    @ReplaceSubstring(@Subset(@DbName;-1);"\\";"/")


    you can write:
    @WebDbName


    Another new Web-savvy @function, @URLEncode, gives you the ability to determine the character set with which to encode a string into a URL-safe format. By default, the Domino 6 Web server uses UTF-8, which stands for UCS (Universal Character Set) Transformation Format 8. UTF-8 is an ASCII-compatible multi-byte Unicode and UCS encoding. Using @URLEncode, you can instruct the server to encode a string using a different character set, such as Shift_JIS, the character set that supports Japanese characters, or ISO-8859-1, which is an 8-bit, single byte coded graphic character set for European languages.


    If you have a form entitled "Ingl#x439s," for example, and want to access it from a Web browser, you could write the following code in a hotspot button:
    @URLOpen("http://MyServer/" + @WebDbName" + "/" + @URLEncode("ISO-8859-1"; "Ingl#x439s") + "?OpenForm")


    Once the form opens, the resulting URL string looks like this:
    http://MyServer.domain.com/Customer.nsf/Ingl%C3%A9s?OpenForm


    The %E9 is the UTF-8 encoding of the #x439 in the form name. Because the function specified Domino, the server used Domino's default encoding character set, which is UTF-8.


    To specify the use of the ISO-8859-1 character set instead, write the formula as follows.
    @URLOpen("http://MyServer/" + @WebDbName" + "/" + @URLEncode("ISO-8859-1"; "Ingl#x439s") + "?OpenForm")


    The resulting URL string looks like this:
    http://MyServer.domain.com/Customer.nsf/Ingl%C3%A9s?OpenForm


    @UrlEncode gives you greater control over how your URL strings are interpreted by a Web browser. This function is very useful, especially for multi-language applications that are accessed from the Web.


    @URLDecode turns strings in Web-ready format into human-readable strings. It again gives you the ability to specify the character set to use while decoding. You could use @URLDecode, for example, in an input validation formula for a field if the field contains an encoded URL.


    A form with a field having the following default value formula:
    "http://MyServer/"+@WebDbName + "/" + @URLEncode("Domino";"Ingl#x439s") + "?OpenForm"


    displays the field as follows:
    http://MyServer/Blank.nsf/Ingl%C3%A9s?OpenForm


    If you add the following code as the input validation formula for the field:
    @URLDecode("Domino";@ThisValue)


    when the document is refreshed, the encoded URL is replaced with http://MyServer/Customers.nsf/Ingl#x439s?OpenForm, which is much easier for users to understand.