the tree approach isn't the most simple to use, but it gives alot of flexibility... http://forums.sscentral.com/index.php?s=&a...st&p=150670 the thing I didn't like about your design was that everything was at the same place, and it was pretty heavy... if everything needed was there, it would be fine, but it was still needing a lot of buttons to add/remove of each element (images, files)... plus handling screenobjects would require some kind of additionnal form, or more fields , and more buttons to choose if it's a mapobject/screenobject.... plus you had only one list to show images/mapobjects... the distinction between a map object and an image definition is quite important, especially when you need to consider the limit of 255 image definitions (However, it could be done with some code to compare each map object you defined, and make the image definitions needed out of them, re-using the same if needed) I'm not saying it sucks, but it would have needed some more coding and we didn't feel like spending much time on this for now (If we had spent more time, dcme would still have no LVZ functionnality whatsoever ) I'm not saying our current approach is much better either... but its structure is somewhat closer to MGB's lvztoolkit, so I just felt more confortable to start it like this... It will obviously be improved in the next versions, still not sure how though...