When an outpin of part1 is connected to part2 and part3, the sequence in which part2 and part3 will get events is not granted. Why is that?

The short answer is that Buildap is based on asynchronous communication among parts.
If a pipe passing an event1 does some processing of the event, then the pipe could pause the event1 long enough that event2 reaches it's destination first.

However, as recently noted in an email to the class, all parts simply cannot be implemented in a purely asynchronous manner.

Someone will have to design and implement a new part for the part library that can synchronize events for use in devices and applications.

For instance, if we change the question slightly to say:
"When an outpin of part1 is connected to part3's INPIN1 and part2's outpin is connected to part3's INPIN2, the sequence in which INPIN1 and INPIN2 will get events is not granted. Why is that?"

With many parts, INPIN1 initializes an internal variable and INPIN2 reads or writes to that internal variable.

If I cannot control which sequence part3's INPIN1 AND INPIN2 are fired by part1 and part2, then as far as I can tell, the overall device or application will not work.

Seems not correct. Here are 2 points here:

When event delivery sequence is predictable and when it is not? When part fires Event1 then Event2 then this order will be preserved. So there is not way that any part can recieve Event1 after Event2. But when Event is broadcasted to several parts then order of delivery is not predictable. Why? Several reasons. The simple explanation is that it is visual language so on diagram we have parts connected and there is not any notion which dictate the broadcast order. Lets say we have a picture that part1 is connected with part2 and part3. Both connections looks equal so which should take priority? THe one which is higher on the diagram - then if we move the part it will affect the execution wich is contreintuitive.

Another explanation is that buildap is declarative language and it defice elements and connections and not the procedure of execution (see comments to declarative vs. procedural)

Why it is important. Just imagine for a moment that we decided to convert a buildap application into distributed one. It will be done without affecting any part - framework will take care about event forwarding - in that case it will be remote forwarding.

But there are situations we really need sychronization. It is a situation like in case of Date and Time. These parts lets say are firing their events asych and we need something to happen at certain date and time. We apply synchronization part which take an input from both parts (say INPUT and CONTROL inpins). This part will take several time events on INPUT pin but will not fire anything till get date event on CONTROL pin. Then it will change its state and next time event will go through. If you are familiar with electronics that how transistor works. It is either closed or open (between pin1 and pin2) and that state is regulated by third pin.

When an outpin of part1 is connected to part3's INPIN1 and part2's outpin is connected to part3's INPIN2, the sequence in which INPIN1 and INPIN2 will get events is not guaranteed.

So, let's say I have an ArrayPart. Inpin1 initializes an array, and Inpin2 sets a value in the array.
Two other parts use the ArrayPart.
PartA initializes the Array, and SSPart will start inserting somebody's Social Security number into the array.

How do I know that the array is initialized before SSPart starts trying to set values in the ArrayPart?

If the SynchronizationPart throws away values until the CONTROL pin is fired by PartA, then only part of the social security number would be inserted into the ArrayPart.

...Ok, I looked closer into they synch java package. I don't think the package will support my proposed situation.

Ideas?

When an outpin of part1 is connected to part3's INPIN1 and part2's outpin is connected to part3's INPIN2, the sequence in which INPIN1 and INPIN2 will get events is not guaranteed.

So, let's say I have an ArrayPart. Inpin1 initializes an array, and Inpin2 sets a value in the array.
Two other parts use the ArrayPart.
PartA initializes the Array, and SSPart will start inserting somebody's Social Security number into the array.

How do I know that the array is initialized before SSPart starts trying to set values in the ArrayPart?

If the SynchronizationPart throws away values until the CONTROL pin is fired by PartA, then only part of the social security number would be inserted into the ArrayPart.

...Ok, I looked closer into they synch java package. I don't think the package will support my proposed situation.

Ideas?

(Note: I don't know what happened, but I can no longer see the previous replies to this topic in the discussion forum.)

When an outpin of part1 is connected to part3's INPIN1 and part2's outpin is connected to part3's INPIN2, the sequence in which INPIN1 and INPIN2 will get events is not guaranteed.

So, let's say I have an ArrayPart. Inpin1 initializes an array, and Inpin2 sets a value in the array.
Two other parts use the ArrayPart.
PartA initializes the Array, and SSPart will start inserting somebody's Social Security number into the array.

How do I know that the array is initialized before SSPart starts trying to set values in the ArrayPart?

If the SynchronizationPart throws away values until the CONTROL pin is fired by PartA, then only part of the social security number would be inserted into the ArrayPart.

...Ok, I looked closer into they synch java package. I don't think the package will support my proposed situation.

Ideas?

The part's behavior in Buildap configuration depends on part's specifics (how it designed to behave)
That is;

1. ArrayPart designed so that it will collect incomming events to it's internal buffer if array is not initilaized yet, and then initialized will apply all events to newly created array.

2. ArrayPart designed so thant it will check if array already initialized then apply event to the array if not dismiss it.

Other policies could be defined upon part but generaly speaking "Part is responsible for its behavior" and not the environment in which it is used.

Solution: there should be enough variety of single purpose part with different behaviors for satisfying different aspects of usage, or part should be designed so that the behavior of which can be configured.

In some cases specific of part behavior could be adjusted when combining it with other ones. (like synch parts etc)