Issue with with images in arrays

[bryonenger]

Hello,
I attempt to use images in arrays - I come from a Java background so I'm thinking that the image is an Object, and when I put it in the array, I'd expect all the properties of the object to be maintained. This doesn't appear to be the case.

Here's my code :

Code: Select all

put image sheep into animalarray[1]
answer the short name of image sheep
put animalarray[1] into  temp
answer the short name of temp 

I'd expect the the first two lines of code to be equivalent to the second two lines of code - but they aren't. The first two lines do what I'd expect ( they display the short name of my "sheep" image). The second two lines produce a runtime error as the fourth line executes. ( Chunk error in object expression )

Once I put an image into an array, does it cease to be considered to be an image object? Should I stop thinking about objects?

The more I use LiveCode, the less I understand it ...

[dunbarx]

Hi.

Line 1: you put the image metaData into an array variable ("animalArray1")

line 2: You ask for the name of the image, ("sheep") An image is a control.

Line 3: You put the value of the array variable into a normal variable ("temp")

Line 4: You ask for the "name of the variable temp". That last makes no sense in LC. If anything one might say the "name" of the variable is "temp", but it is outside the syntax of LC to assign a property, like the "name", to a variable. Controls have names. Variables contain values, like numbers or image metaData.

Think about it. Would the short name of the variable be "temp" but the long name be "ordinary variable temp"? This in contrast to the long name of the variable in line 1, "array variable animalArray1". So it is simply a matter of misunderstanding that fact, that in LC variables can be named, but do not have the property "name".

Craig

[bryonenger]

Hi.

Line 1: you put the image metaData into an array variable ("animalArray1")

line 2: You ask for the name of the image, ("sheep") An image is a control.

Line 3: You put the value of the array variable into a normal variable ("temp")

Line 4: You ask for the name of the variable temp". That last makes no sense in LC. If anything one might say the "name" of the variable is "temp", but it is outside the syntax of LC to assign a property, like the "name", to a variable. Controls have names. Variable contain values, like numbers or image metaData.

Think about it. Would the short name of the variable be "temp" but the long name be "ordinary variable temp"? This in contrast to the long name of the variable in line 1, "array variable animalArray1". So it is simply a matter of misunderstanding that fact, that in LC variables can be named, but do not have the property "name".

Craig

Thanks for your advice

[SparkOut]

does it cease to be considered to be an image object? Should I stop thinking about objects?

Essentially yes And no. It's hard to explain but although there are "controls" (objects) and "containers" in LC this isn't how you're trying to do things. Jacque could probably describe things better. But you see from dunbarx's post, here you are just putting data into a variable. You are not moving an object.

In the code, you will find that you will come very unstuck at some time if you leave out quotes from the object names. LiveCode is helpful at interpreting what it thinks you should mean, but if you ever have a variable called sheep then it will use the value instead of the object named "sheep" creating a bightmare to debug. It might help to become used to this if you turn on "strict compilation" in the Script Editor preferences.

There are different ways to do things in LC. One suggestion could be to place your images onto a hidden card and refer to them from there.

Code: Select all

put the long name of image "sheep" into animalarray[1]
answer the short name of animalarray[1]
 

[dunbarx]

When you put an image into a variable (it does not need to be an array variable, an ordinary one would do) you are putting the "guts" of that image into that variable. The guts are all the information one (actually LiveCode) would need to fully characterize the image, pixel by pixel, colors included.

So there is nothing mysterious about that, or doing that. What were your plans for that data?

And just out of curiosity, why did you choose an array variable in the first place? I use these when I am building a suite of values that I want to be able to control easily, since the keys can be organized the way I want. But I would never think of using one just to hold a single dataset, like the guts of an image. Do you plan to have a suite of images, perhaps a zoo-full?

I have an ulterior motive for asking. I have always found that new LC users jump into using arrays early on. Nothing at all wrong with that, though they do take a bit more effort to name, track and deconstruct. Just wondering...

Craig

[stam]

Code: Select all

put image sheep into animalarray[1]
answer the short name of image sheep
put animalarray[1] into  temp
answer the short name of temp 

I'd expect the the first two lines of code to be equivalent to the second two lines of code - but they aren't. The first two lines do what I'd expect ( they display the short name of my "sheep" image). The second two lines produce a runtime error as the fourth line executes. ( Chunk error in object expression )

The way I think of it is: Manipulating the binary data of the image, vs manipulating a reference to the image. A reference can be a control property such as name/short name/long name/ID/long ID if the image resides in a stack. Or it can be a file path, if the image is an external file.
Most frequently you will reference, unless you want to actually manipulate the picture data.

As for understanding your code: It's very useful to get to know how to use breakpoints (click on the line number to create a red dot - code execution will halt there and you can examine your variable values, and then step through the remainder of the code.

In your code above, you can put a breakpoint on the second line and examine the variables. If you then look at animalArray[1], you would see the binary data, something like this:

âPNG

IHDR[±jgΩgAMA±è¸a IDATxúÏùyòEŸ∑Ô™Ó≥Ãöu!êÑщBÿƒ∞≈∞(*B@DQyŸÇ "aS@
A\≈·eQ"ã√öêê»ûLfÊÃY∫´Í˚£™˚Ùô93ôÑ €;øÎökÍtW◊fiO=ıl
...

This is not a reference to a control, so it doesn't have a short name - it's the binary picture data.

Instead, what you want is a reference to that image. If the image is stored in a stack, I would store the reference as the long id of the image in the stack, i.e.

Code: Select all

put the long id of image "sheep" into animalArray[1] // note the quotes!!
answer the short name of animalArray[1]

You don't need to import the image to use this. Instead of storing the long id, just store the file path to the image. But then of course you can't refer to it by short name etc, since these don't live in a card (you would instead extract the file's name for example).

Hope that helps,
Stam

[Klaus]

Hi bryonenger,

what they said!

And please get used to put QUOTES around names: image "sheep"!
With each new version the engine is less forgiving to "sloppy" coding,
so something like this might throw an error in future versions.


Best

Klaus

[stam]

I should also add that if there is uncertainty about what long name/long id are, using the msgBox you can just type

Code: Select all

put the long name of image "sheep" & return & the long id of image "sheep"

You'll see that unless using short name, the control type is prepended so in your case, you don't need to include both the keyword "image" and the long name/long id - indeed, this will generate an error (the keyword image is part of the name/long name/long id). Hence

Code: Select all

answer the short name of animalArray[1] 

where animalArray[1] contains the long id of the image, is the same as

Code: Select all

answer the short name of image id xxxx of card id xxxx of stack <file path to stack> // always unique

This will however generate an error:

Code: Select all

put the short name of image animalArray[1]

because the keyword image is already included in the long name/long ID (it's like saying put the short name of image image id xxx...)


The reason I prefer the long id is that if you duplicate an image and it has the same name, on the same card, in the same stack, the long name will be the same for both; whereas each control has a unique ID, so the long ID will always differentiate them.
However long name is useful for debugging.

As for the ID - this is the same always, unless you copy/paste the image - every time you paste/duplicate, a new ID is generated.

S.

[dunbarx]

Anyone think that Scotland should mention on the LC website that free lifetime technical support is available 24/7?

Craig