Buffered touches?

[ukimiku]

In a sub that is running for a long time, I call DoEvents. During one of these events, the user can click on an imageview (iv), and the iv_Click routine branches to another sub that presents the user with a InputDialog (nd), asking for a number. I then want to display this number on the screen.

Yet it seems that the result of

nd.InputType = nd.INPUT_TYPE_NUMBERS
nd.PasswordMode = False
nd.Input = ""
result = nd.Show(nmessage, ntitle, npositive, "", "", Null)

then is always -3 (abort), as log messages show.

When I click iv while the long-running sub is not active, I can enter new numbers without problems.

I have the vague idea that touching the imageview iv might fire not only one click event, but more than one, which then would be outside the InputDialog. But the InputDialog does not disappear, so I can't really account logically for this behavior. Should touches be buffered (as I recall reading in another forum message by someone who had gestures buffered while drawing something), is there a way to clear the buffer?

Anyhow, I feel that this is not quite right a notion of what is going on.

Have you encountered similar problems? Found solutions?

Thank you.

Regards,

 

[Erel]

Click events are not buffered.

What do you mean with a long-running sub? You cannot hold the main thread in an endless loop. You should instead use a timer.

 

[ukimiku]

Then this behavior may be due to my using the sub to carry out long calculations. By long I mean a range from maybe 3 seconds to several minutes. But the system is given time for event processing by calling DoEvents. My user experience of the App is that it, and the Android system as well, stay quite responsive, as I call DoEvents quite frequently.

As you recommend using a timer, I will give this a try though my suspicion is that it will down performance considerably. Since even for a pretty ordinary task a couple millions of calculations may be needed, a timer would need to do many calculations in every tick to achieve a comparable performance, which in turn may make the App and the system appear unresponsive without calls to DoEvents. Anyway, I'll try out doing this particular calculation timer-based.

Thanks for the input.

Regards,


P.S. Click events are not buffered. But touch events are? I think I know now where to look in the code...

 

[Erel]

Touch events are buffered. Which calculations are you doing that take several minutes?

 

[ukimiku]

The calculations are necessary for the simulation of a very simple virtual computing device with instructions to be executed, program counter, input, output, precompiling jump tables etc. If I run these calculations in a timer, the whole thing tends to get very slow. At present, the phone manages roughly 20000 code state transitions per second (hogging one core for that time), and for some tasks, several million state transitions must be processed.

As soon as I find out how to launch a precompiled native Android .exe file with parameters, I can delegate most of the time-consuming processes to that .exe and keep the App even more responsive. But then stopping the process would be more difficult, and keeping track of the exact state of the machine (for a later, possible, resuming of the run). Let alone communicating intermediate state results from the simulated computing device to my App. So far, I think of using the Shell to deploy a launch command to the native .exe, but as of now, know almost nothing about the possibilities of the shell, security restrictions that may apply, etc. Heck, I even don't know how to embed/deploy a precompiled native .exe from within my App to my local data folder and run it there. Do you?

Regards,

 

[Erel]

Android doesn't run "Exe" applications. Only APK apps.

 

[ukimiku]

Thanks for responding. On my phone, I sometimes program using the Pépé compiler. It produces native ARM files the filenames of which end in ".exe". They are executables, so I ha thought .exe files were possible executable files on Android. Maybe they are being executed by some software layer lower than Android? Well, anyhow, later I will have a look at the NDK for native code objects; for some tasks, Java is just too slow.

Regards,