In a message dated 09/04/05 15:28:16 GMT Daylight Time, [EMAIL PROTECTED] writes:
> > All EasyPtr keywords can return an error code in the channel parameter, > provided it is supplied as an integer, ie #ch%. > > That seems OK. > > However, it gets more > complicated: You can set EasyPtr up so that instead > of a channelnumber you > pass a pointer to the working definition. A designated variable then gets > any error code instead > > 100 adr = MWDEF(#ch%) > 110 REPeat loop > 120 ch% = 0 > 130 action = MCALL(#adr) > 140 if ch% <0: PRINT 'Error during MCALL:'! ch%: EXIT loop ... How does line 120 indicate that ch% is the variable that MCALL is to return the error code? If I knew that I could perhaps tell what Turbo would do!! > > Luckily, both these behaviours are optional. Their main use is for aiding > program development. Turbo should now be able to handle the first scenario > in any case. But it probably doesnt handle the second? > > The main stumbling block was that Turbo couldnt handle arrays being passed > as parameters. With this considerable inconvenience overcome, a major > disincentive to use Turbo has been removed. > I am indeed glad of that. It as also nice to be able to use GET, BGET etc. > > George _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
