>> I have two answers for a question like:
>>
>> The colour of a leaf if _____ or ___
>>
>> Options : green, organge
>>
>> If I drag green in the first blank the answer should
>> intersect in the first blank. And if I drag orange on
>> the first blank it should not sit there as the answer
>> green is already occupied, but it should intersect
>> with the second blank. Similarly for the second
>> blank. Can somebody figure this out.
>
>
> I'm sure you meant 'leaf is' not 'leaf if'.
>
> You need to think about what the user is trying to do. If they have
> dragged orange into the first position and then decide that they
> would rather say green first, you should let green take over that
> spot, and reset orange back to its initial place. If they have
> already have dragged orange into first and green into second, and
> then dragged green into first, green should go there, and orange
> should jump over to the second position.
>
> That doesn't help you with the lingo, but it might help you think it through.
One other thing (no disrespect, Colin) you might add is the ability to take
a sprite out of the position it was dragged to. So, If the user "picks up"
green after it's been dropped in the first slot, and lets it go outside of a
slot, it should return to its original position.
I could give you some lingo for this, but I like Colin's idea... think about
it a bit. You'll need to store a "draggable" sprite's original loc (a good
way to do so is in a property of the behavior attached to the draggable
sprite) so that you can restore its original loc.
You'll need to keep track of any sprite that is occupying a "target" (a good
way to do so is to store the "draggable" sprite's spriteNum in the target's
behavior) so that you can tell it to move when appropriate.
And you'll need to be able to send messages between those sprites (from the
"target"'s perspective - stick to me, go back to your original position,
stick to my neighbor... from the "draggable" sprite's perspective, am I on a
target?, tell my current target that I'm no longer associated with it,
etc.), or to a master object. Of course, with this kind of functionality,
you probably would have another object checking for correct answers when
some user event initiates the action to check (like clicking a "check
answers" button).
Some prefer to message the controlling object when "draggables" are dropped
on target, and control everything from there. Others like to keep the sprite
interactions between the sprites, and later poll the sprites for their
"associations". That's mainly a question of style. Of course, I am speaking
from an OOP perspective - there are other styles that use globals to achieve
the same ends. How you set up your architecture makes a big difference. But,
the key data you need to store are - original draggable locs, what draggable
is occupying a target, and ultimately, the right draggable for a target.
Of course, given your description, the target sprite could be much more
complex - one field that contains several "hot" blanks, and its behavior
inserts a string into the chars occupied by a blank when "dropped" upon.
That requires a bit more work on the target behavior - storing char locs and
adjusting the other char locs when a string is inserted into a blank. Too
much to cover in a single post.
Peace,
Kurt
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
