Skip navigation

With CS5, some things have changed

Oct 3, 2010 1:50 AM

  Latest reply: Econometric, Oct 13, 2011 7:13 AM
Branched to a new discussion.
Replies 1 2 3 Previous Next
  • Currently Being Moderated
    Jan 25, 2011 10:18 PM   in reply to brifilone

    Instead of 'rectangle "photo1"', you need to use 'rectangle 1 whose label is "photo1"'.

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 29, 2011 2:13 PM   in reply to Harbs.

    I noticed today the the Object Model for CS4 has xmlItems.ItemByName, but the Object Model for CS5 does not. I'm trying to work out how to reference an XML Element by name in CS5. xmlItems.item("myElementName") doesn't work. Any ideas?

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 30, 2011 3:35 AM   in reply to Harbs.

    Interesting finding. I was sure that Adobe had'nt changed anything regarding to XML in CS5. As far as I can see/test your observation is correct.

     

    I would suggest to use the class XMLElement instead of working with the superclass XMLItem.

     

    Given this structure:

     

    <root>
         <child/>
    </root>
    

     

    I would use in CS3/4/5:

     

    app.activeDocument.xmlElements[0].xmlElements.itemByName("child");
    

     

    Working, but strange:

     

    app.activeDocument.xmlItems[0].xmlElements.itemByName("child");
    

     

    regards,

    gregor

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 31, 2011 1:32 PM   in reply to grefel

    Thanks, Gregor. Your proposed solution works for me in this case. Thanks for the help.

     
    |
    Mark as:
  • Currently Being Moderated
    Feb 5, 2011 9:22 AM   in reply to Harbs.

    Hi,

     

    Harbs wrote:

     

    function(){return A.apply(null,[this].concat($A(arguments)))}

    Here's the first two (and probably the most significant) of the changes:

     

    1) PageItem.parent: In previous versions, the parent of top-level page items were the Page that the PaeItem resided on. In CS5, this was changed (for increased performance), and the parent is now the PageItem's Spread. Together with this change, a new property "PageItem.parentPage" was added which returns the page that the PageItem is drawn on. parentPage works for nested PageItems as well, so this new property will do away with the need for a lot of the "findPage" functions that we've all been using!

     

    Is this the case even if I use script versioning? In other words, will CS5 return a Spread for textFrameX.parent even if I included versioning to make it be like CS4?

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 4, 2011 2:58 PM   in reply to Harbs.

    Hi all,

     

    we just tracked down a bug to the E4X implementation in ExtendScript. Fixed in CS5, but unfortunately that project is still CS4.

     

    First, be assured that below syntax is no typo - for details see the XML section in the JavaScript Tools Guide. The code implements different approaches to initialize a simple XML object (the ExtendScript brew, not InDesign's XMLElement) with a single element and text content. The curly brackets within the embedded XML literal are a way to pass on JavaScript expressions.

     

    The only problem here - some kind of conversion is taking place under the hood. Speaking in InDesign character codes, the paragraph end character (13) is silently converted into a forced line break (10). Not good if this XML is later returned into InDesign ...

     

    Dirk

    ( function () {   var aCRbLFc = "a\rb\nc";   $.writeln(aCRbLFc.charCodeAt(1),"/",aCRbLFc.charCodeAt(3));   // => 13,10   // first attempt / redundant XML wrapping.   var xml = new XML(<tag>{aCRbLFc}</tag>);   var hmm = xml.child(0).toString();   $.writeln(hmm.charCodeAt(1),"/",hmm.charCodeAt(3));   // => 10,10   // second attempt / straight XML literal   var xml = <tag>{aCRbLFc}</tag>;   var hmm = xml.child(0).toString();   $.writeln(hmm.charCodeAt(1),"/",hmm.charCodeAt(3));   // => 10,10   // inconsequent, but works:   var xml = new XML(<tag/>);   xml.appendChild(aCRbLFc);   var hmm = xml.child(0).toString();   $.writeln(hmm.charCodeAt(1),"/",hmm.charCodeAt(3));   // => 13,10 } )();

     

    Edit: formatting attempt

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 8, 2011 11:49 AM   in reply to Harbs.

    In case anyone's interested: In the VB object model (not sure of anything else) the idTextWrapTypes was changed to idTextWrapModes.

     

    Not sure why, but there 'tis.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 10, 2011 7:40 PM   in reply to Harbs.

    A couple of other things I've noticed:

     

    1. The Book.exportFile() parameters have changed (which bring them more in line with Document.exportFile()), so:

     

    CS4: myBook.exportFile(myPdfFile, false)

    CS5: myBook.exportFile(ExportFormat.PDF_TYPE, myPdfFile)

     

    2. The regular expression engine seems to have been changed slightly, in CS5 you now have to escape pipes.

     

    Consider the expression:

     

    $.writeln('test'.replace(/|/g, '|'));

     

    CS4: 'test'

    CS5: '|t|e|s|t'

     

    You have to escape the pipe like this:

     

    $.writeln('test'.replace(/\|/g, '|'));

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 29, 2011 11:21 PM   in reply to Harbs.

    Hi Harbs,

    2) PageItems.itemByName(): With the new layers panel comes a name property for PageItems. In previous versions PageItems.itemByName() would return the page item with the specified label in CS5, it will return the page item with the specified name (which can be set in the Layers Panel). There is no longer a quick-and-easy way to get page items by their label using the 7.0 scripting DOM.

    I can able to access a pageItem directly by its name instead of their label.

     

    For example by using the following code I can able to access a textFrame directly by its name (which is already set in the layers panel).

     

    var mytextFrame = app.activeDocument.pages.item(0).textFrames.item("FirstTextFrame");

    alert(mytextFrame.contents);

     

    ---------

    Green4ever

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Mar 30, 2011 12:52 AM   in reply to Green4ever

    Yes, that is the point. But prior to CS5 you used to be able to use the script label as the parameter, and now you cannot.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 31, 2011 1:18 AM   in reply to John Hawkinson

    Hi All,

    I have included glue code.jsx in my CS5 Scripting project.

    Because of this app.scriptPreferences.version = 6 command, textFrame.name property becomes invalid in CS5 scripting.

     

    FYI...... I got the "glue code.jsx" from the "XML Rules" folder.

     

    I think, Since there is no changes made to xml objects, the version of this script is not changed. Can I change it to version = 7 or is there anyother way to overcome this problem?]

     

    --------------

    Green4ever

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 18, 2011 12:24 PM   in reply to Harbs.

    So far, I've slept through all the CS5 activity because our customers have been using CS3 and CS4, but now, some of them are putting their toes into the CS5 water and so I'm finally paying attention to what is now the release before last (ah well).

     

    According to the CS5 OMV, Text.contents returns either a String or a SpecialCharacters enumerator. But this code is failing on me:

     

    var txtSample = oSetText.contents.replace(/\t/g,"[Tab]");

    because contents is returning an array.
    Here's what the JS Console has to say:
    oSetText.contents
    Result: Linda [stroke survivor]
    “If you don’t have a proper wheelchair, that is when you really feel that you are disabled. But if you have a proper wheelchair, which meets your needs and suits you, you can forget about your disability.”
    Faustina [person with paraplegia]
    oSetText.contents.constructor.name
    Result: Array
    oSetText.contents.length
    Result: 1
    oSetText
    Result: [object Text]
    Anbody else seen this? Or am I suffering from a third-party plug-in induced weirdness?
    Dave

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 18, 2011 12:50 PM   in reply to Dave Saunders

    I think I see the cause. I typed:

     

    This is a test.

     

    into a text frame, and selected it.

     

     

    app.selection[0]

    Result: [object Paragraph]

     

    app.selection[0].texts[0]

    Result: [object Text]

     

    app.selection[0].texts[0].contents

    Result: This is some text.

     

    app.selection[0].texts[0].contents.constructor.name

    Result: String

     

    app.selection[0].parentStory.characters.itemByRange(0,-1).texts[0]

    Result: [object Text]

     

    app.selection[0].parentStory.characters.itemByRange(0,-1).texts[0].con tents

    Result: This is some text.

     

    app.selection[0].parentStory.characters.itemByRange(0,-1).texts[0].con tents.constructor.name

    Result: Array

     

     

    It appears that using itemByRange across a range of text is at the root of the issue here because this second construction is akin to what I had done in the other script.
    To be blunt, this looks like a bug to me, but as long as it is consistent, I can work with it.
    Dave
     
    |
    Mark as:
  • Currently Being Moderated
    Apr 18, 2011 6:07 PM   in reply to Dave Saunders

    The solution (which works in at least CS4 and CS5) is to use getElements():

     

    app.selection[0].parentStory.characters.itemByRange(0,-1).texts[0].get Elements()[0].contents.constructor.name

    String

     

    However, in CS4 and earlier, the use of getElements here was not necessary.

     

    Dave


     
    |
    Mark as:
  • Currently Being Moderated
    Apr 19, 2011 12:44 PM   in reply to Dave Saunders

    Not actually a bug. This is a side-effect of a request that (wait for it, wait for it) I made two and a half years ago. At the time, I was bemoaning the fact that when you used everyItem() it didn't always return a collection (if there were only one of the items in question). Well, now it does and so does itemByRange.

     

    Thinking back to an earlier time, it always had struck me as rather mysterious that:

     

    myText.characters.itemByRange(m, n).texts[0]

     

    returned a singular text reference. Well, now it doesn't. It returns a collection of one text object. So:

     

    myText.characters.itemByRange(m, n).texts[0].getElements()[0]

     

    gives you that text object, which isn't such a big price to pay for consistency elsewhere.

     

    Dave

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 19, 2011 8:56 PM   in reply to Dave Saunders

    Thanks Dave for pointing out these hidden pitfalls.

     

    The itemByRange() method has always seemed unpredictable to me, especially with text objects. For example:

     

    app.selection[0].parentStory.words.itemByRange(0,-1).characters[0].co ntents

     

    returns only the first character of the first word (in CS4 and CS5), while:

     

    app.selection[0].parentStory.words.everyItem().characters[0].contents

     

    returns —as expected— an array that collects the 1st character of each word. Thus, itemByRange() may integrate the 'range' as a single block of data and does not produce, in that case, a collective specifier.

     

    In addition, the texts collection is really mysterious. In your example, the specifier:

     

    var spec = app.selection[0].parentStory.characters.itemByRange(0,-1).texts[0];

     

    should finally be resolved as a range of characters. Indeed, both ID CS4 and CS5 return a character-to-character path when you test this:

     

    alert( resolve(spec.toSpecifier()).toSpecifier() );

     

    However —as you have discovered— spec is treated as a collective specifier in CS5, so spec.contents produces an array of one string, while spec is a singular specifier in CS4. So it's sure that something has changed in the implementation of the .texts method, and we probably will find other side effects...

     

    A final note: technically we cannot say that myText.characters.itemByRange(m, n).texts[0] returns a 'collection'. The returned value is actually a Text specifier (versus a Texts collection). What you found is that, in CS5, this can be a collective specifier, in that any underlying property is returned through an array although the DOM object has in fact a single receiver.

     

    @+

    Marc

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 20, 2011 1:19 PM   in reply to Marc Autret

    Thanks Marc.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 29, 2011 4:46 AM   in reply to Harbs.

    Just found another really unfortunate change in CS5. It is no longer safe to issue:

     

    myTextFrame.lines[-1].baseline

     

    even when the text frame is known to contain at least one line because if that line contains a partial table that is not completely set (i.e., the story goes overset before the end of the table) you'll get "Invalid request in the current state".

     

    Possibly worse, if the table is completely set, rather than get the bottom coordinate of the part of the table in the text frame, you instead get the baseline of the actual bottom of the last row of the table no matter which text frame it might actually be in on whichever page.

     

    A really sad state of affairs that wipes out my script that does vertical justification of tables.

     

    Dave

     
    |
    Mark as:
  • Currently Being Moderated
    May 3, 2011 8:58 PM   in reply to Harbs.

    Apologies for cross posting this to both mailing list and forums, I'm not sure what most people are using.

     

    Just starting to look at moving the company from CS3 to CS5/5.5 and updating the scripts has been, well, interesting.  The inability to directly refer to page items via their Label has been quite a challenge as EVERYTHING we do names frames and subsequently refers to them by that name.

    One thing that has me stuck is why the following doesn't throw an error in a try block if the frame doesn't exist.

     

    set myFrame to item 1 of all page items whose label is "kim"

     

    I simply end up with an undefined variable. I would have thought if it didn't exist and myFrame was undefined an error should be returned.

     

    Am I missing something here or is this expected behaviour?

     

    I've just found another issue regarding restoration of styles to a frame. In CS3 we used to simply get the parent story properties from the frame, place the new text and then reapply the properties to restore the style. In CS5 this breaks as it simply applies the default paragraph style despite the properties holding all the individual style elements. I'm thinking this will necessitate applying individual properties (font, leading, tracking, kerning, etc etc) and that's gonna be horrible. If someone has a workaround for this I would appreciate it.

     

    It's been a long time since I wrote these scripts and there's a LOT of work in updating them to follow the new syntax - this is going to be a far more substantial task than I was expecting.

     

    cheers

    'k

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    May 3, 2011 11:00 PM   in reply to kimtorch
    It's been a long time since I wrote these scripts and there's a LOT of work in updating them to follow the new syntax - this is going to be a far more substantial task than I was expecting.

    Perhaps you should consider using:

     

    --Set to 5.0 scripting object model
    set version of script preferences to 5.0
    

     

    until such time as you need to make serious use of CS5 features?

     

    One thing that has me stuck is why the following doesn't throw an error in a try block if the frame doesn't exist.

     

    set myFrame to item 1 of all page items whose label is "kim"

     

    I simply end up with an undefined variable. I would have thought if it didn't exist and myFrame was undefined an error should be returned.

     

    Am I missing something here or is this expected behaviour?

     

     

    It is indeed expected!

     

    A "whose" filter in AppleScript is permitted to return a null list. Errors are only supposed to be thrown in fairly serious errors. Depending on how you try to use the myFrame it might generate an error later though...

     
    |
    Mark as:
  • Currently Being Moderated
    May 3, 2011 11:38 PM   in reply to John Hawkinson

    Well it's certainly returning an error when used later

     

    And there's the rub, in the CS3 version there was no problem simply checking to see if the frame existed but with the variable assignment failing without error the existence check naturally fails as well. I have coded a (fairly clunky) workaround which I think will be reliable but I still think returning an error when trying to assign a non-existent object to a variable makes sense.

     

    With regards using the v5 Scripting, I figure I may as well just bite the bullet and get it done. We're probably a few months away from upgrading (and I'm the one who decides so it can be further postponed) so it's just a matter of getting it all done.

     

    I like fiddling around but when I haven't looked at the scripts in probably 5 years it can take a while to get back into the swing of things

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 7, 2011 2:43 AM   in reply to Harbs.

    With a script that worked OK in CS4 I now find that when I set the strokewidth of a frame to 0 the result is a frame having a stroke of 1 pt, using the default TextFrame Object style. In both cases I used the same template file to start with so the Object Style is somehow changed or is now applied and not inprevious versions ? Do I need to set the ObjectStyle to None on all frames in CS5 to avoid this ?

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 7, 2011 3:10 AM   in reply to RoelofJanssen2

    Just found out myself that just after setting frame.strokewidth = 0 the value for frame.strokewidth is actually 1 pt; if I set strokewidth = 0.000001 then the value returned is actually 0.000001 pt so will show as 0 in InDesign dialogs.
    So now my question is: how to set strokewidth to zero in InDesign CS5 ?

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 7, 2011 3:10 AM   in reply to RoelofJanssen2

    RoelofJanssen2 wrote:

     

    With a script that worked OK in CS4 I now find that when I set the strokewidth of a frame to 0 the result is a frame having a stroke of 1 pt, using the default TextFrame Object style. In both cases I used the same template file to start with so the Object Style is somehow changed or is now applied and not inprevious versions ? Do I need to set the ObjectStyle to None on all frames in CS5 to avoid this ?

    There is no StrokeWidth - it ALWAYS was StrokeWeight - 2.0.2/CS1/CS2/CS3/CS4/CS5:

     

    Property StrokeWeight As Variant
        Member of InDesign.TextFrame
        The weight (in points) to apply to the TextFrame's stroke. Type: Unit (Double or String)

     

    robin

    www.adobescripts.co.uk

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 7, 2011 2:29 PM   in reply to John Hawkinson

    John Hawkinson suggested that changing the version in the script preferences could give one the ability to use properties the way we used to (i.e., set the properties of object A to the properties of object B). Sadly, this isn't the case in CS5 and CS5.5--it's one of those changes that defies versioning--so you're reduced to using other means. I should revise that a bit--*some* properties will transfer; it's important stuff like fill and stroke options won't.

     

    I wish I'd caught this while I was still at Adobe, but I was working on other stuff during CS5. I can't believe that this big a mistake was made without someone else inside the company noticing.

     

    Thanks,

     

    Ole

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 7, 2011 4:03 PM   in reply to Harbs.

    Hi Harbs,

     

    My point was that you were once able to quickly apply all of the formatting of one object to another object, and now you can't--without further work, anyway. Yes, it's almost certainly a problem of the sequence in which items in the properties record are applied. But it shouldn't have changed.

     

    I do have an example of a change that can be overcome with script versioning--the stacking order of items on a layer. It's possible to end up with mulitple page items with the same index(!)--I think it's a problem that's to do with documents coming from old versions of InDesign, or documents with pasted Illustrator paths--I'm not sure. Whatever causes it, it's something that survives export to IDML and back. When you iterate over the page items in a layer with this problem in CS5/CS5.5, you'll see something like this (this is reverse iteration--counter is counting down from layer.pageItems.length):

     

    Counter: 62 Index: 60 ID: 4679
    Counter: 61 Index: 59 ID: 4682

    ...

    Counter: 3 Index: 1 ID: 4761
    Counter: 2 Index: 0 ID: 4762
    Counter: 1 Index: 1 ID: 4919
    Counter: 0 Index: 0 ID: 4680

     

    Isn't that crazy? The counter and the index are out of synch. What's more, ID: 4680 and ID:4919 are at the *back*--they should be at the start of the list. If you're trying to rebuild the stacking order of the objects in some other place (like, in a custom FXG or SVG export, in my case--both formats where stacking order depends on output order), this can drive you insane.

     

    But...switch back to version 6.0 (CS4) before doing the iteration, and you get the items back in the correct back-to-front stacking order:

     

    Counter: 62 Index: 1 ID: 4919
    Counter: 61 Index: 60 ID: 4679
    Counter: 60 Index: 0 ID: 4680
    Counter: 59 Index: 59 ID: 4682

    ....

    Counter: 3 Index: 3 ID: 4759
    Counter: 2 Index: 2 ID: 4760
    Counter: 1 Index: 1 ID: 4761
    Counter: 0 Index: 0 ID: 4762

     

    ...even though the indices are clearly messed up. I'm not sure anyone else will ever face this particular problem, but it's cost me enough lost sleep that I thought I'd better mention it here!

     

    Thanks,

     

    Ole

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Sep 8, 2011 6:53 AM   in reply to Olav Kvern

    Ole:

    John Hawkinson suggested that changing the version in the script preferences could give one the ability to use properties the way we used to (i.e., set the properties of object A to the properties of object B). Sadly, this isn't the case in CS5 and CS5.5--it's one of those changes that defies versioning--so you're reduced to using other means. I should revise that a bit--*some* properties will transfer; it's important stuff like fill and stroke options won't.

    My claim was intended to be much more narrow, and I'm a bit confused how you thought I was referring to property transfer. I was really just talking about the ability to index objects by their script label.

     

    That is, given a TextFrame labelled "foo", in CS5:

     

    app.activeDocument.textFrames.item("foo").contents
    Error: Object is invalid
    

     

    However, if one sets the version preferences:

     

    app.scriptPreferences.version=6.0
    Result: 6
    app.activeDocument.textFrames.item("foo").contents
    Result: Foobar
    

     

    So that does seem to work.

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 8, 2011 7:47 AM   in reply to John Hawkinson

    John Hawkinson wrote:

     

    However, if one sets the version preferences:

     

    app.scriptPreferences.version=6.0
    Result: 6
    app.activeDocument.textFrames.item("foo").contents
    Result: Foobar
    

     

    So that does seem to work.

    Yes, It was mentioned before and it works perfectly fine

     

    Or you can do more - set it at the beginning of the script So old scripts work without any changes at all

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 8, 2011 9:16 AM   in reply to John Hawkinson

    Hi John,

     

    kimtorch's wrote: "In CS3 we used to simply get the parent story properties from the  frame, place the new text and then reapply the properties to restore the  style." I just wanted to note that that was something that script versioning couldn't fix that particular problem. (No worries--your posts here are great!)

     

    Regarding item(label) vs. itemByName(name)--in my opinion, the biggest problem here is that the behaviors differ. The former may have been a hack (a special case for label that only worked for page items), but it was great in that it would return all of the page items with a given label. The latter only returns a single item, even if multiple items have the same name. In cases where the name is not required to be unique (e.g., page items), itemByName should behave the way that item(label) did. So, yeah, I'm really glad script versioning solves the problem, but I wish they'd just fix itemByName.

     

    Thanks,

     

    Ole

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Sep 8, 2011 9:35 AM   in reply to Olav Kvern

    Yes, it is a problem.

     

    Having left the hive-mind, can you advise us: do you think the team

    would be receptive to requests to change .item()'s behavior behavior

    back to the pre-CS5 behavior of searching for a label (where applicable)?

     

    It seems to me we need .itemByName() and .itemByLabel() and both should

    handle multiple objects. I guess I can file a feature request for the

    .itemByLabel(), but I'm not sure if it makes sense to ask for .item()

    to revert to .itemByName().

     

    What do you think and what do you think is feasible to get?

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 8, 2011 11:16 AM   in reply to John Hawkinson

    Hi John,

     

    I really have no idea. But here's what should be done:

     

    * item(label) should be restored for page items, but deprecated. That is, it should work as it did before the change, but users should be encouraged to use itemByName(name)--see the next point.

     

    * itemByName(name) should be modified to work the way that item(label) used to work for page items. That is, it should return an array of all page items in a container that have the specified name. For objects where unique names are required (paragraph styles in a paragraph style group, for example), itemByName should return a single item.

     

    * A new feature should be added: itemByLabel(labelName, labelValue) should get all items with a custom label of "labelName" where the label has the value "labelValue". This way, scripters can mark items using insertLabel in a way that isn't visible (and editable) in the user interface, and get references to items of a given label with a given value. Again, this should return an array of all items in a container with the specified key/value pair. I've run into too many cases where workflow solutions get broken by users accidentally changing labels in the Script Label panel. If you needed to, you could use the default label property by using itemByLabel("label", labelValue).

     

    I don't think that these would be difficult changes to make, but I doubt if anything will happen. I put more of my faith in our ability to create workarounds.

     

    Thanks,

     

    Ole

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 9, 2011 2:33 AM   in reply to Olav Kvern

    hey ole,

     

    i do see your point - especially for exprienced scripters.

     

    but for beginners and learnes this would confuse even more: the label property would not correspond to the itemByLabel() function (same problem as  insertLabel() and extractLabel() but far less used).

     

    the mess started with insertLabel() and now there is no easy way out.

     

    luckily i had never any problems with users accidently changing labels in the label panel.

     

    gregor

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 9, 2011 2:38 AM   in reply to grefel

    Sorry, I'm coming in late to this discussion. What is the probem with

    insertLabel()?

     

    Ariel

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 9, 2011 2:57 AM   in reply to [Ariel]

    insertLabel() does not correspond to the property label. in my opinion this would be intuitive. the question was about getting things clear with item() and itemByName(). because of downward compatibility there is no easy solution to clear the DOM in this point.

     
    |
    Mark as:
Actions

More Like This

  • Retrieving data ...

Bookmarked By (1)