Rene,
Is the recommendation then here to split complex dialogs into smaller units? IE In version 1.3x I currently have one main input statement that controls the input of a buyers name/address and buying parameters and also then an input array that controls the contact methods for that buyer.
In this old pre multiple dialog, the code 'called' a standard address input function and after the final address field called the contact method input, then carried on with the rest of the 'parameter' fields.
It would seem now that I have to split the input into 2 - and to structure the code as:
DIALOG
1) Input of buyer base details
2) Input array of contact methods
3) Input of buyer parameters
Presumably that is the only way I can stop the 'mandatory' parameters from inhibiting the 'flow' from the address into the contact methods.
Lastly, as said above, we had a couple of standard functions that simplified the input of 'common' structures (addresses, contact methods)
- obviously we then had to try to emulate Multiple Dialog by jumping to the correct fields on the form. The benefit was though, that we had simple self contained functions. Now, is the only way to handle this type of dialog, repeating the same code? IE if I have 5 modules that input an address plus other 'data', do I now have to repeat the address input code in 5 places? Is there a way of doing:
DIALOG
CALL INPUT FUNCTION 1 (DIALOG)
INPUT OTHER DETAILS
END DIALOG
...or is the handling of repeated code now expected to occur via compiler 'include' type directives?