07-30-2013 09:09 AM
@flongnos wrote:
In my application, I would like the UI to remain responsive continuously, and not wait for parallel loops to end execution.
@ Neil: Beside looking out for user events, the producer also updates one pure GUI element (the wafer map) according to the event triggered. For that some code must be inside the event structure, and so far it works perfectly.
You have mentioned about Actor Framework. Do you think it's worth implementing in my situation?
If you want to update this GUI element from both loops, make it a consumer command. "Update GUI" or something, updating the item.
As a general solution i find it very good to use a simple Cluster as queue-data, a type-def'd command and a variant.
In this case you could add the value as the variant and convert it back in the consumer.
/Y
07-31-2013 11:16 AM - edited 07-31-2013 11:17 AM
Yamaeda, I was quite skeptical at the beginning to move the GUI element (Wafer Map) to the consumer, as there were Mouse Events related to it, which are:
- Mouse Move to extract XY coordinates on the Picture Indicator
- Mouse Down to either change the color of an element inside Picture Indicator OR command the prober to go to the die corresponding to the selected element of the Picture Indicator
But finally I tried again and with careful coding, I could send the resulting modifications due to these events, through a queue, to the consumer. And the Picture Indicator could actually update very well.
Thanks to this, I am now able to implement a test sequence using the consumer as a Queued State Machine.
Thank you a lot.
Regards,
Florian