Bugs, bugs, bugs - report them

If you come across bugs or anything that’s not working correctly in 0.9.14 please either post here or make a GitHub ticket. 0.9.15 is going to be fixes and making sure all the feature work on all three platforms.

1 Like

Here’s something that’s more of an ongoing annoyance that a bug, and maybe I’m the only one seeing this since I don’t remember any talk about it:

The cursor sometimes doesn’t use the right image. I often get the edit bar stuck as my cursor and have to fiddle around clicking on things to change it. I sometimes see the hand pointer and sometimes get a different random cursor image for clicking on things. I don’t have a recipe for causing the cursor to change or get locked so I don’t know where to look to fix it.

Yeah, I get that on the Mac some times too, not just in HXT too

Yeah, sorry - should have said that I’ve gotten that in LC for years now.

If you can pinpoint a working example, I’d be more than happy to try and fix it

Just saying that I cannot remember seeing this on Windows ever. :relieved_face:

Lucky you :smiley: I haven’t seen it yet on either Windows or Linux but have seen it on macOS (and not just in HXT)

In HXT 0.9.14 the project browser does not scroll anymore. Just manually dragging the scrollbar with the mouse moves the PB.

If you have the mouse in the blank area of the Project Browser, it does scroll, just not when the cursor is over text.

default button in answer dialogs do not trigger when pressing enter or return key

Line numbers in the script editor are not visible

Can you let me know the settings you have for the script editor where you are not seeing the line numbers

That cursor thing may be related to the script editor. Common trigger:

create a new stack, insert button
edit the script of the button
move the cursor back over the test stack
most times it's the positioning arrows or = cursor
and back over the script editor (mostly its the edit bar)
and back to the test stack (weird again)

Sometimes this will clear up soon. Sometimes it’s just annoying.

do ... as "JavaScript" — “Language not installed”

Running HXT 0.9.14 on macOS (Apple Silicon). Calling do "encodeURI(...)" as "JavaScript" throws:

alternate language not found

My guess is that on macOS this routes through OSA / JXA (JavaScript for Automation), which is a completely different engine from a browser JS context and doesn’t expose browser globals like encodeURI. So either JXA support was never reliable for this use case, or something changed in the OSA bridge.

Questions:

  • Is do ... as "JavaScript" on macOS officially supported?
  • Is there a recommended in-engine alternative for URL encoding a string?

For now I’ve routed around it with a custom bbencode function doing percent-encoding manually, but it would be useful to know the intended behavior.

Thanks —
Bill

URLEncode should give you what you’re looking for.

It does work on Intel versions from LC (tested 9.6.12, 10.0.2, Create 1.0dp8)

I do remember a few years ago trying URLencode for my task and landed on the JS call.

Interesting to note - Now that I have Claude helping me - a lot of my previous teeth gnashing has gone away!

Here is what Claude says The problem with URLEncode for your use case:

It encodes spaces as + instead of %20, and it’s not RFC3986 compliant. LogTen’s URL scheme is a logten:// deep link, not an HTML form POST — so + for spaces would likely break it. That’s why the RFC3986 wrapper (urlEncodeRFC) exists, and that’s essentially what your uriEncode function does.

Comparing the three approaches:

URLEncode("hello world")     → "hello+world"        ← wrong for URLs
urlEncodeRFC("hello world")  → "hello%20world"       ← correct
uriEncode("hello world")     → "hello%20world"       ← correct

So the Discourse answer is: yes, URLEncode exists in HXT, but it’s not suitable for URL encoding a deep link payload — you’d need the RFC3986 wrapper, which is essentially what you already built as uriEncode.

Your uriEncode is the right tool. The only question worth asking is whether your implementation and urlEncodeRFC produce identical output — if so, you could swap in urlEncodeRFC and drop your custom function, or just keep uriEncode since it’s already proven working.

Do you remember how you implemented uriEncode? Worth comparing the two side by side to make sure they’re equivalent before deciding whether to consolidate.

Here is the function that I came up with to do the work in-house.


function uriEncode pStr
   put "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_.!~*'()" into tSafe
   put textEncode(pStr, "UTF-8") into tBytes
   put "" into tResult
   repeat with i = 1 to length(tBytes)
      put charToNum(char i of tBytes) into tByte
      if tByte > 0 and tByte < 128 and char i of tBytes is in tSafe then
         put char i of tBytes after tResult
      else
         put "%" & format("%02X", tByte) after tResult
      end if
   end repeat
   return tResult
end uriEncode


  • Bill

The docs for urlencode have a function to generate the RFC value you need:

function urlEncodeRFC pString
    if pString is strictly a string then
        put textEncode(pString,"UTF-8") into pString
    end if
    put URLEncode(pString) into pString
    replace "+" with "%20" in pString
    return pString
end urlEncodeRFC

A little simpler than what Claude suggested.

1 Like