WebHtmlViewer and WebAudioPlayer non requested refresh

Hello, back to my beloved programming life, that were unconnected to because of a masters degree en digital communication.

The issue, a created a webapp, with 2 pages: wp_LIVE and wp_LIBRARY, for my radio station. The first one LIVE holds simply a container that has into HtmlViewer (or an AudioPlayer same issue). It connects to perfect with a URL and with “controls autoplay” does start playing. Great till now.

Then a click on a a top menu (another conteiner) to select the LIBRARY webpage, works fine, and the music is still playing, which is what a expect to happen.

The problem rises when a turn back to the LIVE webpage, then the object (htmlviewer or audioplayer) kind of resets its self, cuts the audio and starts after 2 to 3 seconds.

I put a flag for the ways it enter the opening event, and it does it only once. I also test the flag to avoid do reloading.

I have placed the htmlviewer on the webpage, on a different container… same thing.

For me, it is an internal issue of XOJO webapp. Can anyone have and idea of what is causing it?

regards

Further tests i took to see if the browser was the issue, both Firefox, Chrome and Edge fail in the same manner.

It sounds like the controls are being refreshed in the Shown event. You should open an issue about this.

I think the first question to ask is “how are you starting the audio” and maybe put a breakpoint on that line to see if it’s being called again. If so, you might be able to just check if the Playing or IsPlaying property is true before queuing up the next song.

In any case, for this kind of app I think the music player (for example a WebAudioPlayer) shouldn’t be inside a WebPage that could get hidden.

Instead, you could try having a single WebPage app and change the content inside a WebPagePanel, leaving the player always visible.

Example project:
Music Example.zip (728.0 KB)

3 Likes

agree, how do one do that?

i did put a break point and never gets back into the procedure, in fact is only place at the opening event, and not as Anthony suspects in the shown event. Just the idea is start audio at boot..

kind of Ricardo. Momentarly i solved it by creating a webpage (wp_liveplayer) where the audioplayer object is, and the when the main page opens, a LivePlay methode set in the is call a method in the wp_liveplayer. After that, moving from one wp to another does not affect the behavior, since the audiplayer webpage is never open or show again.

Ockward at least, but was the way out of the issue.

You can open a new ticket here.

https://tracker.xojo.com/xojoinc/xojo/-/issues/new

It’s best if you can include a sample project that reliably reproduces the issue.

1 Like