Inputbox prompt strings are clipped short without apparent reason

If it was just a matter of truncating at some maximum length I could deal with it. But even relatively short strings are truncated.
Here’e my best try yet on my borrowed mac:

  1. the prompts can contain NO spaces. Try adding them and see what happens.
  2. All prompts must be padded to the same length,
  3. All prompts must have minimum 5 character padding at right.
  4. displaying feet and inches will require extra work to replace spaces with dashes.
  5. No prompt can be larger than 25 characters.
  6. Title can’t be larger that 51 characters.
  7. No forward slashes in prompts.

Try this on mac: add spaces or remove padding to see what happens.

    xprompt = "X=292.1mm_____________"
    yprompt = "X=292.1mm>266.7mm_____"
    zprompt = "X=292.1mm>334.5mm_____"
	prompts = [xprompt, yprompt, zprompt]
    puts xprompt
    puts yprompt
    puts zprompt
        #set defaults
	defaults = ["","",""]
        #set list
	list = ["","",""]

        #set title
	titletext = "Enter Sizes, Increments (+|-) or Factors (*|/)"

        #Here is inputbox

	resultinputbox = UI.inputbox(prompts, defaults, list, titletext)

spaces work fine ;•)

xprompt = "X = 292.1mm".gsub(/ /, "\u00A0").ljust(100, "\u00A0")
yprompt = "X = 292.1mm > 266.7mm".gsub(/ /, "\u00A0")
zprompt = "X = 292.1mm > 334.5mm".gsub(/ /, "\u00A0")
prompts = [xprompt, yprompt, zprompt]

and the .ljust works from any single prompt…

it just gets weirder…
john

The problem on MAC with spaces only comes up when prompts get close to 25 characters.
Try editing my code above. I cant because I had to give my borrowed mac back to its owner.

Another discovery
The MAC inputbox automatically right justifies each prompt string so it is close to the entry field. This makes it more readable. The Windows input box keeps the prompt string left justified, so I often padded shorter prompts with leading spaces to get them right justified in Windows. This looked better but causes truncation when displayed on a MAC.

moved

Also trying to grasp Inputbox on Mac.
tested;
3 lines holding 2 groups (words) of 10 chars each separated by a space; input box displays only the first group.
The second ‘word’ of each line is displayed by adding a space and 4 more chars to the last one. But those added chars do not display.
updt:
Actually adding the chars to any line will have the same effect.
inputbox ([‘1234567890 1234567890’,‘1234567890 1234567890 1234’,‘1234567890 1234567890’], [“”], “Mac InputBox Length study”)

I could be wrong but to me this looks like line breaking with the additional lines hidden. “QwertyuiopQwertyuiop” which is just one word is shown with no problem in the screenshot but “Qwert yui opghjklQwertyuiop” gets it last word truncated. “Asdf ghjkl Asdf ghjklQwertyuiop” also gets the last word truncated while “Zxcvb nm Zxcvbnm” which is shorter than “QwertyuiopQwertyuiop” isn’t truncated.

My “solution” until this is fixed: Test for Sketchup.platform.
If OSX, then replace all spaces in prompts with underscores.

What happens if the non-breaking space character is used?

Yep. If enough non-breakingspaces are used on the last line, seems to work.

But what about non breaking spaces between words instead of usual spaces?

That is what I did; n-b spaces between words.
But still, several ones have to be added in order to make the line long enough not to be truncated.
At least those added spaces do not display.

This should have been corrected by Apple long ago !

So if you only add non breaking spaces between words but don’t pad with non breaking spaces ate the end there are still line breaks between the words?

Yes. In fact truncation can happen anywhere in a word, not only between them.
Seems like there is no other way but having the last line longer than any one above. So, for now, lines have n-b spaces between words and last one has padding added.

1 Like

I ended up here because this problem is still happening in SU2022 on the Mac… No words…

And SU2022 will not be fixed as it 2023 that is the current version.

It also seems that these nasty UI module bugs are very low priority for Trimble.

The oft repeated solution is to create your own inputbox using the UI::HtmlDialog class.

1 Like

As a workaround you can add trailing spaces to at least the first field to pad it out to the length of the longest field caption.

1 Like

Yes, that seems to be the only solution. Had to create something quickly for my client and at least it works fine on Windows (although the spacing is just awful).

I have a single field and I ended up adding another word on macOS (as the inputbox will ignore it). Anyway, I will code this properly using a UI::HtmlDialog pop-up.