On Thursday 12 Feb 2004 4:19 pm, James Edward Gray II wrote: > On Feb 12, 2004, at 9:21 AM, Gary Stainburn wrote: > > 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.
The penny's dropped. I see what you're getting at. However there is a drawback. The Tk interface of the training sim could do as you suggest and simply repaint the entire window on a regular basis using a snapshot of Trainset. However, for the model railway use this is not sufficient. The interface then needs to know about specific state changes in order to ensure that the correct commands are issued to the controller. > > 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 am aware of this and have taken on board the things you've said before. Rethinking which object performs which task will help reduce the need to loop backs. For instance having a lever drive a gantry which drives a signal eliminates the need for a loopback from the signal to the gantry. This I got from your previous replies and they have greatly helped simplify my code. However, because of the extent of inter-dependancy, I don't think I can get away without them alltogether. > > 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. This is pretty much what I had in mind. I.e. the gantry (connection) would simply tell the Trainset (server) ' I've changed, deal with it', and the Trainset would. > > 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. This if you remember was why I started my first RFC thread. Again, thanks to your replies and those of others on the list I hope to try to avoid this as much as possible. > > 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. Agreed, and slowly I'm getting there. > > 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. > After Wiggin's and your responses today, I think I'll have to revisit POE and see what it does. I had hoped not to to maintain simplicity of code and deployment, but I think I may end up needing it once I get to more that one input source so I may as well do it now. > 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 Once again, thanks for your thoughts. Gary -- Gary Stainburn This email does not contain private or confidential material as it may be snooped on by interested government parties for unknown and undisclosed purposes - Regulation of Investigatory Powers Act, 2000 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
