RE: When do 4GL windows become current automatically?

---------- Peter Lancashire (Peter.Lancashire.PL1@bayer.co.uk) asked an interesting question: >There is some undocumented (well, I haven't found it) trickery going on >with 4GL windows. I wonder if anyone can shed any light on it. >What seems to happen is that if a menu is active in a window and a menu >COMMAND block does something that causes another window to become the >current window, returning to the menu causes the window the menu is in >to become current automatically, without the need for a CURRENT WINDOW >statement. >My question is: Is that right? Yes, that is correct. And I'm not certain whether it is documented, but it has been that way for a good long time. I ran into it maybe 8 years ago, and duly modified the design of my I4GL code generator to handle it. >And: does this happen in any other >circumstances, eg with INPUT, DISPLAY or PROMPT statements? It isn't clear cut, and my memory may yet be failing me - sleepless nights with newborns can do that. One of two things will happen if you have code such as: OPEN WINDOW w_input FROM "input" - syntax? INPUT r_data.* FROM s_data.* [...] AFTER fieldN LET newvalue = function_changing_current_window() DISPLAY newvalue TO s_display.somewhere [...] END INPUT Assume that function_changing_current_window() opens a window w_extra and does not close it again - a bad idea. The DISPLAY is going to display to the s_display.somewhere field in the current form, which is the one in w_extra. Because this is not the same form as when function_changing_current_window() was called, then the DISPLAY is likely to fail, or display in the 'wrong' place - actually, the right place but not the place which was wanted. When the INPUT itself continues, one of two things is going to happen: Either the whole process will fail horribly because the incorrect form is currently on display Or the INPUT will ensure that the correct window is on display, like MENU does. From memory, it is more likely the latter, but I wouldn't completely trust my memory (and I don't have I4GL on my machine to verify this). Life could be more complex because it might try poking the current form onto the w_extra window. Or other similar nasties. Certainly, it is not advisable to try exploiting the behaviour. >An observation: inspecting the C header files provided with 4GL shows >that many of the user input structures (like MENU) do have knowledge of >the window they are in. Yes. >A reason for wanting to know: some of my code uses a C function which >allows me to pop the current window off the top of the window stack, >revealing the previously current window. This is essential for modular >code but is not portable. (Why didn't Informix provide a HIDE CURRENT >WINDOW statement?) If 4GL can be relied upon to do the work >automatically I can be more portable. The normal way of writing modular code is to have it open a window, use it, and close it. When the window is closed, the previous window becomes current. You can do more complex things; I've used a full-screen sized window simply to blank out a bunch of previous windows and then start over with an apparently clear screen; closing that window exposed the prior (complex) window. It allowed me to simulate a wide screen INPUT ARRAY where you could either look at the left-hand side or the right-hand side of the display. To add to the complexity; some of the entries in the INPUT ARRAY used 1 line on the screen; others used as many as 5 lines; and as many lines as possible had to be on display. Kinda tricky... Yours, Jonathan Leffler (jleffler@visa.com) #include <bother.ms-exchange.h>