If a button could point to a file instead of an embedded image, the issues with ID's would disappear altogether. Instead of having an image AND the button, and then hiding the image, you would only have the button. Yes you can create an image and point it to a file on the hard drive, but it amounts to the same thing as importing the image and then setting it's file reference to the original file. 2 different paths, same destination. A button's icon still has to be set to that image object's ID, so it's six one way, half a dozen the other. One leg is both the same, you see? ;-)
Bob On Apr 2, 2012, at 10:21 AM, Malte Brill wrote: > I do not see what does not work in that context? The images does not > necessariely need to be imported? Works just fine with referenced images. > Sure, it still needs an image container, but that does not hurt much, does > it? I would be glad if the icon could be a rugged ID though (image ID 58 of > cd "myCard" of stack "myStack") without being resolved to an ambigouus > number... > > Cheers, > > Malte > >> It's one of the oddest things, but buttons point to imported images, >> imported images *can* be set to point to a file on the hard drive. Why not >> allow a button to point to an image on the hard drive for it's icon I say? > > _______________________________________________ > 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 _______________________________________________ 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
