the properties

[LCMark]

Hmmmm - changing the image property setter is changing the behavior of the property although I guess text and filename are essentially the same property (in the same way as foreColor and forePattern are) so perhaps this is more 'correct' (and consistent with similar things elsewhere).

In regards to the name issue then it appears that there isn't a way to get empty for an object's name if it is unset - both the short name and name return abbrev id in this case. I guess, really, P_NAME should return P_ABBREV_ID (since it contains the control type), but if you ask for P_SHORT_NAME, it should return empty - as you are asking for just the name. Not sure what the ramifications of that change might be in user scripts...

[monte]

Seeing as it turns out setting the color to empty when there's a pattern doesn't lose the pattern then my change would make filename/text consistent with that. It just doesn't make sense to set a property to empty that's already returning empty to have any effect...

One of the problems is if you ask for the short name and get the abbrev id and try and use it you get an error...

Code: Select all

put the short name of button 1 into X -- X = "button id 1003"
put the icon of button X -- throws error

So perhaps there's less people relying on this quirk than we think... Also, perhaps it should just return "id 1003"...

A workaround is for only the properties to return empty if it's unnamed...

Code: Select all

case P_SHORT_NAME:
     if (isunnamed())
           ep.clear();
     else
           getprop(parid, P_SHORT_NAME, ep, effective);
     break;

[mwieder]

So perhaps there's less people relying on this quirk than we think

I actually have quite a bit of code that relies on this bug in order to step around it...

Code: Select all

put the short name of <object> into tControl
if word 2 of tControl is "id" then...

but if we can get this "fixed" then I'd happily revisit my code.

[monte]

An interesting point is that such code is not robust... someone might have a naming scheme: myobj id 3... Perhaps:

Code: Select all

if tControl is the abbrev id of <object> then...

Is it a bug though? I'm not sure... one other quirk here is short id is synonymous with id but name is synonymous with abbrev name and short name is only synonymous with name if there is no name... wrap your head around that one

I think there's a reasonable argument for changing it to just return 'id 1024' etc. That way it won't throw an error if you use it where you would use a name. This is exactly why I implemented the cardIDs of group because with cardNames you ended up having to handle this stuff...

I guess these decisions were made before I was born or something...

[LCMark]

It just doesn't make sense to set a property to empty that's already returning empty to have any effect...

That's a very succinct way to explain the rule with 'paired props' (i.e. ones where there are two props representing two sides of the same thing)

Is it a bug though? I'm not sure... one other quirk here is short id is synonymous with id but name is synonymous with abbrev name and short name is only synonymous with name if there is no name... wrap your head around that one

Well it seems to have been explicitly coded that way - although I can't really see a good reason. Particularly since, as you've pointed out, trying to do:

Code: Select all

  put the label of button "button id 1004"

Doesn't actually work.

I think there's a reasonable argument for changing it to just return 'id 1024' etc.

As far as I can see, this doesn't work either - when used just as 'button <expr>', control chunks only search for a match of the name property; or (it seems - looking at MCU_matchname), '<object type> "<name>"').

This is exactly why I implemented the cardIDs of group because with cardNames you ended up having to handle this stuff...

Well, using the cardIds also means you don't have to worry about two cards with the same name in a stack.

I guess these decisions were made before I was born or something...

I think we were both born at the time, just probably not using LiveCode

In regards to the name returning something that isn't a name when it's empty then that is a behavior that we could look into changing. If we made it so that the engine would correctly resolve "button empty", then having the short name return empty if the name is unset would be consistent with searching for any other name. Of course there might be some reason that having a control with an empty name and resolving like any other name is a bad idea - but I can' think of one at the moment...

How about, at the moment, we 'work-around' the name problem in 'the properties' (getproparray()) and keep the changes to filename/text (making them work like the other paired props). We can then try changing the 'empty' name behavior in the next (major) version - this at least gives more time to see if what effect such a change would have.

In regards to text/filename of image, should filename be preprocessed first, or should text? (Just to ensure there is a consistent ordering - like color/pattern).

[monte]

As far as I can see, this doesn't work either - when used just as 'button <expr>', control chunks only search for a match of the name property; or (it seems - looking at MCU_matchname), '<object type> "<name>"').

Ah... well... I didn't actually try it... still it at least seems more likely to work that abbrev id

As far as I can see, this doesn't work either - when used just as 'button <expr>', control chunks only search for a match of the name property; or (it seems - looking at MCU_matchname), '<object type> "<name>"').

Code: Select all

I think we were both born at the time, just probably not using LiveCode

Probably not... HC was well and truly dead before I started coding.

Code: Select all

In regards to the name returning something that isn't a name when it's empty then that is a behavior that we could look into changing. If we made it so that the engine would correctly resolve "button empty", then having the short name return empty if the name is unset would be consistent with searching for any other name. Of course there might be some reason that having a control with an empty name and resolving like any other name is a bad idea - but I can' think of one at the moment...

Hmm... the only thing I can think of that would be relying on this quirk is the IDE (script editor and inspector stack title etc)... I'm not sure I'd bother spending much time trying to resolve button empty... but if it's a case of just not throwing an error or something then it might be worth it...

