Re: get_fldbuf(variable-field-name)

In article <E8qoKo.I2x@nonexistent.com>, Jacob Salomon <jake@apparel.net> writes >If you've been following this thread, page up a couple of screens. > >My original message, edited for brevity (which does little in my case ;) > >|I have a problem that cannot be solved by standard 4GL. I am trying to >|improve upon the FourGen help subsystem in ways that I'd rather not >|detail right now. The main issue is that I need a uniform way to get >|the value in the current field at the moment the user presses a >|function key for field level help. FourGen has already generated the >|code to save the name of the current field in a "before field" clause. >|I'd like to use that string - the field name - to call get_fldbuf() and >|obtain the value currently in that field. This cannot be done in 4GL; > >--SNIP (Description of experiment, request for undocumented info) SNIP-- > >Marco Greco Responded: (Also edited for clarity) > >|the following snippet comes straight from the fglc2 precompiler and >|shows the expansion of get_fldbuf >| >|static _EFFIELD _sqfldlst[] = { >|{".customer",0}, >|{0}}; >| >|fgl_nret = _ef_fldbuf(_sqfldlst, &_sqicb); >|if (fgl_nret != 1) >|... >| >|Since you will have to play with the internal workings of 4gl, my >|feeling is(I thought of doing something like that, years ago) that >| >|1) whatever you do, you will only be able to do it with 4gl-c >|2) you will have to write some sort of precompiler that adjusts >| 4gl generated c code to include a reference to the appropriate >| _sqicb struct >| >|All in all, if at all possible, you're better off doing it the >|traditional way: a huge case. > >This is Jake again. > >Marco, I took you up on your expanded code and also looked at the >expansion of the CONSRUCT statement. The expanded code opens a program >block with a left brace "{" and defines a variable local to that block >only. It is defined as: > > _EFICB _sqicb; > >where _EFICB is a typedef of a reasonable but loooong structure we might >call an Input Control Block. > >The pseudo-call to get_fldbuf() expands, as y'all can see above, to >passing an array of ASCII field names and the address of the input >control block, in this case &_sqicb. The actual C function called is >_ef_fldbuf(). As Marco pointed out, I cannot do this in direct 4GL. If >I want to pass the address of the local _sqicb to a function, I would >have to finagle with the generated ec code. > >Riiiiight! I don't have enough grief in my life! :-^)) I was willing >to write 4gl-wrappers for callable C functions but messing with >generated code is a recipe for brain damage. > >In a spirit of denial-of-futility, I might repeat an old request that >Informix add features to 4GL to make aspects of the internal structures >(like input and field control blocks) more accessible to the >programmer. But I have been asking for these features for so many >years, I've lost my spirit. (Sounds like I need a beer. ;-) > >-- Jake (In pursuit of undomesticated aquatic avians) > >+-----------------------------------------------------------+ >| Impeccable Logic: A thought process which successfully | >| resists chicken bites | >+-----------------------------------------------------------+ Yes - I would also like windows (struct WINDOW *?), forms and menus to be documented - how do I find which windows and forms I have open? I can't. How do I find out which window is current? Again I can't. I had a nasty error where a window was not closed (this window had NO border hence was 'invisible'!) this meant that a display.. AT.. failed. A glance at the code indicated that a large window should have be open at that time. I had to track down several layers of searches/results list to find the bug.... The eventual reply from informix was that they do not track which form files are open!! -- David Williams