PB 6.1 Beta 4 - QT and Function Return support in WEBViewGadget?

[pamen]

Hi
PB 6.1 Beta 4

1 - Is Qt fully supported by WEBViewGadget? New help file states GTK, GTK has much poorer browser than Qt...

2 - ExecuteJavascript in WebViewGadget - I see a callback for function with parameters, but not Javascript function return value.
Silly question: I need to call a JS funciton with no parameters but return a string (or integer or what not) - how can this be done in WebView?
I have plenty of code for each browser / OS to do that, it would be lovely to get rid of all those OS dependant 1000 line blocks.

3 - How do I intercept Navigate callback in WebViewGadget???? This is essential to be able to use ready html with email or htpps links.

[Fred]

1 - QT is not supported yet. Why GTK browser is poorer, It's WebKit based IIRC ?

2 - I don't think you can yet

3 - Same, it's not support.

The WebViewGadget() is intended for UI management, so reacting to user input should be enough as it shouldn't have any logic in the UI code. What's your use case for execuing a JS proc and getting back the result ?

[pamen]

Dear Fred
Thank you.

Qt renders pages fine (or emails in my case), which in GTK WebView 2/3 just show "errors in HTML".

Calling Java and getting function results is essential if you want to:
- WEB based editors (and not reinvent them for the next 6 months)
- Pages, which contain dynamic JS from different sources, for example server supplied variations with business logic , depending on retrieved data
- Reacting to changes of DOM caused by any script or even CSS
- The idea, the UI should have no logic is correct, but there is a LOT of logic in the UI, which should be traced, for example state of buttons, change of text selection, current focus, text in edit area etc. etc.

If WebGadget had in 6.1 JS function support for calling and returning results (I'm "hacking: it now with each OS, Browser and platform differently), WebView would not be needed as the same can be then achieved by WEBgadget,
BUT if WebGadget is considered legacy and display only (I could understand that) - WebView should allow it and consolidate functionality in one place, including Navigation events and JS calling 2-ways.

Otherwise we rewind back despite WebView2 having all of that - for each platform get Forum code, fix it, tweak it and have the above, instead of unified, beautiful, PureBasic approach.

That is just my opinion, so please take it with a smile.

Edit 1 - knowing that the page is fully loaded is also needed for interaction with the HTML/CSS/JS page. So Browser events like PageComplete or Navigate are even needed in an application
Edit 2 - if the text contains for example fred@domain.com - navigation event is needed to intercept the click, no matter if it is in a sub-sub frame or the outer most HTML.
Edit 3 - If one wants to use any WEB based modules with years of development, like CK4 / CK5 - one needs JS script result, at least as a string.

Sources for JS with result:
Linux (WEBKIT) https://www.purebasic.fr/english/viewtopic.php?t=78274 (WEBKIT)
MacOS: CocoaMessage(0, GadgetID(0, "stringByEvaluatingJavaScriptFromString:$", @URL1$)
WindowsIE 11: search for result = Script\Invoke(dispID, ?IID_NULL, 0, #DISPATCH_METHOD, @params, @varResult.VARIANT, 0, 0)
Qt: pieces are here: https://www.purebasic.fr/english/viewtopic.php?t=81386

[Fred]

Thanks for the additional info, I will see what can be done

[ChrisR]

I fully agree, ExecuteScript (JS) seems essential to control an interface, to Set, Get, Text, State, Color, Item... and be able to interact as it is done for native gadgets.

[Seymour Clufley]

+1

[Quin]

+1

[mk-soft]

WebViewExecuteScript(#Gadget, JavaScript$) cannot return a result directly, as the script is executed as a sub thread of WebKit. A callback for the result would therefore have to be passed. This is hooked into the MainScrope of Caller (Place of WaitWindowEvent). A run of WaitWindowEvent is required to get the result.

WebViewExecuteScript(#Gadget, JavaScript$[, ResultCallback])

It took me a while to understand where the Webkit callbacks are hooked in. This means that no threadsafe is required as the data transfer takes place in the MainScope.

Like WebGadget Extensions

[pamen]

Correct mk-soft,
in all browsers the result of the JS must be in a callback. This is clear.
It is not possible and also makes no sense to have it differently.
Hosting application can do the polling and blocking until result or error comes back via callback.

So - the same as already implemented in PB 6.1 for other functions - call browser, then callback.

[pamen]

Additional Info Win7 64/32 with WebView installed:

Webgadget (WebView2) on Windows 7 seems to become IE, scrollbars are square and white.
WebViewGadget on the Same installation of Windows 7 + WebView2 works correctly (but as it does not have Navigate Callback, so it is not usable as secure viewer)