[Bug?] Call For-Each via FastLoop doesn't work as intend.

[defisym]

If you have two individual for-each loops of an object, and put the first one into a fastloop, then call the fastloop and the second for-each loop in the same line, the latter only runs once.


But, if you call for-each loops directly in one event, everything works as intend.
Here comes a quick example, I think that might be a bug.
CallForEachViaFastloop.mfa

[chrilley]

I vote bug. This does not seem like expected behavior at all. Curious to know what happens under the hood here.

[Volnaiskra]

Looks like another case of fastloops messing up scope, as we were discussing in this thread https://community.clickteam.com/threads/106342-Bug-Objects-initialised-and-looped-in-a-same-event

I bet that green diamond was the most recently created one

[defisym]

Looks like another case of fastloops messing up scope, as we were discussing in this thread

iirc if there's no for-each in the fastloop, all diamonds are turned into green. so I think something might goes wrong when fusion returns from for-each then fastloop.

[Volnaiskra]

I'll explain what I mean.

If you add a condition to event #4 that scopes only one Active, then the forEach loop will retain that scope. So here, only one Active has an id of 18, and that is the only active that gets colored by the loop "Angel_2":





So far so good.



And of course if you don't have any scoping conditions, then ALL the Actives will be colored:




Also, so far so good.


But what is happening in your example, I believe, is that the mere insertion of a fastloop call into event #4 breaks the scoping of that event. Fastloops are scope killers - they seem to force events to scope only one instance of any object that they themselves reference, as described in that thread I linked to above. Let's test to see if I was right, and the most recently created object is the one that gets scoped. Nope, it's actually the least recently created object that gets scoped:




Like I said, fastloops kill the scope only for objects that they themselves reference. So, if we change the "DoSomething" fastloop to reference some other object, suddenly the scoping in event #4 isn't messed up anymore:





It doesn't have anything to do with ForEach loops. Here's your example without any ForEach loops in it, with still the same problem:

[defisym]

I'll explain what I mean.

Fastloops are scope killers - they seem to force events to scope only one instance of any object that they themselves reference

Oh, I got you.
Now let's call a fastloop in event #4.
EV_E.jpg
if there is no operation about object A in the fastloop, it will resets the scope of object A in event #4 to all object As, unless #4 has already scope object A down to an unique object, as what you said in your bolg.
If there is an operation about object A in the fastloop, this time fastloop will reset the scope of object A to the latest-created in the fastloop-scoped objects.
Result_FL.png
Seems that if you create an object, fusion will put it on the top of the object list, and fuison scopes objects by iterating through the list from bottom to top, testing conditions, then puts the eligible ones to the scoped list: that's why we get 10 instead of 19.
Result_ID.png