Code: Select all

How about, at the moment, we 'work-around' the name problem in 'the properties' (getproparray()) and keep the changes to filename/text (making them work like the other paired props). We can then try changing the 'empty' name behavior in the next (major) version - this at least gives more time to see if what effect such a change would have.

OK, I've pushed it.

Code: Select all

In regards to text/filename of image, should filename be preprocessed first, or should text? (Just to ensure there is a consistent ordering - like color/pattern).

Well in the pull request I've put fileName in the pre-process list. I don't feel strongly either way about precedence other than it should be documented.

[LCMark]

Hmm... the only thing I can think of that would be relying on this quirk is the IDE (script editor and inspector stack title etc)... I'm not sure I'd bother spending much time trying to resolve button empty... but if it's a case of just not throwing an error or something then it might be worth it...

I think the change just needs to be made in MCU_matchname, so it would be simple to do. As I said I can't think of a reason why the name empty shouldn't be treated like any other name - after all, names aren't intended to be unique and I can't think of anywhere that relies on names being non-empty in the engine.

OK, I've pushed it.

Great - thanks.

Well in the pull request I've put fileName in the pre-process list. I don't feel strongly either way about precedence other than it should be documented.

Then filename over text it is then

[mwieder]

I can't think of anywhere that relies on names being non-empty in the engine.

The only thing I can think of that might cause problems is inheritance - you wouldn't want an empty button name to inherit the name of the card, etc. But if there's not concept of the "effective name" of an object then there shouldn't be a problem with that.

[LCMark]

After working around the text/filename issue in 'the properties' for 6.1, I've just merged the proper fix (Bug 10977) into 'develop' for the next major release. Whilst doing this I noticed that setting the filename to empty was causing a 'could not load image' error which seems a bit silly, so filed Bug 10980 and merged a fix for that into 'develop' for the next major release also.

I've also filed a bug about the name behavior - Bug 10981 - still not sure about that one in terms of breaking scripts so any thoughts and such on that would be appreciated.

[monte]

The only place I can see it being a problem are places that display an object reference to the user and don't care what it is... I had thought the inspector and script editor did this but I see I'm mistaken. Actually the inspector displays the bug by putting the abbrev id in the name field... The project browser and application browsers, however, definitely make use of it... they and anything like them would need to be updated to check for empty when getting short name...

I wonder if a workaround would be to use the effective short name to be the one that returns empty if a name isn't set??? It's kind of opposite to the way the effective works elsewhere...

[monte]

I've been integrating the updated properties into lcVCS and I've hit a few issues:
1. stack password and passkey should probably be removed from the properties... passkey being
2. I found that while padding is documented as a field property it's actually not one... it appears to be only a field chunk property
3. I found an odd bug. It appears the trytoconvertutf16tonative() method is doing something quirky to the element value in the array. LiveCode scripts can see the full value but either the buffer length or buffer both and length mergJSON gets is short... after getting the properties if I do something like put the text of theObject into tProperties["text"] then it works as expected. I can even do stuff like put "ssdsd"&tProperties["text"] into tProperties["text"] and what mergJSON sees is "ssdsd"&char 1 of tProperties["text"]...

I'll send a pull request regarding #1 and #2 but #3 is a bit of a mystery to me...

[FourthWorld]

I've been integrating the updated properties into lcVCS and I've hit a few issues:
1. stack password and passkey should probably be removed from the properties... passkey being.

Maybe. Having both lets you determine whether you'll have access to the script property.

[monte]

Hmm... getting the passkey seems to be undocumented but it appears to return true if you have access to the script in the current session. Both of these properties throw errors on community and both return virtual properties rather than actual values when getting them. I personally think these should be dealt with separately like script is.

[FourthWorld]

Hmm... getting the passkey seems to be undocumented but it appears to return true if you have access to the script in the current session.

You're right; I was thinking about the olden days when those properties contained non-Boolean values.

Since passkey is session-specific anyway, on further consideration I see no reason to maintain it in the array returned from "the properties".

Both of these properties throw errors on community and both return virtual properties rather than actual values when getting them. I personally think these should be dealt with separately like script is.

Unless the password could simply return empty in Community, if it's throwing errors I would agree it needs to go.

[monte]

3. I found an odd bug. It appears the trytoconvertutf16tonative() method is doing something quirky to the element value in the array. LiveCode scripts can see the full value but either the buffer length or buffer both and length mergJSON gets is short... after getting the properties if I do something like put the text of theObject into tProperties["text"] then it works as expected. I can even do stuff like put "ssdsd"&tProperties["text"] into tProperties["text"] and what mergJSON sees is "ssdsd"&char 1 of tProperties["text"]...

Ah... it seems to be a mistake in trytoconvertutf16tonative which I have fixed and included in the pull request https://github.com/runrev/livecode/pull/82

@FourthWorld there is an error lock on when setting the properties array so it's not critical if they throw errors but even setting the password to empty throws an error in community. I've removed them both in my pull request so we will see what @runrevmark's thoughts are.