RE: 4gl 7.20 UD4

Cool, Thank you. That certainly explains all. btw - the code is not mine...it's <gah> Tecsys... James Tibbets MCS Limited Hamilton Bermuda jtibb@mcs.bm -----Original Message----- From: Jonathan Leffler [SMTP:jleffler@informix.com] Sent: Tuesday, February 09, 1999 4:04 PM To: James Tibbets Cc: Informix NewsGroup; Informix Tech Pubs Subject: Re: 4gl 7.20 UD4 On Tue, 9 Feb 1999, James Tibbets wrote: > Hello all (Johnathan Leffler?), Jahmes Tibbets? > Under 4gl 7.20 UD4 why will this type of statement in a report function: > > ON EVERY ROW > if G_FIRST_ROW then > if G_FIRST_ROW = 2 then > SKIP 2 LINES > let g_message = get_message(162) > PRINT COLUMN 1, g_message > SKIP 2 LINES > return > | > | This type of statement cannot be used in a report. > | > | See error number -4492. > end if > let G_FIRST_ROW = 0 > end if > > produce error -4492: > -4492 Warning: The parameter is assigned a new default value. > > More than one copy of the function prototype has occurred in the > current scope, and the one indicated by this message has specified a > different default value for a formal parameter than that specified by > any prototypes already encountered. OK - there are two or more parts to this. (1) Why can't you use RETURN in a REPORT any more? (2) Why doesn't the error message get reported accurately. Part 1 is an I4GL issue; part 2 is a documentation issue. Let's deal with part 1 first -- it's easier. > and why did it use to work in Version 6.01.UD2? Because the restriction wasn't in place until 6.02. > Is this a change in functionality or a bug? Change in functionality. It was documented in the 6.02 release. It was necessary as the behaviour of a RETURN inside a report can lead to the most odd problems, especially in a PAGE HEADER or PAGE TRAILER section (where you could end up with a report that was neither active nor inactive - so you could not do OUTPUT TO REPORT or FINISH REPORT or START REPORT without getting conflicting errors). What's the workaround? Well, obviously you have to remove the RETURN. You then need to ensure that the code in the ON EVERY ROW block doesn't do anything more for the case where the RETURN used to be executed. As far as I can tell from looking at the sample code, unless the code outside the report modifies g_first_row, then once you get into the IF g_first_row = 2 THEN block, you always go through that block; the code does not reset g_first_row. That makes it a bit difficult to rewrite comfortably, but the revised logic for this block needs to be: ON EVERY ROW IF g_first_row THEN IF g_first_row = 2 THEN SKIP 2 LINES LET g_message = get_message(162) PRINT COLUMN 1, g_message SKIP 2 LINES -- RETURN -- no longer allowed ELSE LET g_first_row = 0 END IF END IF However, you also need to ensure that when you go through the g_first_row = 2 code, the rest of the printing code in the ON EVERY ROW clause after the shown code is skipped. You might do that with an auxilliary variable: ON EVERY ROW LET oer_skip = FALSE IF g_first_row THEN IF g_first_row = 2 THEN SKIP 2 LINES LET g_message = get_message(162) PRINT COLUMN 1, g_message SKIP 2 LINES LET oer_skip = TRUE -- RETURN -- no longer allowed ELSE LET g_first_row = 0 END IF END IF IF oer_skip = FALSE THEN ...other printing code... END IF Now, as to part 2, the message you are getting comes from errmsg.txt. The error message explanation is correct for NewEra. Unfortunately, the NewEra team decided to pre-empt whole swathes of error message numbers which were allocated to I4GL without notifying the I4GL team that they (the I4GL team) no longer had control of the I4GL message files. When the I4GL team added error messages, they used previously unallocated error numbers, blissfully unaware that the NewEra team lumbering towards a release had seized control of the I4GL message files. So, there are two different meanings for this error number, and errmsg.txt reports the NewEra meaning, not the I4GL meaning (even though the I4GL compiler puts the correct error message into the compilation error file. Put politely, its all fouled up. I'll notify those in charge of the errmsg.txt and its translations, and we can get the two divergent meanings into errmsg.txt, perhaps, eventually. Or we can end up dropping the NewEra versions of the messages, but that will take longer still. Yours, Jonathan Leffler (jleffler@informix.com) #include <wish/I/was/skiing.h> Guardian of DBD::Informix v0.60 (v0.61_02) -- http://www.perl.com/CPAN Informix IDN for D4GL & Linux -- http://www.informix.com/idn