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

Design error

Expand Messages
  • Axel Berger
    I just came across a design error in Notetab. I used to have a clip to show me the decimal and hex value of the character at the cursor. With NT doing the same
    Message 1 of 4 , Oct 26, 2012
    • 0 Attachment
      I just came across a design error in Notetab. I used to have a clip to
      show me the decimal and hex value of the character at the cursor. With
      NT doing the same whenever one character is selected it seemed to have
      become superfluous. Not so. In Regex NT only supports the hex (and
      octal) representation, but for e.g. the n-dash that's not what I'm
      given. I only get decimal and UTF, both of no use, and no hex. My old
      clip otoh was:

      ^!Set %varchar%=^$GetChar$
      ^!If ^$GetSelSize$ < 1 SKIP
      ^!Set %varchar%=^$StrCopyLeft("^$GetSelection$";1)$
      ^!Set %varchar%=^$CharToDec(^%varchar%)$
      ^!Info Hex: ^$IntToHex(^%varchar%)$ Dec: ^%varchar%

      I don't use UTF so that was not incorporated.

      Axel

      --
      Dipl.-Ing. F. Axel Berger Tel: +49/ 2174/ 7439 07
      Johann-H├Ąck-Str. 14 Fax: +49/ 2174/ 7439 68
      D-51519 Odenthal-Heide eMail: Axel-Berger@...
      Deutschland (Germany) http://berger-odenthal.de
    • Eric Fookes
      Hi Axel, No, this is not a design error but a choice. Showing too much information can be detrimental to the user experience, which is why the feature works as
      Message 2 of 4 , Oct 29, 2012
      • 0 Attachment
        Hi Axel,

        No, this is not a design error but a choice. Showing too much
        information can be detrimental to the user experience, which is why the
        feature works as you describe.

        I do realize that my design choices don't suit everyone. Trying to do so
        is an impossible mission.

        --
        Regards,

        Eric Fookes
        http://www.fookes.com/


        On 26/10/2012 12:17, Axel Berger wrote:
        > I just came across a design error in Notetab. I used to have a clip to
        > show me the decimal and hex value of the character at the cursor. With
        > NT doing the same whenever one character is selected it seemed to have
        > become superfluous. Not so. In Regex NT only supports the hex (and
        > octal) representation, but for e.g. the n-dash that's not what I'm
        > given. I only get decimal and UTF, both of no use, and no hex. My old
        > clip otoh was:
        >
        > ^!Set %varchar%=^$GetChar$
        > ^!If ^$GetSelSize$ < 1 SKIP
        > ^!Set %varchar%=^$StrCopyLeft("^$GetSelection$";1)$
        > ^!Set %varchar%=^$CharToDec(^%varchar%)$
        > ^!Info Hex: ^$IntToHex(^%varchar%)$ Dec: ^%varchar%
        >
        > I don't use UTF so that was not incorporated.
        >
        > Axel
        >
      • Axel Berger
        ... Alright, fair enough. Usage differs, but for me the most frequent reason to look up a strange character is to get rid of it. While there is
        Message 3 of 4 , Oct 29, 2012
        • 0 Attachment
          Eric Fookes wrote:
          > No, this is not a design error but a choice.

          Alright, fair enough. Usage differs, but for me the most frequent reason
          to look up a strange character is to get rid of it. While there is
          ^$DecToChar(Decimal)$, \xnn is much easier to type and for that I need
          the hex representation. No big deal, my old and trusted clip is still
          there, just seems a bit odd to me. UTF would be sensible in other
          editors, but with your single code page policy it isn't really.

          Axel
        • C
          Hi Eric Regarding this subject, I agree 101% with you. But do not forget that you and Alex and some other friends have the most great understanding of this
          Message 4 of 4 , Oct 29, 2012
          • 0 Attachment
            Hi Eric

            Regarding this subject, I agree 101% with you. But do not forget that you and Alex and some other friends have the most great understanding of this script language, but the NTP have a lot of powerful codes that are rarely used, and if we need to use some codes for the first time we lost time to really understand and to debug. Therefore, my suggestion is to include, in your good manual, few examples about some rarely used codes (that are in larger number, because the NTP are very powerful). This is very standard in debug system manuals.

            First, I use your NTP for more or less ten years or more, I dont remember.

            Second, you have a great software. He is the most powerful script/language for "texts" in the world, he is better than very famous languages. My continuous congratulation. As a matter of fact, I dont like his name (Editor) because he dont say really what is possible to do with your script language. Examples: I developed a powerful and experimental content (semantic) analyzer, using the NTP, that are running ok for years. And speaking of IT/business automation, I forget the quantity of correspondent clips that I created in these years, working automatically with the Web, any browser, any program, in real time.

            But NTP is missing a good debug. If we have at least two new codes

            ^$GetExecutionLineNumber$
            ^$GetClipLineNumber$

            will be possible to write powerful scripts to do ANY debug functions, including using his results as automatic inputs for EXCEL and more important, some powerful debug analyzers.

            Because we do not have a powerful debug in NTP, see this clip that I created to do my debugs (I include this Look code in any clip line number that I want to debug):

            ^!Clip Look Line;Code;v3;v4;v5;v6;v7;v8;v9;v10;v11;Search12;Search13;tccommand14;batname15;clipname16;dir17;comments18;openfile19;

            v3 up to 11: variable names, that you want to see his values
            12 and 13: Search one or two words in the open document(s), including using Regex (words are in the fields 12 and 13)
            14 = to execute a specific command in TC (the command name is in the field 14)
            15 = to execute a specific .bat in TC (the bat name is in the field 15) 16 = to execute a specific NTP clip (the clip name is in the field 16) 17 = to execute a specific DIR code (the directory name is in the field 17)
            18 = to show a comment at this specific line position (the comment is in the field 18)
            19 = to open a specific file (the file name in the field 19).
            Line = Clip line number, unfortunately a manual input, corresponding to the specific Clip line at this moment.

            This Look clip have two options:

            1. To stop in the line position, and show/print these results (using "P" instead of "Code")
            2. Do not stop in the position, and in the end show/print these results (all appended).

            As a matter of fact, I use the Look to create a lot of printed logs.

            Did you see how powerful will be this simple script, if including the above mentioned two ^$Get... codes?

            I know that the results from both codes ^$Get will show different numbers, but really if we have these both codes will be possible to write a script to fix this small problem. Very easy, as you realize.

            Finally, if any friend want to use or to expand the Look clip using his more powerful NTP knowledge, I will publish the Look clip in the Web.

            Best regards,
            JC.
            ------------------------------------------------
            --- In ntb-clips@yahoogroups.com, Axel Berger <Axel-Berger@...> wrote:
            >
            > Eric Fookes wrote:
            > > No, this is not a design error but a choice.
            >
            > Alright, fair enough. Usage differs, but for me the most frequent reason
            > to look up a strange character is to get rid of it. While there is
            > ^$DecToChar(Decimal)$, \xnn is much easier to type and for that I need
            > the hex representation. No big deal, my old and trusted clip is still
            > there, just seems a bit odd to me. UTF would be sensible in other
            > editors, but with your single code page policy it isn't really.
            >
            > Axel
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.