Re: Informix news release in my mailbox

On Sun, 17 May 1998 14:36:51 +0100, David Williams <djw@smooth1.demon.co.uk> wrote: >In article <355befc2.1079234@news.newmedia.no>, Nils Myklebust ><Nils.Myklebust@nmdata.com> writes >> >>>- OPEN WINDOW window_name in a variable >> >>Of course, except that open window is in itself a design error. There > ??? >>should have been a define window that didn't open anything at all. >>Then you could have used current window is at will anywhere in your >>application. > Surely the you don't define the window before the first time you need > to make it current do you? defining a window and not immediately > making it current would be a waste of resources... > > OPEN = DEFINE+MAKE CURRENT! No, I usually don't. But the current open with this combination doesn't work very well. What we have done is writing a function that keeps track of which windows are allready opened, and which are not. To display a window we call this function with the window name as a parameter (we use smallint for the name now, but should have used a char variable for readability). This function will do an open if the window isn't allready open, a current window is if it is opened. In this way programming becomes real easy. We can call this function to display any window at any time. It also keeps track of what is the current window, so we can at any time find that in a function that needs it's own window, display the functions window and at the end go back to the previous window whatever that was. Using this function we could of course also easily have implemented a close window function that would have released resources. We haven't however. Firstly we have found that users generally use some set of windows, and keeping them open doesn't realy cost much. Actually I know of no detrimental effect of keeping all windows the user have used in a session open. As to memory usage I am currently not that conserned about it. Memory is rather cheap and another windows doesn't necessarily take up much anyway. This may of course be an issue if you have a very large number of users and are more or less starved on memory. If you are our solution can handle it by a simple implementation of a close window function. However another issue may also come into play. As windows are opened from definitions stored in disk files you *may* get more disk I/O and it may take too long to open another window. This last was an issue a very very long time ago when we had programs running on PC/XT machines with slow disks (you may remember the 85 ms, 20 Mb drives). May be non of this counts any more. What we do gain with our solution is very simple programming with little or no risk of going wrong. Now, when I said I wanted a define window that didn't open the window, may be I was wrong. May be an open window or a similar statement that would open the window from the disk file if it wasn't allready opened, otherwise just display it, would be the right thing. That's what we actually do now, and you are right, it would save some resources. That's also the change I think happened from version 1.0 to 2.0 of Visual Basic. In version 1.0 you had to open a form before it could be displayed. In some later version you could just display it, and it would be opened if it wasn't allready open. You can still "close" it so it doesn't take up any resources. This change made it simple to handle forms. Before this change it was very hard, as it is in Informix 4GL now without our type of helper function. The problem with our helper function is that you have to write and maintain it. That's some work that we don't like to do when it could so easily have been handled automatically by 4GL. >>You do need a way to find out what is the current window > > Agreed, this is something that is really needed. I used to support a > very large app which could have up to 40 windows open at the same time > > search-> results list -> item view -> connections list -> item view > ...up to 20 lists deep! > > Of course these windows were different sizes and failing to close one > on the way back up the 'stack' would mean the because window 17 was > still open a display in window 2 would be outside the limits of the > current window! The amount of time it took to find the problem was > vast! Especially when an error window was displayed only if an error > message need to displayed i.e. the open was amongst nested if > statements and the close was in the wrong place!! > > I did ask Informi Tech Support but they do not track which window > is current by name. Looking at the generated C code 4GL uses an > _EFwindow struct which has hte variable name defined after the > window. Only the form name is available... It shouldn't be to hard to add the window name. It's available to the compiler the same way the form name is, so it should be a simple matter of putting it into the struct. It would then be a simple matter of some kind of search or lookup to find the name of the current window and equally simple to use this at runtime to enable the use of windows names in variables. >>so you could open a window at the start of a function and go back to >>whatever was the current window before that without closing the opened >>window. A stack of windows doesn't work. You need to say: >> > Why do you need to do that? Surely a function should free any > resources it creates? (MEmory leak!!) First there is *no* memory leak in this! It would only have been a memory leak if calling that function repeatedly would have used more and more memory. It obviously doesn't. The next time the function is called it uses the same window that is already open. This (and any time later) it simply executes "current window is ..." to get to this window (via the helper function mentioned above). If you do want to release the resources of this window it would be a simple matter to extend the helper function with an option to close the window. As I said I have found no need for that as the resources used to keep the window open are minor. And why do I need to do it? It makes for the most simple programming I can think of: Display any window at any time you want and then forget about it. You may say: But then windows may stay open at times you don't want that. Yes, it does happen. If that is a problem - close them. Alternatively we just redisplay the windows as needed. Most of the time this isn't a problem though. With only a 24 by 80 screen to play with the user will go back to some window (or the main form) that covers all of the screen often enough that it's not a significant problem. Other times it's an advantage, sometimes even a distinct requirement, that the previous window isn't closed as the user wants or needs to see the content of that window while working in the next. Advanced usage of windows have many requirements. The biggest negative in all this isn't actually the lack of a way to display any window at any time without consern for having to either open it or use current window is. We have solved that, although with some effort. The big problem is that one can't display to anything but the current window. This sometimes causes significant windows flicker@@NL