Varen,
Until i can release my mediastack... Klaus or Mickey might tell you what
they think about it... (without mentioning the unfinishedness of it of
course)... but until then, here's a little insight (or a lot ;)
I wish I could share a quick script but's it's now gotten much bigger and
complicated which is not the point...
Alternative procedure:
Import the folder into a new stack...
Set the mainstack of your new "media" stack to the main stack you use or
just open it and hide it so your stacks can use it (note that if you open
the media stack after, the stack needs a toplevel kick in the but to refresh
it's images (bugzilla lurking already)).
Make a button in the media stack. In it, put a repeat loop script to make
all ids of each image +1 zillion (set the id of image x to x+K). Note
there's a limit to the max integer in ids.
-- imagine what is an id...
function isImgIDReserved what
return (what >= 1 and what < 100) or \
(what >= 101 and what < 135) or \
(what >= 236 and what < 300) or \
(what >= 301 and what < 1000) or \
(what >= 101000 and what < 103000) or \
(what >= 200000 and what < 299999)
end isImgIDReserved
Now there's a little trick... if you have already set the patterns or icons
of buttons with your media before you set the ids, you have to track the
icons and patterns of all your controls before you reassign or replace the
ids for the correct images.
Problem #1: can't use the name of an image unless you use the path of the
image (then problem and media stack are futile, but 1 stack file is better
than 50 images folder).
Problem #2: remember which stack used which media stack or ID range.
Problem #3: hope that no other stack already uses the same ids... You work
on many stacks at once instead of a one stack project for example.
Solution #1: encode names as numbers (base 256 numbers encoding). It might
help in the diversity or standardization of images in use.
Solution #1b: use the md5 hash of the image data to generate an id. In
solution #3, this helps identify duplicates...
Solution #2: use stackID:imageID to define your IDs' range. Names [encoding]
instead/along ids can help if there's a zillion images.
solution #3: one stack with media, the rest depend on it... Stack stability
problems?
There's lots to think about this. One issue is that stacks can't have the
same name (yet have different ids!) - why can images then? I might even add
that in an object programing level, any global can be harmful is is
disrecommended. In this case it fouls the inheritance of private
resources/data in a stack. A choice to make images public, shared, or
private could help. And this could be caried on to cards, groups, bgs,
etc... Am i too far ahead again?
And this imoho is a mistake that polutes the image stack-independent id
space... Im sure menus or controls could be confused in this way in a script
maybe somewhere along the line (and be exploited as a security hole maybe
too ;).
To be precise, stay simple... Use the solution that is best for you. Adapt
to your needs and duplicate the shared/experience for the standalones...
Just use an original id ;)
cheers
Xavier
--
http://monsieurx.com
> -----Original Message-----
> From: use-revolution-bounces at lists.runrev.com
> [mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of
> Varen Swaab
> Sent: Friday, April 22, 2005 19:22
> To: How to use Revolution
> Subject: Re: Image Library question
>
> Xavier
>
> Thanks for the info but I'm not sure what to do from here.
> You say to set the image IDs above 1 billion but how do I do
> that? I'm importing a folder full of images, I'm not even
> sure how to do that with one image.
>
> I admit to be a little dismayed and discouraged that this
> problem and I'm surprised it hasn't been addressed yet. (hek,
> it's not even a "confirmed" bug in the Bug Database. This has
> become a big issue for me as now all my images are messed up
> and I have no confidence in the image management system of RR.
>
> I may now need to completely rebuild my stack from scratch to
> fix this problem and it will cost me a lot of time and effort.
>
> Varen
>
>
> On Apr 21, 2005, at 10:54 PM, xbury.cs at clearstream.com wrote:
>
> > Hi Varen
> >
> > I think the issue is this...
> >
> > http://support.runrev.com/bugdatabase/show_bug.cgi?id=2449
> >
> > Not the first or last time. You'll find some solutions and
> answers to
> > your
> >
> > questions there I hope...
> >
> > Im writing a library to avoid the issue altogeter and have
> both images
> > and any references reassigned to unique ids but library images are
> > always a big job...
> >
> > cheers
> > Xavier
> >
> > On 22.04.2005 07:47:05 use-revolution-bounces wrote:
> >> Hi everyone,
> >>
> >> I'm working on an application which has about 25 .png
> files imported
> >> via the image library. We recently discovered an aesthetic
> problem
> >> with the images which required me to import new images into the
> >> stack's library.
> >>
> >> When I imported the new images I noticed some wrong images
> being used
> >> in the various button states even though I'm sure the images were
> >> being called correctly. I have several button states I'm working
> >> with, mouseEnter, mouseClick, etc. In a seemingly random pattern
> >> some button images have been replaced by very old images
> I'd imported
> >> into, and deleted from the application weeks ago.
> >>
> >> In other cases, the thumbnail in the Image Library was of
> a totally
> >> different image than the actual imported image, but when viewed in
> >> the stack the image was correct.
> >>
> >> For example, when I mouse over a button an image appears that I
> >> deleted from the application in February. I haven't seen
> or used this
> >> image in a long time but BANG there it is!! fI know the
> image number
> >> is being called is correctly and the image appears
> correctly in the
> >> stack, but not in the button.
> >>
> >> Has anyone ever seen this problem before? It seems that
> there is an
> >> image cache that isn't properly cleared when images are
> deleted, or
> >> something else is going on.
> >>
> >> BTW, I even created a new substack, imported the new
> images, and the
> >> same problem happens.
> >>
> >> Any help or ideas are appreciated.
> >>
> >> Varen
> >>
> >> _______________________________________________
> >> use-revolution mailing list
> >> use-revolution at lists.runrev.com
> >> http://lists.runrev.com/mailman/listinfo/use-revolution
> >
> >
> > -----------------------------------------
> > Visit us at http://www.clearstream.com
> > IMPORTANT MESSAGE Internet communications are not secure and
> > therefore
> > Clearstream International does not accept legal
> responsibility for the
> > contents of this message. The information contained in
> this e-mail
> > is
> > confidential and may be legally privileged. It is intended
> solely for
> > the addressee. If you are not the intended recipient, any
> disclosure,
> > copying, distribution or any action taken or omitted to be taken in
> > reliance on it, is prohibited and may be unlawful. Any
> views expressed
> > in this e-mail are those of the individual sender, except where the
> > sender specifically states them to be the views of Clearstream
> > International or of any of its
> > affiliates or subsidiaries. END OF DISCLAIMER
> > _______________________________________________
> > use-revolution mailing list
> > use-revolution at lists.runrev.com
> > http://lists.runrev.com/mailman/listinfo/use-revolution
> >
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>