I can understand the point that James made, in that the update of the Trainset
objects is being made by a Tk event trigger, and could therefore simply
update the screen at the same time, e.g. clicking on a lever throws a signal
*and* updates the screen. The problem is that it's not allways possible to
know every object that gets affected - the state of the signal may affect
other objects, such as changing a locomotives state from 'Stopped' to 'Clear
To Proceed'. This is the reason behind needing the callback method.
This shouldn't be an issue at all. Remember when we talked about the Trainset object being an interface to the whole underlying system? That's to solve exactly this problem, and many others.
Trianset, at any given time, should be able to describe the entire setup. That's it's job. That's also why the TK widgets, should hold onto a link to the sucker.
Here's how I envision an event happens: Event handler locates correct signal box to flip or train to change, however it does that, and make the change. Event handler calls update/refresh on the appropriate interface object(s), maybe the whole window. Update/refresh do their thing and eventually, I assume we end up in some kind of draw/paint method. In draw/paint we don't care about signal boxes and trains, we just want to do our job. We pull up our stored link to the Trainset, and ask it to tell us what it looks like right now. That will of course include whatever change we recently made to some signal box or train. When it tells us, we draw that.
Trainset just needs to do its job, which is to worry about Trainset stuff, not interfaces. We let the interface objects worry about interfaces and how to display Trainsets, because that's their job.
You're always very quick to resort to serious cross linking in your discussions. This will only increase your pain, remember that. Heck, isn't that the main reason you keep shooting down POE?
I said I had a network server that maintained the links to it's connections, and vise versa. I didn't say it was easy. It was very hard to get right. The problem is that I can be in a connection and need to change my read/write status. Unfortunately, because of the linking, I can't do that, the server would get out of sink. So what should be simple is painful. I call into the server and have it change my read/write status, so both objects stay in sink.
Also remember that creating all these circular links will defeat Perl's garbage collection system, forcing you to manage your own cleanups. I know others have warned you about this in the past.
I know I'm a broken record, but the reason I keep stressing these points is simple: I don't believe you need to do this to yourself. If you keep focused on the top down view and keep your interactions going through Trainset, I truly believe you can spare yourself this pain. I'm just trying to provide the best tips I know how, given the information I have.
The choice is, of course, yours.
If you're going to tie all these things together like that though and keep track of everything, I think you should take Wiggin's advice and go with POE. It's a road tested solution designed to help you solve this problem and you're going to have a learning curve either way you go. Might as well spend your study time gaining skill with a good system that will help you do this and more.
Okay, I'm going to shut up about this now. I am glad you're making progress with your code and I wish you the best of luck, with any implementation you choose.
James
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
