Storing Images for use by Custom Controls

Simon Knight smk at anvic.net
Thu Jul 26 04:52:33 EDT 2018


Bob,

The reason I went for the array rather than a naming convention such as you suggest is because I have no idea how Livecode resolves the names.  I have an impression that it looks at the stack and works its way up through the images in ID order.  The upshot is that a button in a copy of the first group may well be using images from other groups.

I tried all sorts of syntax along the lines of image “ImgPlusButton” of this group but any attempts to specify the location were rejected.  My code associates the local image of the required name that is within the group container with its ID number which is allocated when the group is created.  I believe that the stack wide naming/ID list is also where Bernd’s code fails; images are indeed found but there is no guarantee that they are the images that are members of the group or as in one of my tests even on the same stack.

best wishes

Simon

> On 25 Jul 2018, at 22:47, Bob Sneidar via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> About saving images: I learned a long time ago, both with graphics and publications development, as well as software development, to have copies of resources in a subfolder of a main project folder. This has a couple advantages: First of all, graphics applications can often auto-resolve references if you do that. Second, in case you want to skin your app, you can keep sets of graphics in other folders, then do a simple folder rename kabuke dance and voila! You just reskinned your app! 
> 
> As far as the technique of grouping buttons with their image objects (I hide my image objects and put them behind the button they belong to) and then grouping all the control groups as one, this is a great method, and allows you to programmatically dynamically update the controls as needed. 
> 
> Finally, as I mentioned, naming the images and buttons so that knowing the button name makes the image name predictable eliminates the need to store everything in an array for access later, although I'm sure that is a workable solution as well. 
> 
> I have no problem having multiple copies of an image in my application, at least for MacOS and Windows apps. They shouldn't take up too much space if designed right, and the convenience of keeping the images with the buttons that need them ensures my forms will ALWAYS display correctly. 
> 
> Bob S
> 
> 
>> On Jul 25, 2018, at 13:20 , Simon Knight via use-livecode <use-livecode at lists.runrev.com> wrote:
>> 
>>>> The problem with this storage solution is that my custom control has
>>>> components stored in different locations and they may well become
>>>> separated sometime in the future.
>>>> Initially, I searched the Livecode forum and found a thread where the
>>>> prospect of better encapsulation of custom controls was discussed and Mark
>>>> W. wrote that he was thinking  about it.  This was a few years ago when
>>>> version 6 was current and I wondered if any features have been added to
>>>> Livecode to enable fully encapsulated custom controls to be written.  I
>>>> realise that one answer might be “write a widget” but I don’t really want
>>>> to take time learning a new language and process in an attempt to recreate
>>>> a control that I already have.
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list