Deprecate ImageIDs database?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Deprecate ImageIDs database?

Richard Gaskin
Many years ago the RIP group started a database of image IDs with the goal of having a common place for developers to communicate their intentions to use IDs within specified ranges so we could avoid ID conflicts in our tools.

But for the last several years, the LiveCode engine now allows us to reference images by name as well, which is much more flexible.

In addition to being difficult to remember,IDs carry an additional downside:  when you raise an object's ID it raises the next available ID to be used when creating any other object.  This means that if you see an image ID to 999999 to try to be safely away from most common ranges, the next object created will have an ID of 1000000.  If you set your ID high enough, and create enough new objects, you can shorten the time before you exceed the available ID range (roughly 2 billion).

So going forward, I would advocate that we no longer maintain the image ID database, and instead encourage developers to use image names which are unique instead.

Can any of you think of a reason why the image database should be maintained?


Reply | Threaded
Open this post in threaded view
|

Re: Deprecate ImageIDs database?

mwieder
1. Are there any use cases where it's necessary to use an ID reference
rather than a name or is a name specification universally applicable?

2. Does using a name for an image reliably keep us out of trouble with
regard to conflicts with IDE images? I'm guessing it does, given the
assumption of an optimistic answer to the previous question.

3. Does this by any chance happen to solve the problem of id wraparound
regarding the metacard patterns? Sorry - I don't have the bug number in
front of me at the moment.

--
 Mark Wieder
 [hidden email]

--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate ImageIDs database?

Monte Goulding
In reply to this post by Richard Gaskin

On 03/05/2011, at 7:49 AM, richard g wrote
>
> Can any of you think of a reason why the image database should be maintained?
>
My understanding was using the name reference was very limited in that the engine only looks on the current stack for the image and long/rugged names don't work. Is that not still the case?

Cheers

Monte

[Non-text portions of this message have been removed]

Reply | Threaded
Open this post in threaded view
|

Re: Deprecate ImageIDs database?

Mark Rauterkus-2
In reply to this post by Richard Gaskin
Furthermore, what is the best system for picking names so that the
name reference is clear and less of a problem into the future?

Calling graphics, image1 or logo-small would not be ideal.

How do you name your stuff?


--
Ta.


