'Resolve image' is useful to know. However, the indexing solution to identify buttons used as behaviors is fine as far as it goes, but it will inevitable omit any behaviour buttons if any 'calling' objects are not currently loaded. As you say, behaviors can be set and changed dynamically, but then so can the icon property. On the other hand, I am coming to the conclusion that an 'isBehavior' property is essentially meaningless because a behaviour only means 'insert into message passing hierarchy'. There is no property to identify whether an object contains a frontscript or backscript, and the same would thus be true of a behaviour script. Until actually applied, it is not a behaviour anyway.
My apologies for wasting everyone's time. Hugh Senior FLCo Richard Gaskin wrote: Hugh Senior wrote: > It's a supplementary idea for the upcoming Control Manager utility to > show not only the style but the function of a button. > > More generally, behaviours are a bit like icons, although locating a > behaviour source is easier than locating an image source! That got much easier a few builds ago with the "resolve image" command - from its Dictionary entry: This command resolves a short id or name of an image as would be used for an icon and sets it to the long ID of the image according to the documented rules for resolving icons. For behaviors, anything the IDE were to provide would have to use a brute-force on-the-fly algorithm very similar to the one Mike provided, since behaviors can be set and changed dynamically at any time. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode