Re: Increasing 32K PCode size limit within a function

david@smooth1.co.uk wrote: > I'm not sure what the limit is in 4GL 7.32 latest but... > > > simplify the screen...how the hell can you have that many lines of > code? > > The array should be a module level variable. If it is complex then > all processing should be done in functions. > > How many fields on the screen? > > Push everything into functions. > > FUNCTION screen5_after_field (lc_current_field) > CASE lc_current_field... > END FUNCTION > > FUNCTION screen5_before_field (lc_current_field) > CASE lc_current_field... > END FUNCTION > > > FUNCTION screen5_input_array() > > INPUT ARRAY... > BEFORE INPUT > CALL screen5_before_input() > > BEFORE FIELD x > CALL screen5_before_field("x") > RETURNING lc_next_field > IF lc_next_field != "EXIT INPUT" THEN > EXIT INPUT > ELSE > NEXT FIELD lc_next_field > END IF > > AFTER FIELD x > CALL screen5_after_field("x") > RETURNING lc_next_field > IF lc_next_field = "EXIT INPUT" THEN > EXIT INPUT > ELSE > NEXT FIELD lc_next_field > END IF > > AFTER INPUT > CALL screen5_after_input() > RETURNING lc_next_field > > IF lc_next_field = "EXIT INPUT" THEN > EXIT INPUT > ELSE > NEXT FIELD lc_next_field > END IF > > END INPUT > > END FUNCTION > > This way you can build test harnesses with > > FUNCTION screen5_test() > LET module_variables= "whatever" > CALL screen5_before_input() > IF module variables not set right then error > > LET module_variables="whatever" > CALL screen5_before_field("x") > RETURNING lc_next_field > IF lc_next_field not set right then error > IF module variables not set right then error > > LET module_variables="whatever" > CALL screen5_after_field("x") > RETURNING lc_next_field > IF lc_next_field not set right then error > IF module variables not set right then error > > CALL screen5_after_input > RETURNING lc_next_field > IF lc_next_field not set right then error > IF module variables not set right then error > > END FUNCTION David: Thank you for your candid yet constructive response. Although 3000 lines may sound like a lot of lines of code for a function there really isn't anything exotic about our what it does. The function contains the INPUT ARRAY logic needed to support all of the rules/edits required by the business. I know you're thinking that it's just the result of 'sloppy' programming, but that really isn't the case. Your idea of splitting the edit logic into seperate function would certainly help, but it makes the logic more complicated and than it should have to be. Obviously, if this is our only choice then we'll have to take on this overhaul, but I thought that there might be a less invasive solution. Pehaps not. Thanks again.

or move to compiled 4GL??

All of production executable are compiled .4GEs, however, for development we need the debugger for diagnosing problems.