Re: [Flashcoders] avoiding a stack of lists
Nathan Derksen wrote: Sorry for the delayed response, it's been a busy day. Not a problem at all. I hope this helps. That looks great, an improvement over what I've already done, but it wont require a full rewrite. Thanks a lot. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] avoiding a stack of lists
Sorry for the delayed response, it's been a busy day.
It's been a while since I have touched Lingo, so I won't comment
there, but yah it's basically a list of properties. Associative
arrays can be accessed in two ways. First:
listRelationships:Object = new Object();
listRelationships["propertyName"] = "foo";
trace(listRelationships["propertyName"]);
and second:
listRelationships:Object = new Object();
listRelationships.propertyName = "foo";
trace(listRelationships.propertyName);
The two syntaxes are equivalent and interchangeable. I used the first
syntax because it easily allows you to access properties by name,
passed through another variable.
var itemID:String = "itemID1";
trace(listRelationships[itemID]);
You would create your full data structure, each line representing one
list item and containing an array of IDs linked to the given ID.
Ideally you would pull this data in from an external source, such as
through XML or through LoadVars, and build this data structure
dynamically. Also, this is only one way of doing it. Another way may
be more appropriate for you, given your particular requirements.
var listRelationships:Object = new Object();
listRelationships["itemID1"] = ["itemID2", "itemID3"];
listRelationships["itemID2"] = ["itemID1"];
listRelationships["itemID3"] = ["itemID1", "itemID3"];
...
listRelationships["itemIDN"] = ["itemID6", "itemID7", "itemID8"];
When one of the items is selected or moused over, you call a function
that you create, pass in the ID of the item in question, and use that
ID to find the related IDs:
function handleSelect(itemID:String):Void
{
var selectedItemData:Array = listRelationships[itemID];
for (var i:Number = 0; i < selectedItemData.length; i++)
{
// Get each row that should also be highlighted
trace(selectedItemData[i]);
}
}
I hope this helps.
Nathan
http://www.nathanderksen.com
On Jan 30, 2006, at 9:26 AM, Kent Humphrey wrote:
On 30 Jan 2006, at 17:13, Nathan Derksen wrote:
Well, regardless of whether or not you use listeners, you still
need to create the data relationship. I don't think encoding the
relationships into 25 listeners is necessarily a good idea,
either. An associative array, indexed by ID, could store the IDs
of the other list items that are related, all in a single data
structure. So for instance:
listRelationships["itemID1"] = ["itemID2", "itemID3"];
listRelationships["itemID2"] = ["itemID1"];
listRelationships["itemID3"] = ["itemID2"];
This allows you to store arbitrary relationships between each list
item. When a list item is moused over, just grab listRelationships
[itemID] and you will get a corresponding array of list items to
highlight.
Nathan
http://www.nathanderksen.com
That sounds a bit more like where I'm at. Not that I've used
associative arrays before, but they're basically the same as
property lists in Lingo right?
In your above example, wont I still need a listRelationships
["itemID1"] = [whatever] line for each item I'm wanting to
reference? Or have I totally misunderstood what's going on there?
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] avoiding a stack of lists
On 30 Jan 2006, at 17:13, Nathan Derksen wrote: Well, regardless of whether or not you use listeners, you still need to create the data relationship. I don't think encoding the relationships into 25 listeners is necessarily a good idea, either. An associative array, indexed by ID, could store the IDs of the other list items that are related, all in a single data structure. So for instance: listRelationships["itemID1"] = ["itemID2", "itemID3"]; listRelationships["itemID2"] = ["itemID1"]; listRelationships["itemID3"] = ["itemID2"]; This allows you to store arbitrary relationships between each list item. When a list item is moused over, just grab listRelationships [itemID] and you will get a corresponding array of list items to highlight. Nathan http://www.nathanderksen.com That sounds a bit more like where I'm at. Not that I've used associative arrays before, but they're basically the same as property lists in Lingo right? In your above example, wont I still need a listRelationships ["itemID1"] = [whatever] line for each item I'm wanting to reference? Or have I totally misunderstood what's going on there? ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] avoiding a stack of lists
On 30 Jan 2006, at 17:12, Alan MacDougall wrote: Close. Let's assume you're using mx.events.EventDispatcher. Your event broadcaster class starts like this: Wow. Thanks for all that. I'm not using classes so that's another thing I'll have to study up on... I've filed your post away for future reference, when I've got to grips with the whole OOP thing :> ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] avoiding a stack of lists
Well, regardless of whether or not you use listeners, you still need to create the data relationship. I don't think encoding the relationships into 25 listeners is necessarily a good idea, either. An associative array, indexed by ID, could store the IDs of the other list items that are related, all in a single data structure. So for instance: listRelationships["itemID1"] = ["itemID2", "itemID3"]; listRelationships["itemID2"] = ["itemID1"]; listRelationships["itemID3"] = ["itemID2"]; This allows you to store arbitrary relationships between each list item. When a list item is moused over, just grab listRelationships [itemID] and you will get a corresponding array of list items to highlight. Nathan http://www.nathanderksen.com On Jan 30, 2006, at 8:30 AM, Alan MacDougall wrote: Kent Humphrey wrote: I've made a single item work with my initial solution, which was to have a list for each item that lists which items in the other lists should highlight. But by the time I've made 25 lists for my 25 (current) items, that seems like a lot of redundant and duplicated data somehow. That sounds to me like you want to use events -- the items which light up should listen to the items that trigger them. When the triggering item gets moused over, the listening item(s) can decide whether to react. This might just take your redundancy and put it somewhere else, but it keeps you from writing and checking a ton of different lists. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] avoiding a stack of lists
That sounds to me like you want to use events -- the items which
light up should listen to the items that trigger them. When the
triggering item gets moused over, the listening item(s) can decide
whether to react. This might just take your redundancy and put it
somewhere else, but it keeps you from writing and checking a ton of
different lists.
Yeah, that sounds good. I haven't used events and listeners much, so
upfront it might take me longer than my first approach. But let me
see if I have the theory right.
Each item in the lists is assigned a listener object as it is
created, which would be a list of the possible events that will
trigger it. Each item also has an event object that fires when rolled
over.
Rolling over item A fires an event that all the other items hear,
each other item checks its list of events that will trigger it, and
if it finds the event that was fired, it does its thing.
Does that sound about right?
Close. Let's assume you're using mx.events.EventDispatcher. Your event
broadcaster class starts like this:
import mx.events.EventDispatcher;
class myClass
{
// function declarations to be mixed in by EventDispatcher
public var addEventListener:Function;
public var removeEventListener:Function;
public var dispatchEvent:Function;
/* constructor */
public function MyClass()
{
EventDispatcher.initialize(this);
}
}
The EventDispatcher.initialize() call simply "fills in" the blank
function declarations, and your object -- no matter what its type was
before -- now acts as an EventDispatcher.
Now let's say you have greenSwitch and purpleSwitch, which are event
dispatchers; and redLight, blueLight, and yellowLight, which don't need
to be. Given basic color theory, you want red and blue to light up if
you click the purple switch.
class Switch
{
...
public function toggle():Void
{
var eventObject:Object = new Object;
eventObject.type = "onSwitchChange";
eventObject.target = this; // sends a reference to itself!
dispatchEvent(eventObject);
}
}
class Light
{
...
// note that this function has the same name as the event
public function onSwitchChange(eventObject:Object):Void
{
// animate something, probably by altering a movieclip
}
}
And finally, the code that makes use of these objects:
var purpleSwitch:Switch = new Switch();
var redLight:Light = new Light();
var blueLight:Light = new Light();
purpleSwitch.addEventListener(redLight);
purpleSwitch.addEventListener(blueLight);
purpleSwitch.toggle();
As you see here, purpleSwitch contains an array of all objects listening
to it; then when you create and dispatch an event object, it simply
calls the identically-named method on each listener object. It's nothing
mystical -- just convenient.
And the nice thing about it, for your purposes, is that none of the
switches or lights really even needs to know what color they are... the
logic is contained in their sender/listener relationship.
If you need something more complex, just add properties to the
eventObject, and have the listener object deal with that. Or just read
from eventObject.target, which should be a reference to the broadcasting
object. The classic example is to have a textField or something, which
sends events when it's updated; a listener could get to the text with
eventObject.target.text.
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] avoiding a stack of lists
On 30 Jan 2006, at 16:30, Alan MacDougall wrote: I've made a single item work with my initial solution, which was to have a list for each item that lists which items in the other lists should highlight. But by the time I've made 25 lists for my 25 (current) items, that seems like a lot of redundant and duplicated data somehow. That sounds to me like you want to use events -- the items which light up should listen to the items that trigger them. When the triggering item gets moused over, the listening item(s) can decide whether to react. This might just take your redundancy and put it somewhere else, but it keeps you from writing and checking a ton of different lists. Yeah, that sounds good. I haven't used events and listeners much, so upfront it might take me longer than my first approach. But let me see if I have the theory right. Each item in the lists is assigned a listener object as it is created, which would be a list of the possible events that will trigger it. Each item also has an event object that fires when rolled over. Rolling over item A fires an event that all the other items hear, each other item checks its list of events that will trigger it, and if it finds the event that was fired, it does its thing. Does that sound about right? ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] avoiding a stack of lists
Kent Humphrey wrote: I've made a single item work with my initial solution, which was to have a list for each item that lists which items in the other lists should highlight. But by the time I've made 25 lists for my 25 (current) items, that seems like a lot of redundant and duplicated data somehow. That sounds to me like you want to use events -- the items which light up should listen to the items that trigger them. When the triggering item gets moused over, the listening item(s) can decide whether to react. This might just take your redundancy and put it somewhere else, but it keeps you from writing and checking a ton of different lists. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
[Flashcoders] avoiding a stack of lists
Here's more of a higher-level problem for you helpful people :> Imagine 3 lists, someListA, anotherListB, and lastListC. When I rollover something in someListA, I want the items in anotherListB and lastListC to highlight. And the same for rolling over something in anotherListB or lastListC. So rolling over an item in any list makes N items in the other lists highlight. I've made a single item work with my initial solution, which was to have a list for each item that lists which items in the other lists should highlight. But by the time I've made 25 lists for my 25 (current) items, that seems like a lot of redundant and duplicated data somehow. Anyone got any ideas? ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
