NewEra Conundrums - Responses Plus

In regards to Spokey's response: I am most assuredly not trying to follow Fourgen's coding philosophy with NewEra, even if that was possible. I do, however, want to retain some of the apparent functionality for the users. I mentioned Fourgen's zoom screens only as an illustration of a kind of pick list. It is very helpful to our users to allow entering partial values in particular fields. When this occurs, we want a screen to display those records that fit the partial definition. Should none of the records in the list be appropriate, we want the user to be able to enter new selection criteria - possibly based on criteria not found on the main screen. I did consider using a List Box but I think implimenting it would be too clumsy as I would still need an additional screen for new criteria as well as various buttons and such to control it. My problem with stack errors came when I was trying different configurations of project and program definitions. I was eliminating and creating different projects and associated programs hoping to find an optimum directory structure for my overall system. I have one normalTop screen which can call two different zoom programs. These zoom programs are started with run statements. They are indeed separate programs (4gi's) but are part of the same overall project. This means that I have three 4gi's associated with a program and all three directly access the same database. I have since created several more normalTop screens for this program and have not had any more stack errors. So, I'm still not sure what the manuals mean when they say you cannot use a run statement to start a program that ALSO accesses a database. I suppose it means its okay as long as the subsequent 4gi's are within the same project. (???). As to the point about deallocating resources (objects); since the zoom programs have their own MAIN I assume that all resources they use will be freed once the window is closed. It may be that I need to be more explicit about it, perhaps use an exit program statement. I haven't tried this yet because I suspect it may cause the overall application to terminate. If the memory problem persists, I might try it, though. I have a new question as well. Again, I wish to retain functionality found in our original system. In this case, Browse screens. After a user does a select on a table, more often than not, multiple records are found. Browse screens are very handy for scrolling through this list rather than forcing the user to look at one record at-a-time. Examples throughout NewEra documentation show associated grid screens but all are of one to many relationships. I would like to open a screen using the pre-existing supertable array (or is it a vector?). Our users like being able to go from one screen to the other and back again, without losing their position in the queue. If anyone has suggestions about the best way to handle this please let me know. I haven't tried writing anything for this yet as I'd rather not use up my client's money experimenting. ---------- There are more things in heaven and earth, Horatio, ---------------- Scott Holmes <sholmes@netcom.com> Informix 4GL Applications --------------- Than are dreamt of in your philosophy. ------------------------