We actually have two maps - mainline, schematic drawn using data in a table and VFP objects, and yard, we use a BMP for this. Trains, as well as mainline stations are objects, and their size and position are based on data in the drawing table, as well as operational data and some algorithm in the class code. The form is resizable, and having each object taking care of itself makes it a lot easier to code. It is true, we lost the 'visual' of design, but in case of trains that would be meaningless anyway, and considering the big number of track lines, track features, stations, etc. having them data-driven is more manageable.

>Well, I think you are right. Your idea is that (as with any objects) additional elements (properties, etc.) may be added later. I will consult this with my client.
>
>On the other hand, let's see if I can understand your idea in detail. Do you mean that even the position of an object on screen is coded in the database? How is the original map designed? Are the trains "attached" to objects that are drawn statically on the screen?
>
>Because, if you have the entire drawing in the database, you lose the visual (WYSIWYG) element.
>
>>It looks like one attempt to reply got lost in the UT hickup. Let's try again...
>>I wouldn't call it an 'interesting alternative' (as opposed to 'more elegant methods'), unless you consider OO design an interesting alternative to hard coding. For the moment it may seem simpler to leave the code as is, but that's about the only reason to not use a class. It does not matter that the objects are not moving, or that for now you only need to show the power.