That might be a solution. However, let's not do it just yet. It may be that once I have gotten the rest of the user interface in place there may be a more obvious thing that should be done.
Regards, Elias On 12 Jun 2014 17:55, "Juergen Sauermann" <juergen.sauerm...@t-online.de> wrote: > Hi Elias, > > normally )CLEAR does the job. Could be that some .so files remain loaded > but that should > not matter. So I could simply redirect )OFF to )CLEAR under android. > > /// Jürgen > > > On 06/12/2014 05:48 PM, Elias Mårtenson wrote: > > Well, this is arguably not the biggest issue right now. ☺ It is, however, > something I came across during my experimentation. > > I have to admit that I'm not sure what is the logical thing to do when > receiving the )OFF command. Android applications generally never exits. I > suppose doing a full restart of the APL interpreter is the most logical > thing to do. > > Is there a way to do this without exiting? > > Regards, > Elias > On 12 Jun 2014 17:43, "Juergen Sauermann" <juergen.sauerm...@t-online.de> > wrote: > >> Hi Elias, >> >> we have the HAVE_ANDROID macro already, so I can return from )OFF >> without doing anything under android. >> >> Note that cmd_OFF is called from other places as well, not >> sure how they react if we return instead of exit()-ing. >> >> /// Jürgen >> >> >> On 06/12/2014 05:20 PM, Elias Mårtenson wrote: >> >>> On Android, one does not want )OFF to actually kill the process itself, >>> since this instantly kills everything, which is problematic for an Android >>> application. >>> >>> Of course, I can check the command typed in the input field before >>> sending it to the interpreter, but with the arrival of commands being >>> executable, this is not a complete solution. >>> >>> Would it make sense to add a callback that I can set that will be called >>> when the )OFF command is issued, and you only fall back to the default >>> behaviour if this callback is NULL? >>> >>> Regards, >>> Elias >>> >> >> >
