jbv.silences at Club-Internet.fr
Mon Jun 21 13:00:53 CDT 2004
I don't if it'll help (and I'm not sure if I remembre it correctly
as it happened several months ago and as I have no time to check
right now), but I remember facing a similar problem using
imagedata. And I think I remember the problem has to do with the
fact that imagedata returns binary data, and that putting that kind of
code in a variable (or field) that contained a different kind of data
right before used to cause some problem...
I vaguely recall that I first tried to put empty into that variable before
putting the imagedata into it, and then I finally solved the problem
by using that variable ONLY for binary data.
But that was with a previous version of the MC engine. The context
might have changed and the cause of your problem might be different...
> My stacks do some moving of imageData between main stacks.
> The code seems to break, randomly, but with regularity. I think I have
> the issue resolved, it works fine for a while, then suddenly doesn't
> work... with no changes to any of the related code. It looks like this
> PUT the imageData of image ID 1018 of stack "Button Icons" into
> set the imageData of image "ThumbNail" of card tClipSelected of
> stack "CurrentP" to tClearImage
> *Sometimes* this will work a hundred times in a row. Then, it will
> suddenly fail, and fail every time after that.
> A little more info -
> image ID 1018 of stack "Button Icons" is an imported JPG, but I've
> tried PNG, and GIF with the same results.
> When it fails, the image is pure black.
> "Button Icons" is a substack of my main app.
> "CurrentP" is a mainstack, loaded by my main app as a resource.
> It seems to me that although I have the paths right, it can't find the
> proper image?? The fact that it works *sometimes* but not always is
> just weird, as computers usually make the same mistakes consistently.
> Could this have something to do with the defaultStack? I didn't think
> so, as I'm not using "this stack" anywhere, and I explicitly define the
> stack names.
> Any pointers? Thanks.
> RPSystems, Ltd.
> use-revolution mailing list
> use-revolution at lists.runrev.com
More information about the use-livecode