In the process of my app's execution, it needs to put up a UI, and pause until the UI returns an object (only this piece of code needs to pause, the rest of the world can keep going). I was thinking of using forks, but FillInTheBlankMorph seems to manually drive the world's doOneCycle while it waits (seems ugly and a little too controlling).
What would be the best way?
Thanks. Sean
On 05.11.2010, at 23:18, Sean P. DeNigris wrote:
In the process of my app's execution, it needs to put up a UI, and pause until the UI returns an object (only this piece of code needs to pause, the rest of the world can keep going). I was thinking of using forks, but FillInTheBlankMorph seems to manually drive the world's doOneCycle while it waits (seems ugly and a little too controlling).
What would be the best way?
Redesign your app so it does not have to pause but is event-driven (or possibly continuation-based). Then just lock the part that should not be interactive.
FillInTheBlank has to do that ugly doOneCycle because it was made to work with non-eventdriven programs.
- Bert -
Bert Freudenberg wrote:
Redesign your app so it does not have to pause but is event-driven (or possibly continuation-based).
That sounds promising. A little more detail to clarify. At this point, the app could be driven through the API, and there may be no GUI (definitely for now, because I haven't designed the GUI, lol). However, the app will need user information here to continue its work. So... * Events - would only be if I had a GUI before I opened this request, right? * Continuations - I'm not so familiar with them (a little Seaside). Are you saying to supply the GUI with a callback selector/block?
Thanks.
Sean
On 07.11.2010, at 16:39, Sean P. DeNigris wrote:
Bert Freudenberg wrote:
Redesign your app so it does not have to pause but is event-driven (or possibly continuation-based).
That sounds promising. A little more detail to clarify. At this point, the app could be driven through the API, and there may be no GUI (definitely for now, because I haven't designed the GUI, lol). However, the app will need user information here to continue its work.
How would it get that info without a GUI?
So...
- Events - would only be if I had a GUI before I opened this request, right?
Well, that's what I assumed, yes.
- Continuations - I'm not so familiar with them (a little Seaside). Are you
saying to supply the GUI with a callback selector/block?
Exactly.
- Bert -
Continuations it is then. Is there a big difference between passing a block vs. a receiver and selector. The block way seems simpler and more flexible - any downside?
Sean
On 08.11.2010, at 16:51, Sean P. DeNigris wrote:
Continuations it is then. Is there a big difference between passing a block vs. a receiver and selector. The block way seems simpler and more flexible
- any downside?
Blocks are harder to debug, and dangerously powerful. In my designs I try to stay away from ever storing a block for later use.
You might substitute a MessageSend for the Block. Nicely explicit and simple.
- Bert -
Bert Freudenberg wrote:
You might substitute a MessageSend for the Block. Nicely explicit and simple.
Okay, thanks. I'll try that.
Sean
beginners@lists.squeakfoundation.org
-
Bert Freudenberg -
Sean P. DeNigris