Card size question

[Pistris]

I gues this is somewhat a stupid question but i want to make sure

can the card be a different size than the stack?
i tried to make it smaller but i couldn't, i want to know if its because am doing it wrong or it can not be done

thanks

[Klaus]

Hi Pistris,

stack size = card size!

But noone will hinder you from changing the card size for specific cards "on preopencard".
And of course restore to "default"(?) dimensions "on closecard" or "on preopencard" of the next card.

You get the picture!


Best

Klaus

[FourthWorld]

And if you need the contents of a card to be larger than the card itself, you can put those in a group and turn on the group's scrollbars.

[Pistris]

ok so i dont understand why i have position parameters for cards

am setting diferent locations for the card but still everything remains in the same place

kind of confusing

[dunbarx]

Hi.

if you think about it, what sort of scenario would you suggest where the card size need be different than the stack? Sort of a smaller visually defined area within a larger window? This can be simulated in several ways.

If you do have some other ideas, please discuss them. No matter what, LC will be able to do what you need with its native object model, and nobody will be the wiser.

Craig Newman

[dunbarx]

You cannot set the loc of a card, only of the stack, which as you now know is the same thing. That property may be read with either object, however, though I do not see the advantage of one over the other.

So stick to:

Code: Select all

set the loc of stack "yourStack" to yourLoc

Craig

[FourthWorld]

ok so i dont understand why i have position parameters for cards

am setting diferent locations for the card but still everything remains in the same place

kind of confusing

Think of card metrics as information for placing objects on them. To move or resize a card, do those operations on the stack. Card metrics are provided in local coordinates, since they're used for positioning things within them. Stacks use global coordinates, so they can be positioned on the screen.

[Pistris]

Well if i were able to actually move the card within the stack it is actually useful
am not saying that what need to be accomplished can not be done in different ways

i just saw that the cards had a location parameter and wondered if it could be moved

thank you guys

[dunbarx]

Well if i were able to actually move the card within the stack it is actually useful

I had asked above how this might work. Can you give a short example of what you mean?

Craig

[Pistris]

i make interactive comic books
if i was able to treat the cards as layers and move them around in combinations with the effects already built into live code
it would save me time
i would laid out every item on the cards with positions set relative to the card,

basically a container for images that you can manipulate inside the container, you can move them, you add them or remove them , set transparency (all this on script)
the container will be on a layer so i can work with several layers at the same time and they can all be visible depending on position and

am doing it using groups of buttons with graphics now, its a little tedious task

[dunbarx]

OK.

Simply rethink your, er, thinking with groups instead of cards. There really will be no difference, except, as I said, a slightly different mindset.

Create a group (or series of groups), each containing its own content. Groups can contain images, graphics, controls, whatever. You can then move or change any properties of the group or any of the objects within that group in any way you need to.

Write back if this is not clear.

Craig

[dunbarx]

I just finished reading the whole of your previous post. You are already using groups.

I cannot see any difference in effort or management between groups and sliding "cards". In other words, whatever you hope to do with cards, assuming that they indeed were able to slide around on a fixed "stack", you can do with a group. I would think that the effort is the same.

Do you see what I mean? Whatever controls might sit on a card can also sit on a group. Whatever changes you need to make on the sliding "card" objects can be made, with exactly the same effort, on the group objects.

The difference is that groups do indeed "sit" on cards, whereas cards cannot "sit" on a stack.

Please write back, again, with your thoughts about the disadvantages of using groups, that you believe would go away if the "card" object worked in the way you wished it would.

Craig

[FourthWorld]

One challenge with working with groups is that by default they change their size to accommodate the objects within them. If you want a scrollable area within a group of a fixed size you can set the group's boundingRect property.

[dunbarx]

One challenge with working with groups is that by default they change their size to accommodate the objects within them...

What Richard said.

But whatever "card" you were wishing for, if the placement of objects within it changed, you might have to adjust certain properties as well, and though the names of those properties would be different, the concept would not, nor would the complexity.

What I mean is the comparison between groups and sliding "cards" is much the same. I am only harping on this point because you wrote that you found the management of groups tedious. I bet if that is true, whatever you would need to do with "cards" would be virtually identical.

Craig

[Pistris]

i would have to post here when challenges present themselves

thanks for the answers.