Mark Rauterkus       [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate ImageIDs database?

Richard Gaskin
On 5/3/11 4:10 AM, Mark Rauterkus wrote:
> Furthermore, what is the best system for picking names so that the
> name reference is clear and less of a problem into the future?
>
> Calling graphics, image1 or logo-small would not be ideal.
>
> How do you name your stuff?

I'm imagining that for shared components like behaviors we could use
naming conventions similar to what we commonly use for libraries, e.g.:

_stsVerticalSplitter

_fwMyNiftyCursor

With letters we have much more flexibility than with numbers, and
they're easier to remember when coding.

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate ImageIDs database?

Richard Gaskin
In reply to this post by Monte Goulding
On 5/2/11 3:39 PM, Monte Goulding wrote:
>
> On 03/05/2011, at 7:49 AM, richard g wrote
>>
>> Can any of you think of a reason why the image database should be maintained?
>>
> My understanding was using the name reference was very limited in that the engine only looks on the current stack for the image and long/rugged names don't work. Is that not still the case?

Good question, so I ran a test in which I made two separate stack files,
one containing an image and another containing a field.  I set the
htmlText of the field to use the image as an imageSource by name, and it
seemed to work.

With the revisions made for the lookup path for images (v2.9?) I'm
guessing names are now as robust as IDs.

Anyone here know of a circumstance where that's not the case?

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate ImageIDs database?

Richard Gaskin
In reply to this post by mwieder
On 5/2/11 2:58 PM, [hidden email] wrote:
> 1. Are there any use cases where it's necessary to use an ID reference
> rather than a name or is a name specification universally applicable?

So far in my own tests it seems names are good, but if there is a case
where one must use IDs it would be very helpful to know.


> 2. Does using a name for an image reliably keep us out of trouble with
> regard to conflicts with IDE images? I'm guessing it does, given the
> assumption of an optimistic answer to the previous question.

Since IDs have a smaller namespace than names, my hunch is that using
names would obviate those limits, as well as the limit on the max ID.

But of course that's dependent on the answer to your #1 above.


> 3. Does this by any chance happen to solve the problem of id wraparound
> regarding the metacard patterns? Sorry - I don't have the bug number in
> front of me at the moment.

I'm not familiar with that one - can you describe what happens with that?

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate ImageIDs database?

Monte Goulding
In reply to this post by Richard Gaskin
>With the revisions made for the lookup path for images (v2.9?) I'm
>guessing names are now as robust as IDs.

>Anyone here know of a circumstance where that's not the case?

It was new to me that this might be the case so I ran a test too. I created 3 stacks. One with a button and two with an image each. The images had the same name but different id. I set the icon of the button to the name of the images. Then restarted LC and loaded one of the image stacks and the button stack  then did the same with the other. It appears that the name reference didn't stick and the engine finds the image id of the name reference then saves that. Because when I loaded the second image stack the button was blank.

Cheers

Monte
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate ImageIDs database?

Richard Gaskin
 On Wed, 4 May 2011 12:54:20 +1000 (EST), Monte Goulding wrote:

>>With the revisions made for the lookup path for images (v2.9?) I'm
>  >guessing names are now as robust as IDs.
>
>  >Anyone here know of a circumstance where that's not the case?
>
>  It was new to me that this might be the case so I ran a test too. I
> created 3 stacks. One with a button and two with an image each. The
> images had the same name but different id. I set the icon of the
> button to the name of the images. Then restarted LC and loaded one of
> the image stacks and the button stack then did the same with the
> other. It appears that the name reference didn't stick and the engine
> finds the image id of the name reference then saves that. Because
> when
> I loaded the second image stack the button was blank.

 Good sleuthing.  Thanks for looking into this.

 I didn't recreate your three-stack test, but I did recreate my
 two-stack test, and posted it here:
 <http://fourthworldlabs.com/mc/Image%20Test.zip>

 The "open me.mc" stack has a field with some HTML text which references
 an image by ID and again by name, and a button which sets another
 field's htmlText to that string.  Before it sets the htmlText it first
 gets the name of a second stack in a file named "aaa.mc", which contains
 the image in question.  As with behaviors, this will be needed to have
 the stack in memory, of course, though you should never have to open
 that "aaa.mc" stack directly (probably a cleaner test if you don't).

 Here, when I click that button I get both images showing.

 If your results are different it would be good to know, or if you have
 a set of files that causes any name lookup to fail.

 If we can pin down a recipe in which IDs work but names don't I'll file
 it to the RQCC as a bug report.

 Thanks -

 - rg

Reply | Threaded
Open this post in threaded view
|

Re: Deprecate ImageIDs database?

mwieder
In reply to this post by Richard Gaskin
 On Tue, 03 May 2011 07:56:50 -0700, Richard Gaskin
 <[hidden email]> wrote:

>> 3. Does this by any chance happen to solve the problem of id
>> wraparound
>> regarding the metacard patterns? Sorry - I don't have the bug number
>> in
>> front of me at the moment.
>
> I'm not familiar with that one - can you describe what happens with
> that?

 It's bug #8212 in the RQCC.

--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate ImageIDs database?

Ken Ray
>>> 3. Does this by any chance happen to solve the problem of id
>>> wraparound
>>> regarding the metacard patterns? Sorry - I don't have the bug number
>>> in
>>> front of me at the moment.
>>
>> I'm not familiar with that one - can you describe what happens with
>> that?
>
>  It's bug #8212 in the RQCC.

As it turns out, patterns don't work with image names, but only IDs (you get
a "pixmap is not an integer" error) and so they don't fix the MC Wraparound
Patterns issue.

It looks like names can be used for button icons and for imageSource in
fields, but not for cursors (error: "source is not a character") or patterns
(error: "pixmap is not an integer").

:-(



Ken Ray
Sons of Thunder Software, Inc.
Email: [hidden email]
Web Site: http://www.sonsothunder.com/


Reply | Threaded
Open this post in threaded view
|

Re: Deprecate ImageIDs database?

Ken Ray
In reply to this post by Monte Goulding

> It was new to me that this might be the case so I ran a test too. I created 3
> stacks. One with a button and two with an image each. The images had the same
> name but different id. I set the icon of the button to the name of the images.
> Then restarted LC and loaded one of the image stacks and the button stack
> then did the same with the other. It appears that the name reference didn't
> stick and the engine finds the image id of the name reference then saves that.
> Because when I loaded the second image stack the button was blank.

Yes, that's very similar to when I tested it - when you assign the icon of a
button by name, it only uses the name to locate the image and then attaches
that ID to the button's icon property. If you save the stack with the button
in it, you are saving the ID it was assigned when you set the name.

If you try to set the icon of a button by name and the image with that name
does NOT exist at the time, the icon of the button is 0 (i.e. it doesn't
"remember" the name).

So names can be used in *most* circumstances, but if you're connecting to an
image that's not in the same stack, you'll either have to use IDs, or assign
the icon by name after the "other" stack has been opened.

Ken Ray
Sons of Thunder Software, Inc.
Email: [hidden email]
Web Site: http://www.sonsothunder.com/


Reply | Threaded
Open this post in threaded view
|

Re: Deprecate ImageIDs database?

mwieder
 On Wed, 04 May 2011 18:52:12 -0500, Ken Ray <[hidden email]>
 wrote:

> So names can be used in *most* circumstances, but if you're
> connecting to an
> image that's not in the same stack, you'll either have to use IDs, or
> assign
> the icon by name after the "other" stack has been opened.

 Bummer. Why can't this stuff be easy? Isn't this stuff supposed to be
 easy?
 <g>

--
  Mark Wieder
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate ImageIDs database?

Richard Gaskin
In reply to this post by Ken Ray
On 5/4/11 4:52 PM, Ken Ray wrote:

>
>> It was new to me that this might be the case so I ran a test too. I created 3
>> stacks. One with a button and two with an image each. The images had the same
>> name but different id. I set the icon of the button to the name of the images.
>> Then restarted LC and loaded one of the image stacks and the button stack
>> then did the same with the other. It appears that the name reference didn't
>> stick and the engine finds the image id of the name reference then saves that.
>> Because when I loaded the second image stack the button was blank.
>
> Yes, that's very similar to when I tested it - when you assign the icon of a
> button by name, it only uses the name to locate the image and then attaches
> that ID to the button's icon property. If you save the stack with the button
> in it, you are saving the ID it was assigned when you set the name.
>
> If you try to set the icon of a button by name and the image with that name
> does NOT exist at the time, the icon of the button is 0 (i.e. it doesn't
> "remember" the name).
>
> So names can be used in *most* circumstances, but if you're connecting to an
> image that's not in the same stack, you'll either have to use IDs, or assign
> the icon by name after the "other" stack has been opened.

Thanks for the follow-up.

Given the many benefits of being able to reference images by name in
addition to ID, I've submitted a request for this:

<http://quality.runrev.com/show_bug.cgi?id=9528>

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv