Quin wrote: Sun Jan 21, 2024 6:21 pm
What kind of increase are we talking here? It may be completely worth it, especially because we could possibly get MP3 like discussed above.
What about the size jump in beta from 5KB to 140KB on empty .exe? library size is not much to that
Quin wrote: Sun Jan 21, 2024 6:21 pm
What kind of increase are we talking here? It may be completely worth it, especially because we could possibly get MP3 like discussed above.
What about the size jump in beta from 5KB to 140KB on empty .exe? library size is not much to that
2024-02-04: beta 5 is ready to test. It mainly brings a new DPI Aware mode for OS X (the IDE tabs on OS X shouldn't be blurry anymore on retina display, yeah !) and the usual bugs fixes. Don't hesitate to test it and we are close to the final release.
Added: DPI-Aware support for OS X
Added: GetGadgetFont(#PB_Default) support on OSX to get the system gadget font
Added: Documentation is up-to-date now for all new commands (english only)
For me, one of the best improvements for this version is the introduction of the WebViewGadget. Up to now I have been using the WebGadget and the excellent CoMate plus to automate the logging in to some websites by entering text and "pressing" buttons. This has become less effective as the WebGadget (based on Internet Explorer) fails to show some websites correctly. The WebGadget with the #PB_Web_Edge flag does show them correctly but then Comate Plus can't be used.
The WebViewGadget has the ability to execute javascript (with WebViewExecuteScript()) and I thought this would solve the problem of automatic logging-in but this gadget does not have the events associated with the WebGadget such as #PB_EventType_DownloadEnd. You can't run a script until the page is loaded, and building in a timed delay is not satisfactory.
I therefore urge the team either to expose the WebViewGadget to the same events as the WebGadget or to allow the WebGadget to execute scripts.
CalamityJames wrote: Wed Feb 07, 2024 11:20 am
I therefore urge the team either to expose the WebViewGadget to the same events as the WebGadget or to allow the WebGadget to execute scripts.
The problem being in general - great new browsers support, but without more complete interface we will all go back to the same "tricks" for each OS and lots of (possibly buggy) includes.
Fred said he will think about it, which is a very good thing.
Added: #PB_WebView_ICoreController attribute support WebGaget() and WebViewGadget()
Added: All ICoreWebView2 interfaces and constants as residents, thanks to Justin (Windows)
Added: #PB_WebView_ICoreController attribute support WebGaget() and WebViewGadget()
Added: All ICoreWebView2 interfaces and constants as residents, thanks to Justin (Windows)