trevor

It would be real nice if one could flag events in the event handler so that the simulation would auto-pause either before or after that event happened and have the EV pop up.

1.Paste should paste wherever the mouse is, not at an offset from the original. It can be a chore if you are pasting from one side of the map and have to drag it to the other when you are zoomed in. 2. When dragging an object around, the map should auto-scroll when the mouse hits the edge of the client area. (Window). This one is also true for dragging objects in the event handler.

Changing a track geometry using the EDIT button on the objects properties dialog clears any already assigned variables.

Sweet I figured that was probably related. Not sure what you wrote this in. I strongly recommend dictionary objects or using routines that play the higher-lower game for looking up sorted lists of text. If you are using simple for I = 1 to ubound, it is horribly inefficient. OF course dictionaries wont help much unless u force folks to use unique names.

Hi Henry, Thanks for that explanation and doing the translations. So what you are saying is, it is NOT REALLY an event handler but a state monitoring sequence. I had already determined that handlers triggered by the same event were executed in top down order in the EV but had no idea it was checking states of all of them and not EVENT driven as the name implies. I will take that into consideration. It also appears to take a "Snapshot" of the layout state before running the events. A change made in one event may not be detected in the conditions of the next one in sequence. The latter makes creating an ELSE event problematic. Even with all that, it is still horribly slow though.

Here is the test layout I am working on. I am trying to build an automated sectioned layout with section controllers and train controllers. Only one train can own a section and enter / occupy it at any given time. A timer is used to sequence the navigation events in each controller. I make quite heavy use of pointers attached to objects to reference other objects so that the event handlers can be easily duplicated as I add more sections and trains. I am also using controller switches to trigger events since I need the Trigger properties attached to those. (Using simple Variables does not allow me that luxury) Performance is pretty bad. Navigation requests can take more than 1/4 sec which Is a problem since that's longer than the navigation timer window allotted to each train. Granted I am doing quite a lot in those windows, but really.... it should not take that long to check that 20 or so tracks are clear and toggle a few controllers. I suspect the performance delay has to do with all the string lookups. I am a professional software developer, writing software that processes and searches through tens of thousands of records. If my code took 1/4s to sort through <100 I'd be out of a job. Perhaps I can give you some pointers. I'd love to talk to you guys 1 on 1. If you watch the trains they do not run smoothly but hesitate at regular intervals. BTW My system is top of the line with medium graphics capability, Frame rate on that layout is 50FPS so that should not be causing the hesitation. Test21.mbp

It seems to me that the simulation pauses whenever an event is triggered. For small events this is hardly noticeable, but those that have a more complex sequence of chained events this hesitation is extremely noticeable and almost nullified the usefulness of the application... Obviously it gets worse the bigger the layout and the more events that fire.

Labels give us the ability to align text left right or centre, however that does not impact the justification of the label itself on the board which auto-size to fit the text.. Either make it so the x-y origin of the label is either at the left right or centre based on the text setting, or let us fix the size of the label box so we can align them manually ourselves. In some ways, the latter would actually be the better solution. Then we can make it as wide and tall as we want. If the text doesn't fit... too bad. Or perhaps make the latter an option. This is particularly an issue with labels that are set dynamically by the event handles. Hard to make a nice table of left justified text when the darn labels keep resizing and effectively moving.

I agree. I find it easier do the layouts in the technical design view. There open ends on tracks are shown as red lines. What I find more disturbing is tracks are shown as joined, and the trains will pass over that join, but the join is really bad and the train jolts as it passes over them. Me thinks tracks that are joined should auto-align somehow.

Might I suggest you turn off the gizmo unless you really need to use it. I also find it finicky... and have learned to zoom in and move the view around when using it so the particular part I want to click on is clearly distinct and clickable.

I had the same problem lys, now I turn off the gizmo (which it took me forever to figure what it was) and only turn it on when I need to rotate something.

Currently you can only run one instance of the application. It would be nice to open more than one layout at a time in separate runs of the application and be able to copy and paste between them.

This is a biggy It would be great if we could have the ability to create an object that contains other objects then instantiate that custom object on our layouts, The object would work sort of like a selection group but with the following added functionality. 1. Ability to reference each item within the group with dot notation... e.g. Controller_1.Enable_Switch 2. New native variable in each object that identifies the Parent container. 3. Each object should have it's OWN event handler and a new separate global variable namespace in addition to the layouts namespace. 4. Ability to save the object as a library object and place it on other layouts. In my example I am using a bunch of these identical "section" objects which monitor, display and control track sections. Each object on it is specific to a particular track section. Currently, obviously, they are all individual objects. I need to be careful with naming conventions and editing common variables on each that point at the a master object for that group. It would be so much nicer if I could create that object in a separate editor, and edit the common event code there too. This feature would also be useful for making a library of other sub-designs that could be re-used on other layouts, not just for active elements. For example, one could spend hours building an intricate bridge structure, it would be nice to save that work as a new library object and use it on other projects. Or perhaps you develop some parking lot with cars moving around and parking and want to reuse it with all its built in (and hidden) event handlers on a new layout. The possibilities are endless It might even be nice to share them. Note: Separate editor could simply mean another instance of the existing program, and the addition of a "Save As Object Model" function.

