WebView hyperlink will not work during DoEvents

[nfordbscndrd]

I have a large application in which I cannot get WebView to display when the app is in a Do-Loop with DoEvents in it. The WebView is used to display the app's Help file, so the file is loaded at the start of the app and all the Help button does is supposed to do is make the WebView visible, but it will not become visible.

To try to isolate the problem, I created a test app (attached) with a Webview and three buttons:

"Help/X" to show and hide WebView
"Back" to go back after a hyperlink has been clicked.
"Loop/Exit Loop" to put the app into/out of a Do-Loop with DoEvents.

Unlike the main program, in the test program when I exit WebView, activate the Do-Loop, and start up WebView again, it displays okay, but if I click on a hyperlink, it will highlight the link, but it will not go to the destination until after I click on Exit Loop to get out of the DoEvents loop, then it will jump to the hyperlink destination.

So while I didn't duplicate the original problem, there is still a problem. The routine in the main program is equally simple (change the text on the Help/X button and display/hide WebView), but it simply will not display it.

If I remove DoEvents from the loop, none of the buttons or the WebView can be accessed, of course, so DoEvents is working as far as allowing processing of button clicks, etc., but it will not allow processing the hyperlink clicks.

Attached is the test app, including an HTML file to display. Is this a bug, or am I just doing something wrong, or is this just a limitation of DoEvents-WebView?

 

[Erel]

You should use a Timer instead of a loop with DoEvents. Calling DoEvents in a loop consumes a lot of resources and it doesn't allow the system to process all waiting messages properly.

 

[nfordbscndrd]

You should use a Timer instead of a loop with DoEvents. Calling DoEvents in a loop consumes a lot of resources and it doesn't allow the system to process all waiting messages properly.

Hmm. I thought that allowing the system to process waiting messages was the whole point of DoEvents?

In this situation, a timer is not really a substitute for a loop with DoEvents. This is a card game in which the opening bid and play changes with each deal, so the turn of the human player changes each time. I have a routine like this:

For i = 0 to 3
    If Turn(i) = 0 Then ' human
        waiting = True
        ' Wait for the human to play and click Okay, which sets waiting=False:
        Do While waiting
            DoEvents
        Loop
    Else
        ' computer bids or plays.
    End If
Next

When it's the human's turn to play, he may click the Help button which tries to bring up the WebView to display the docs, which isn't working. I can program around this, but the code will not be as simple or as easy to follow, but it appears I don't have any choice.

Thanks for the info.

 

[agraham]

Do While waiting
    DoEvents
Loop

Looping is bad practice on mobile devices. The CPU will be constantly executing code and using battery power unnecessarily as the code will never get back to the OS idle loop where the hardware power saving measures are invoked.

 

[nfordbscndrd]

I see. Well, that's good to know. Thanks.

 

[Erel]

As a side note, DoEvents is not a native method. Android API doesn't expose such a feature.
As there are places when calling DoEvents is very convenient (for example if you want to update a ProgressDialog while doing some long calculation) I decided to implement it. Calling DoEvents is not a full replacement for letting the main thread handle the message queue.

 

[nfordbscndrd]

Looping is bad practice on mobile devices. The CPU will be constantly executing code and using battery power unnecessarily as the code will never get back to the OS idle loop where the hardware power saving measures are invoked.

On a related note, the music player on my device offers two screens. One is just a picture of the album cover and the name of the song playing. The next shows all the controls, as well as a progress bar with the seconds played on one end and seconds remaining at the other end. Are these things causing enough of the type of battery drain you mentioned to make it worth staying on the other screen?

 

[agraham]

Anything that changes on the screen uses CPU cycles and power and the screen illumination also uses a large percentage of the power consumed. However if a screen is being updated in the region of once per second then the additional power consumption is probably small, actually playing the music is probably using more power. Dimming the screen while the display is not needed while playing is the best way of saving power.