the properties
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
Re: the properties
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...
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...
Re: the properties
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...
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...
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
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;
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: the properties
I actually have quite a bit of code that relies on this bug in order to step around it...So perhaps there's less people relying on this quirk than we think
Code: Select all
put the short name of <object> into tControl
if word 2 of tControl is "id" then...
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: the properties
An interesting point is that such code is not robust... someone might have a naming scheme: myobj id 3... Perhaps:
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...
Code: Select all
if tControl is the abbrev id of <object> then...
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...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: the properties
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)It just doesn't make sense to set a property to empty that's already returning empty to have any effect...
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: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
Code: Select all
put the label of button "button id 1004"
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>"').I think there's a reasonable argument for changing it to just return 'id 1024' etc.
Well, using the cardIds also means you don't have to worry about two cards with the same name in a stack.This is exactly why I implemented the cardIDs of group because with cardNames you ended up having to handle this stuff...
I think we were both born at the time, just probably not using LiveCodeI guess these decisions were made before I was born or something...
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).
Re: the properties
Ah... well... I didn't actually try it... still it at least seems more likely to work that abbrev idAs 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>"').
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
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...
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.
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).
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: the properties
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.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...
Great - thanks.OK, I've pushed it.
Then filename over text it is thenWell 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.
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: the properties
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.I can't think of anywhere that relies on names being non-empty in the engine.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: the properties
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.
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.
Re: the properties
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...
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...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: the properties
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...
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...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 9856
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: the properties
Maybe. Having both lets you determine whether you'll have access to the script property.monte wrote: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.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: the properties
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.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 9856
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: the properties
You're right; I was thinking about the olden days when those properties contained non-Boolean values.monte wrote: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.
Since passkey is session-specific anyway, on further consideration I see no reason to maintain it in the array returned from "the properties".
Unless the password could simply return empty in Community, if it's throwing errors I would agree it needs to go.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.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: the properties
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/82monte wrote: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"]...
@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.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/