Why not just use $(_Trigger1.Camera) ?

I find myself duplicating whole groups of code in the event handler with the only difference between each group being the initial entry condition of all the events within. The remainder of the conditions and actions make use of the Triggers and pointers defined in the originating objects variables.. This of course makes it a horrible task if I need to make a small change to the logic since I have to properly replicate the change to 10s or maybe even hundreds of groups. To rectify that, it would greatly simplify matters if you could change the EV to do the following. 1. Add ANY or ALL to EVERY event condition. You already have "All Locomotives" in the train enters track, but there is no "All Tracks" state. We have the conditions statements to refine the event, and with the addition of the _Triggers, that includes filtering the name if need be. 2. As possibly a better alternative, if I use the "User Defined" choice and enter say the name "Train_Enable" the event should toggle for ANY OBJECT with that name. That way I can have common controls for all trains on the board with variables set in each to properly point at the objects under control rather than having different event code for each. Actually the more I think about it.. both features would be a nice addition. Here is a typical example.... On my layout I have numerous small tracks called "Section_Entry_(Number)". The EV detects a train entering and leaving that section and sets a SECTION object state appropriately. Currently I need an EV entry for every single one of them..... The EV statements are ALL identical (or should be) bar the entry condition itself. It would be so much simpler if... 1. I had a global Train enters track - Any Train - Any Track event 2. I added a variable to the track sections to identify their type... e.g. Type = "Section_Entry" 3. I added a second variable to the track section to reference the section itself, e.g. Section = "Section_12" 4. I made a single event handler that checked for the type and then performed the appropriate actions on the referenced section. Similarly, this example would ALSO work if I gave ALL those track sections the same name and the User_Defined setting acted on all objects with that name. Though having lots of objects with the same name does present other issues. NOTE I SAID EVERY OBJECT EVENT... The same issue exists with track switches, controllers et.al. The only one I can currently think of that does not merit an ALL selection is "variable has changed" since variables do not have sub-variables. Though someone might argue the use of the variable pointing at an object that does might merit the addition. Trevor

ya but it would be nice to be able to reference the parent object in the EV

It would also help a lot if the variables list in the event manager also listed the native properties of objects., perhaps with a switch to optionally show them. Not only would it help us change them. but it also acts as a visual teaching function so users can see what they can control on each object.

Is there a list of built in object properties somewhere? Specifically I'd like to too look up what an object is connected to by that little chain button on the object properties.

Rather than putting the catalog name in as the object name, add it as built in variable. Make the name more generic, e.g. Track_(N) or Engine_(N) etc. where N is the next available unused number. Two reasons for this. 1 . It would be nice after you change the object's name to something else, to be able to tell exactly which catalog model it came from so you can find it and use it elsewhere. This is especially true of track sections which all look the same to me 2. Doing so would give you the opportunity to add a button to allow us to CHANGE the catalog model of the object without having to rip it up and add a new model. The latter sounds trivial UNLESS you have 50 variables attached to the object. Since there is no way to copy variables from object to object, rip-up-and-replace can be a horrible chore....

When I select an object with name say "Track", then copy and paste it, the new object should - auto name as Track_1 if that name is not already used... or - the next available number if it is. If I do the same with a group of objects each element within that group should also be renamed. FURTHER, the program should NEVER allow you to re-use an existing name unless you plan on adding an index so you can reference the names numeration. It would also be nice if the objects catalog model name was also saved to a different property. See other suggestion.

Can you change the variables list in the event manager to use a tree-view instead of a simple list. The list gets awful long when you are using numerous objects each with their own set of variables.

Can you please make dialogs like this sizeable PRETTY PLEASE

Editing the variables of an object directly by clicking on the three bars at the top right of the object properties window can cause serious unexpected loss of simulation synchronization if you do so while the simulation is running. I suggest a change to the program to auto-pause the simulation when this is clicked. The same way as you do with the event manager. Work around ... REMEMBER TO PAUSE BEFORE EDITING THIS WAY.

Yes I understand that principle, but it is weird and inconsistent depending on the test or action selected. Where it expects a NAME the $ can mess it up. Some places when you think it SHOULD expect a name you need the $.... I end up trying it one way, testing (debugging is NOT a simple matter with complex criteria), then adding or removing the $ to see if it helps.

Not sure that is true Curt, it seems to be more to do with "this is a name not a string"... but sometimes u need it, sometimes you don't.