|
Hi Elias,
OK, I will do nothing.
BTW I have separated the )commands from the APL statements in
Command::process_line().
/// Jürgen
On 06/12/2014 05:58 PM, Elias Mårtenson wrote:
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"
< address@hidden>
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" < address@hidden>
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
|