Re: Informix 4GL question

Douglas Wilson wrote: > > I've helped users who were allowed to do this sort of thing, didn't > realize they > were already 5 or 10 levels deep, then wonder why they're getting > errors. If you really want to allow the back and forth calling (it > can be useful I admit), you could > pass in some argument to only allow just so many levels of calling, and > maybe warn the user that they're already so many levels deep and using > up > system resources, and maybe to please release them. > > Douglas Wilson > > Belakimem wrote: > > > > Suppose you have an orders screen / function with an option to transfer to > > the customer screen. > > > > Suppose also your customer screen / function can transfer to the orders > > screen. > > > > Both functions can be called from a menu in main first, and both have an > > option to exit back to the main menu. > > > > Now, it is obviously possible to call customers then orders, then > > customer, then orders etc. and travel endlessly down many levels of the > > function / subroutine stack. > > > > In 4GL would this be good programming practice? What are your opinions on > > avoiding this problem, if it is one. Is it better to always return to the > > calling function before going into this spiral? > > > > Please reply to my email address as well as the newsgroup. Thank You. My method of popping back and forth between two or more screens in to have one function that can call one or more screen functions. The first screen function called is based on the passed parameter. The return value is the used to determine if it needs to go to another screen or return. Basically it creates a simple state table where one screen function can tell the state engine which screen to go to next. Each screen function is responsible for displaying it's form and data. The data structures the screen functions use are usually global or the values they need to fetch there data are global or passed in. Often the low level functions just use the current window or are very specific (I tend to prefer the current window and making sure that the maser function that called it all straightens itself out or handles the subwindow creation). S.W. wilcoxon@pioneerplanet.infi.net ********************************************************************** ... this is only a test ... if this had been a real signature it would have been interesting **********************************************************************