In a message dated 11/04/05 20:34:25 GMT Daylight Time, [EMAIL PROTECTED] writes:
> 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? > On reflection I can see that MWDEF, being passed the variable ch% by reference, can store its address (which is given in the Name Table relative to the VV area) in a spare long word attached to the window definition at "adr". This will allow all subsequent extensions which are given adr as parameter to access the variable ch%. Hence MCALL could easily send the error code to ch%. If this is how it works then all that is needed is that ch% be passed to MWDEF by reference. Since Turbo does this MCALL should operate as hoped. The only snag I can see is if the code for MWDEF, which has to tell whether the channel is sent by reference or value, gets it wrong for Turbo. This could happen if, for example, MWDEF assumes (wrongly) that the parameter is passed by value if the pointer to the Name List in the Name Table is -1. I imagine this is very unlikely. George _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
