LiveCode Forums.

I like the idea of a measure text command like I see in the widget code. Are you happy for me to expose this? What it would mean is we wouldn't need to put text into fields to find out the size it needs so I think it would be good for long list and tree management. What I'm proposing is we use relative to object to get the effective font attributes from the object:
it would be set to a width,height size.

Any thoughts?

I think something along these lines would be useful - although I do perhaps think it should be a function in the current syntax (the reason its a command in the widgets branch is because the mechanism the widget commands I added use cannot do functions!). How about: Here I propose <mode> to be:

• width - the default if not specified - returns just the width of the text
• size - returns the "width of text,ascent+descent"
• bounds - returns "0,-ascent,width of text,descent"

The reason for the 'mode' is that in some cases all you need is the width, in others the width and height but there are cases where you also need the ascent / descent (if you wish to align text of different fonts and sizes next to each other).

OK, I'll take a look at it.

I'm just about done with this... just writing up some docs now but wanted to check if there's any times other than the object not being open where the fontref will be nil? I'm throwing an object not open error if it's nil.

Also I wanted to point out that the practice of including a number in the error definition means that whoever is doing the merges will always need to check both error files to ensure those numbers remain sequential even if it merges cleanly... ah... merges and sequential numbers... reminds me of something

If the comments on each error are parsed then included in the IDE then the comments on each error become redundant. Or perhaps the error description should be included in the engine so we can implement error handling in standalones better?

OK here's the pull request if anyone's interested:
https://github.com/runrev/livecode/pull/129

It appears the comments on the errors are already being parsed so I think it's just the numbers that should be dropped because they are redundant.

Also I wanted to point out that the practice of including a number in the error definition means that whoever is doing the merges will always need to check both error files to ensure those numbers remain sequential even if it merges cleanly... ah... merges and sequential numbers... reminds me of something

Yup - it does.

It appears the comments on the errors are already being parsed so I think it's just the numbers that should be dropped because they are redundant.

They aren't redundant - an error once defined has a unique number which cannot change (some error codes are checked in the IDE, for example) in the current model of error handling. The reason for including them in the error's file is so that there is a direct reference for which error number is which error, and also to ensure that it isn't possible to accidentally change the error numbers.

@monte: I merged in this into develop a while ago - it will appear in 6.5-dp-1 which we're hoping to get out asap.

OK, would be good if we knew version numbers for the next release branch off develop for feature contributions so you didn't need to change our docs. Given the big jump can I assume it includes the graphics stuff?