getThreadInfo( LSI_THREAD_CALLMODULE )

  • Hallo zusammen,


    ich habe mal eine Frage zu getThreadInfo
    Der Aufruf mit "LSI_THREAD_CALLMODULE" liefert mir nur eine Zahl (z.B. "*69A0A30" ) zurück, statt wie in der Hilfe "the name of the calling module".


    Kann mir jemand sagen warum?


    Danke.


    Gruß von Ekki.

  • Das einzige was ich dazu sagen kann, ob du die LSCONST.LSS eingebunden hast.


    Auszug aus Designer:
    The values of the constants are defined in LSPRVAL.LSS, which is automatically included through LSCONST.LSS.



    Vielleicht kriegst du deshalb so n komischen wert zurück.


    lg,
    ghostxxl

  • Hallo,


    ich habe die LSCONST.LSS eingebunden, sonst könnte ich ja auch nicht mit "LSI_THREAD_CALLMODULE" arbeiten.


    Trotzdem danke.


    Gruß von Ekki.

  • Ekki, post mal in unseres B-KH forum, dann wirst du dort bestimmt schnell ein antowrt bekommen vom api programmieren bei uns.. Der ist soweit ich weiß nicht hier im forum.

  • Hallo Norbert


    Ja, es geht um eine ErrorHandling Routine. Ich würde jedoch eher eine dokumentierte Funktion (getThreadInfo) benutzen, anstatt eine undokumentierte (LSI_Info).


    Ausserdem hab ich jetzt kurz geschaut: ein LSI_Info(3) (was das Modul zurückgeben sollte) gibt wie bei getThreadInfo eine Zahl zurück. Respektive habe ich irgendwo gelesen, dass dies ein Hex-Wert sein soll. Nur kann ich auch damit nicht viel anfangen...


    Greets
    Patrick

  • Die einzuziehende LSS für die Auswertung der dokumentierten LSI-Funktionen heißt lsprCval.lss (ich habe das C groß geschrieben, weil die Notes-Hilfe an der Stelle einen Fehler hat)


    Ich kann mich nicht erinnern, daß ich etwas von LSI_Info(3) geschrieben habe. LSI_Info(2) ist der Modulname, (LSI_Info(3) die LS-Version).


    Wenn du dich mit ErrorHandling auseinandersetzst, kann dir das Projekt OPENLOG von OPENNTF helfen. (Zitat aus dem Kommentar von Julian Robichaux: It uses lsi_info and many other tricks to easily access error logging information. All you have to do is copy the script library to your database, include it in your LotusScript code, and type "LogError" in all your error handling blocks.)


    Ich habe das Zitat abgedruckt, damit du weißt, daß du dich dabei auf die undokumentierte LSI_INFO-Variablen gleich wieder einläßt.


    Wenn dir undokumentierte Funktionen schon beim Errorhandling zu viel sind, dann scheinst du ein Purist zu sein, der den potenziellen Fehler bei der Fehlerbehandlung mehr fürchtet als den Nutzen davon sehen kann.


    Wenn ein Anwender dann einmal in einer Anwendung eine Notes-DB öffnen will, wirst du bestimmt auch nicht ein @Prompt([LOCALBROWSE) oder in LS ein
    xvariant=uiworkspace.prompt(13,$title,$prompt) anbieten, das dir in einem Array Server, Filepath und Title zurückgibt,
    sondern sagen, daß das nicht geht, weil es sich um undokumentierte Funktionen handelt.


    Ist ein Standpunkt. Ist aber nicht mein Standpunkt. Das muß jeder mit sich selbst ausmachen.