Inputbox prompt strings are clipped short without apparent reason

Developers Ruby API
1

I can’t see any pattern, but on El Capitan, SU 2016 Pro, some of my Inputbox prompts are being cut short.

For example, if I put in:

 prompts = [ "Qwert yui opghjklQwertyuiop", "Asdf ghjkl Asdf ghjklQwertyuiop", "Zxcvb nm Zxcvbnm", "QwertyuiopQwertyuiop"]
 defaults = ["First", "Two", "Three", "Four"]
 list = ["First|Second|Third|Fourth|Fifth", "", "", ""]
 results = UI.inputbox(prompts, defaults, list, "Prompt string clipping")

what I get out is truncated - sometimes at the second space, sometimes later. This is the output from the above input.

Both the first and second prompt strings are cut short in this example. The third and fourth aren’t.

Try copying and pasting the above into your Ruby console, and see if you experience the same truncation.

I’ve tried variations of the number of characters between spaces, and where the spaces come, but can’t see any pattern to it.

Any ideas how to get round this? Or indeed, why it is happening in the first place?

I can’t find any other references to this issue using Google generally, or on this forum. Is there a word length limit?

Has it anything to do with the first input being a drop down list?

2

your first needs to be the longest…

don’t ask…

actually do ask…

john

3

Can I pad it with spaces?

But, isn’t my first here the longest already?

4

it’s very weird and I think finally I worked it out the other night, but it fell apart for translations so I binned it…

trying to remember my test…

it did rely on adding whitespace + a char…

something like…

'XxxxXxxxXxxxXxxxX' + ‘…:’

as you add periods you see more X’s…

then I translated one string and it all collapsed…

john

5

If it looks like a bug, clicks like a bug, and behaves like a bug, IS it a bug?

6

it’s been like this for awhile…

maybe from day one…

I usually use WebDialogs as they are more compliant…

john

7

I’ve been put off trying Web dialogues because at least early descriptions of how to make them looked horribly complicated.

Are they now easier?

8

they were always easy on a mac, complying with IE was always a pain, and porting from an IE html generated most of the frustration seen on the forums…

john

9

If created on a Mac, then, do they work in IE?

Maybe now I have a Mac, I should look again at Web Dialogues

10

there’s the rub…

should do…

john

11

Well, I still have a Windows 7 laptop, so could at least test there…

12

what versions are you targeting?

if it’s HTML5 compatible, life is easier…

I also use mm instead of px, which keeps thing easier for retina etc…

john

13

heres your example with what I was doing…

  prompts = [ 'XxxxxXxxxxXxxxxXxxxxX'+':        ', 'XxxxxXxxxxXxxxxXxxxxX', 'XxxxxXxxxxXxxxxXxxxxX', 'XxxxxXxxxxXxxxxXxxxxX']
 defaults = ["First", "Two", "Three", "Four"]
 list = ["First|Second|Third|Fourth|Fifth", "", "", ""]
 results = UI.inputbox(prompts, defaults, list, "Prompt string clipping")

add or subtract spaces in the add…

john

14

I’d be targeting relatively recent versions of Safari and IE, but possibly SU at least back to v2014, maybe even v8 - there still seem to be quite a lot of Pro users who haven’t needed to upgrade since.

But even with this quirk in Inputbox, it may be sufficient for present purposes. It seems weird - I can’t imagine what coding quirk is causing this issue, nor (if it is a bug) why it hasn’t been noted and fixed.

I can see from the very long thread here about Trusses that you can do real wonders with Web Dialogues, but I don’t need anything fancy. Just half a dozen or so input settings popping up on a R-click in a Tool I’m working on, slowly.

I can live with the quirk - just wish it wasn’t there, and that I could work out WHY it behaves as it does - it just makes no sense to me at the moment.

Will experiment a bit with your example, to see if I can figure out what’s going on.

Still not quite clear what you meant about making the first entry the longest one. Didn’t really understand that, or its impact.

I would like to have the possibility of a second language - how does one use in in the prompts? A separate function call to Language Handler for each separate prompt, I guess - I’ve seen it in use in other contexts, but never actually coded for it myself.

PS. I’ve played around a bit with your example. I wondered if the long stretch of spaces is somehow ‘going under’ the input field, whether text box or drop down? It’s behaving a little like that - as if right justifying from the right hand edge of the combo or text box.

Even that explanation doesn’t quite work. I can leave out the ‘+’ and the colon, just have lots of trailing spaces in the prompt string, then ALL the non-space characters to the left of the string of spaces display, but none of the spaces.

Weird!

Haven’t tried swapping the first and second fields, so the first field is a text input box instead of a drop down list. But haven’t time to try more now.

At least I now have a workaround - add lots of trailing spaces to first (and maybe later?) prompt text strings.

15

You may wish to look at ThomThom’s SKUI interface for Webdialogs.

1 Like
16

Late to the party, but I think what happens is this:

  1. The inputbox uses “break at whitespace” logic to split each prompt into words.
  2. The inputbox chooses the width of all the prompt fields based on the longest first word in any prompt, up to an unspecified maximum pixel width for the as-rendered text.
  3. The other prompts then get truncated at whatever word boundary will fit within the width chose in step 2.
1 Like
17

Thank you. Already had a quick glance.

I ought at some point to learn how to use Web Dialogs, but the Input box
will be good enough for immediate purposes, especially now I have a work
around for the truncation issue. I want to progress on other fronts in the
Tool first.

18

I’ve been changing one of mine over to a WebDialog and there are a few advantages, other than length of text…

512×512 308 KB

checkboxes, radio buttons and inline help are all available…

the help gif’s are a quick lash up…

john

1 Like
19

My input boxes all work fine on Windows, But now Mac customers are reporting truncation.
Try this code snippet and tell me if it fits your theory. I’m padding some prompts with spaces so all prompts are right justified… Initial case has all min values equal to all max values. Try also running where mins are not equal to maxes. IIf someone can try on a MAC it would be revealiing:
`` ruby
# inital case where mins equal maxes
sizexmin = 10.5
sizexmax = 10.5
sizeymin = 20.5
sizeymax = 20.5
sizezmin = 30.5
sizezmax = 30.5

if sizexmin.round(1) == sizexmax.round(1)
	xprompt = "                   X size is: " + sizexmin.to_l.to_s + "  "
	else
	xprompt = "X sizes from " + sizexmin.to_l.to_s + " to " + sizexmax.to_l.to_s + "  "
	end
	
	if sizeymin.round(1) == sizeymax.round(1)
	yprompt = "                   Y size is: " + sizeymin.to_l.to_s + "  "
	else
	yprompt = "Y sizes from " + sizeymin.to_l.to_s + " to " + sizeymax.to_l.to_s + "  "
	end
	
	if sizezmin.round(1) == sizezmax.round(1)
	zprompt = "                   Z size is: " + sizezmin.to_l.to_s + "  "
	else
	zprompt = "Z sizes from " + sizezmin.to_l.to_s + " to " + sizezmax.to_l.to_s + "  "
	end
	prompts = [xprompt, yprompt, zprompt]
        #set defaults
	defaults = ["","",""]
        #set list
	list = ["","",""]

        #set title
	titletext = "title"

        #Here is inputbox

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

``

It’s supposed to look like this

Barry Milliken

20

I have other inputboxes where I inserted a leftmost period before the space padding.
No Mac user has reported problems with them.
If some one with a MAC would try that it could solve the problem.