Loading ...
Sorry, an error occurred while loading the content.

Custom functions from clipbar?

Expand Messages
  • Eb
    I ve been asked for my workaround to using custom functions within a clipbar clip. The problem with UDFs (user defined functions, or custom functions) from the
    Message 1 of 3 , Jun 14, 2011
    • 0 Attachment
      I've been asked for my workaround to using custom functions within a clipbar clip.

      The problem with UDFs (user defined functions, or custom functions) from the clipbar is, that clip calls from the clipbar must be FarClip calls, even within the same library. Wheras UDFs have no provision for far calls.

      As a workaround, one needs to replace the ^%result% variable with the clipboard, and make a separate call to the clip that SETS the clipboard:

      This method worked in all combinations of clip locations I've tested.

      Replace the UDF call:

      ^!Set %output%=^$UDF(arg)$

      within a clipbar clip, with

      ^!FarClip "libname:UDF" arg
      ^!Set %output%=^$GetClipbar$

      and recode the UDF to use the clipboard instead of, or in addition to, %result%:

      --------------->8--------------
      H="UDF"
      ;udf runs as regular clip and as custom function,
      ;BUT NOTE: it will set the clipboard either way!
      ^!Set %result%=(whatever process)
      ^!SetClipboard ^%result%
      --------------->8--------------

      Alternatively, if you can guarantee, that both clips are located in the current clipbook, you can use ANY UDF located in this clipbook, in the conventional way:

      --------------->8--------------
      H="Clipbar Clip"
      ;near call works, but only if everything is in the current clipbook!
      ^!IfClipExist UDF NEXT else SKIP_3
      ^!Set %test%=^$UDF(7)$
      ^!SetWizardTitle Running from the clipbook
      ^!Info "^%test%"
      ^!FarClip "^$GetLibraryName$:UDF" 5
      ^!Set %temp%=^$GetClipboard$
      ^!SetWizardTitle Running from any library
      ^!Info "^%temp%"


      H="_UDF"
      ;test udf call from clipboard
      ^!Set %result%=^$Calc(3*^&)$
      ^!SetClipboard ^%result%
      --------------->8--------------

      Note: Insert both clips above into the same library. Then add a call to "clipbar clip" to a clipbar, and run it with the library as the current clipbook, and then load a different clipbook, and test the same clip, to see the difference.

      By the way, in case you're wondering, the test for ClipExist in the clipbar clip (line 1) fails, even though the clip is indeed in the same library, if that libary is NOT the current clipbook.


      Cheers,


      Eb
    • Art Kocsis
      Thanks Eb, BTW, I think you meant ^$GetClipBOARD$ not ^$GetClipBAR$ in your overview. This looks interesting but given the amount of coding required I am
      Message 2 of 3 , Jun 14, 2011
      • 0 Attachment
        Thanks Eb,

        BTW, I think you meant ^$GetClipBOARD$ not ^$GetClipBAR$ in your overview.

        This looks interesting but given the amount of coding required I am
        wondering what is the advantage over using regular clips and a standard
        naming convention?

        For example, if I define

        %UDF_arg% to always and only be used to pass an argument
        %UDF_result% to always and only be used to pass a result

        for all my clips would this not accomplish the same thing and without the
        potential of destroying the current clipboard contents (which can be saved
        and restored but takes extra code)? Or is the problem retaining clip values
        when changing clipbooks?

        I have used clip variables to pass values among sets of related clips
        within the same clipbook without any problems but I haven't played around
        with clip variables between clips from different clipbooks. According to
        the Help file, clip variables are destroyed when a clipbook is closed which
        would imply no retention at all when using clipbar clips and the clipbook
        is closed. Yet I have run clip sets from the clipbar that retained their
        values (at least while running). Investigating the retention properties of
        NTB clip variables is on my ToDo list but hasn't made it to the top yet.

        Namaste', Art

        At 06/14/2011 07:41, Eb wrote:
        >I've been asked for my workaround to using custom functions within a
        >clipbar clip.
        >
        >The problem with UDFs (user defined functions, or custom functions) from
        >the clipbar is, that clip calls from the clipbar must be FarClip calls,
        >even within the same library. Wheras UDFs have no provision for far calls.
        >
        >As a workaround, one needs to replace the ^%result% variable with the
        >clipboard, and make a separate call to the clip that SETS the clipboard:
        >
        >This method worked in all combinations of clip locations I've tested.
        >
        >Replace the UDF call:
        >
        >^!Set %output%=^$UDF(arg)$
        >
        >within a clipbar clip, with
        >
        >^!FarClip "libname:UDF" arg
        >^!Set %output%=^$GetClipbar$
        >
        >and recode the UDF to use the clipboard instead of, or in addition to,
        >%result%:
        >
        >--------------->8--------------
        >H="UDF"
        >;udf runs as regular clip and as custom function,
        >;BUT NOTE: it will set the clipboard either way!
        >^!Set %result%=(whatever process)
        >^!SetClipboard ^%result%
        >--------------->8--------------
        >Alternatively, if you can guarantee, that both clips are located in the
        >current clipbook, you can use ANY UDF located in this clipbook, in the
        >conventional way:
        >--------------->8--------------
        >H="Clipbar Clip"
        >;near call works, but only if everything is in the current clipbook!
        >^!IfClipExist UDF NEXT else SKIP_3
        >^!Set %test%=^$UDF(7)$
        >^!SetWizardTitle Running from the clipbook
        >^!Info "^%test%"
        >^!FarClip "^$GetLibraryName$:UDF" 5
        >^!Set %temp%=^$GetClipboard$
        >^!SetWizardTitle Running from any library
        >^!Info "^%temp%"
        >
        >H="_UDF"
        >;test udf call from clipboard
        >^!Set %result%=^$Calc(3*^&)$
        >^!SetClipboard ^%result%
        >--------------->8--------------
      • Eb
        ... Yes, I menat clipboard 8=D. ... You have a point. But I got to the workaround in a series of steps, from working clips, clipbars, and libraries, that
        Message 3 of 3 , Jun 15, 2011
        • 0 Attachment
          --- In ntb-clips@yahoogroups.com, Art Kocsis <artkns@...> wrote:
          >
          > BTW, I think you meant ^$GetClipBOARD$ not ^$GetClipBAR$ in your overview.

          Yes, I menat clipboard 8=D.

          >
          > This looks interesting but given the amount of coding required I am
          > wondering what is the advantage over using regular clips and a standard
          > naming convention?

          You have a point. But I got to the workaround in a series of steps, from working clips, clipbars, and libraries, that stopped working when I changed libraries in the cipbook. So my workaround became an add-on.

          Using the add-on as needed prevents breaking existing code, that calls UDFs without special workarounds.

          As to your comments about variables losing their value when crossing library boundaries, I'm fairly certain that variables do not retain their value when changing libraries voa far calls (including clipbar calls). I believe I have fooled myself into thinking I could retain a variable value, when in fact the clip restored it's value via a default mechanism (like ^$GetValue(default)$) or via passing a variable as an argument to a clip.


          Cheers,


          Eb
        Your message has been successfully submitted and would be delivered to recipients shortly.