the properties

[LCMark]

Hmm... Isn't htmlText a complete representation of styledText? At least in the context I'm using it in it's much easier to work with because I don't need to worry about encoding... for styledText I'd need to parse it for unicode and utf8 it... I do realise it's not just me using this thing and I could delete the key and add htmlText but htmlText is already there and if it doesn't lose any data then it would be good to stick with it...

Actually, yes, htmlText should be fine - for some reason I have it in my head its not fully faithful, but 5.5 should have made it so.

I agree with @mwieder about ID... I think that should be in there because we don't know the context of how and where the properties will be set and the error lock is on during setting anyway...

I only threw that out there as a potential suggestion... I guess it doesn't do any harm because, as you say, the id will be set if it can or just error-out silently.

Hmm... OK, I don't think it will impact me a great deal... it's a little frustrating that the data appears to be utf8 encoded no matter what and that's what I want to end up with but to get it I'd need to implement a whole separate property... I guess hasunicode() is my friend?

In regards to Unicode - internally the engine does use UTF-8 in places for convenience of implementation. However, the 'unicode' properties are host byte-order UTF-16 - and this is what should be returned.

Basically, if an object's 'hasunicode()' method returns true, it means that it should present unicode properties, rather than non-unicode ones.

Can you give me an example of overlapping properties that require both? I can't think of any at the moment.

I think the 'style' property overlaps with other flags on some objects - which is what I had in mind when I wrote that. I'll need to double-check.

[ As an aside, Unicode gets 'solved' by the refactor we are doing - rather than changing everything to UTF-8 internally which would cause all kinds of problems with efficiency and backwards-compatibility, strings are being changed to be an opaque MCStringRef type that can be either native or Unicode. This is a little more work, but will give a much better forward-compatibility experience - stacks that work with just native text should (for the most part) carry forward and 'just work' with Unicode text. ]

[monte]

So hasunicode() means it should return ALL unicode props even if only one has been set to unicode?

I changed the setprops method to set style among a couple of other thins first because otherwise it overrides other properties.. Is that what you mean?

[LCMark]

I changed the setprops method to set style among a couple of other thins first because otherwise it overrides other properties.. Is that what you mean?

Yes - that was the main example I had in mind.

So hasunicode() means it should return ALL unicode props even if only one has been set to unicode?

Hmmm - okay this is a little more involved than I thought.

The toolTip property of all controls is stored internally in UTF-8 : this should be presented as 'tooltip' if native, and 'unicodeToolTip' if it cant' be encoded as native.

The stack object has 'title' / 'unicodeTitle' : this is store internally as UTF-8 and should be presented as 'title' if native and 'unicodeTitle' if it can't be encoded as native.

The group and graphic objects have 'label' / 'unicodeLabel' : this uses the hasunicode() flag - if true it means unicode is required (i.e. the label isn't native).

The button object has 'label' / 'unicodeLabel' and 'text' / 'unicodeText' : if either of these properties need unicode then hasunicode() is true and they are both encoded as unicode internally (even if one could be native).
The button object also has 'acceleratorText' and 'unicodeAcceleratorText', however the acceleratorText is always native since you can't set 'the unicodeAcceleratorText'.

The easiest thing to do might be to fetch the unicode props in all these cases then run through something like 'canconverttonative()' (in button.cpp) - if it returns true, then return the native property rather than the unicode one.

[monte]

Hmmm - okay this is a little more involved than I thought.

Argh.. I just pushed relying on hasunicode for them all...

The easiest thing to do might be to fetch the unicode props in all these cases then run through something like 'canconverttonative()' (in button.cpp) - if it returns true, then return the native property rather than the unicode one.

I guess that's most likely to be consistent too... any reason I can't move canconverttonative to MCObject?

[LCMark]

Argh.. I just pushed relying on hasunicode for them all...

I know - I had forgotten it was a little more complicated - sorry about that :S

I guess that's most likely to be consistent too... any reason I can't move canconverttonative to MCObject?

How about an MCExecPoint method. Since properties are fetched into an ep, something like (not tested!):

Code: Select all

// Assumes the contents of the ep is UTF-16 and attempts conversion to native. If
// successful, the new contents is native and the method returns true, otherwise
// false and the contents remains unchanged.
bool MCExecPoint::trytoconvertutf16tonative()
{
    MCExecPoint t_other_ep;
    t_other_ep . setsvalue(getsvalue());
    t_other_ep . utf16tonative();
    t_other_ep . nativetoutf16();
    if (getsvalue() . getlength() == t_other_ep . getsvalue() . getlength() &&
        memcmp(getsvalue() . getstring(), t_other_ep . getsvalue() . getstring(), getsvalue() . getlength() == 0)
    {
        copysvalue(t_other_ep . getsvalue());
        return true;
    }
    return false;
}

This can be made more efficient in the future - but would mean the pattern for these props is something like:

Code: Select all

    getprop(..., ep, ...);
    if (ep . trytoconvertutf16tonative())
      ... put non-unicode prop into array (ep is native)
    else
      ... put unicode prop into array (ep is unicode)

[monte]

nice... I just pushed with this. Only a couple of changes to the new ep method from your code...

[mwieder]

I like this in theory, but wouldn't there be a performance hit on every getProp call?

[LCMark]

@mwieder : do you mean the unicode / native stuff? This is only when fetching 'the properties' property, and then only for the 3 or 4 properties that could be unicode or native.

[mwieder]

Ah. OK - so trytoconvertutf16tonative() wouldn't be called on every getProp call. That should be all right then.

[monte]

Right... it's only used 3 times:
- label (title of stack)
- text (of button only)
- toolTip

[LCMark]

Btw guys, I merged this into 'develop' yesterday - thanks Monte

[monte]

Unshared properties and the properties array...

So... if an object is in a shared group and has unshared properties who do those unshared properties belong to? The card or the object? If it's the object then shouldn't they be included in the properties array? Perhaps an array keyed on card ID? If it's the card then should they be included somehow with the cards properties array (quite a bit more complicated I think)...

Should the result depend on how the object is referenced (of background vs of card)???

[LCMark]

Well, whenever you get a property there is an implicit card reference even if you don't state it - 'the properties of button 1' will result in 'the properties of button 1 of this card'. So, unless you specify a card chunk you'll get the data for 'this card' of the stack the object is on.

I don't think 'the properties' is the place to return all the unshared data of an object - I think this should be got via different mechanism.

[ In regards to (internal) ownership, the control 'owns' the data for each card it is placed on ]

[monte]

OK, hmm... I can't think of a good name for the properties... the unsharedHilite seems like it should return not the sharedHilite... How about the unsharedHilites? the unshared[htmlText|text|unicodeText...]s ... not sure...

[LCMark]

We already have properties to fetch any shared or unshared data - i.e. the existing property names. At the moment, you can do this to get all the unshared data:

Code: Select all

repeat for each line tCardId in the cardIds of group tMySharedGroup
   put the htmlText of control id tMyControlId of card tCardId into tMyControlsUnsharedData[tCardId]
end repeat

Now, I realize your concern is efficiency but I really don't think adding lots of properties is the way to go (as, in the grand scheme of things they have very restricted utility).

In my opinion, the best way for lcVCS to get the data it needs is to add an import/export mechanism of objects that produce arrays with all the information that is required - which has been a work in progress for a while, but has stalled recently due to other commitments. (I'll try and start a topic about the direction this work is taking later on in the week - my todo list is quite long today...).