Hi All - I’m looking to see if anyone else has ideas of how to solve my situation, which I had /hoped/ to be cured by the recent implementation of webKit3, but to no avail. I know of at least three people on here who have voiced similar issues, but I don’t know whether they have managed workarounds.
Problem: My major application, currently being sold through at least 20 education authorities in the UK and more soon in Europe is still stuck on 2016r4 because of a problem that seems to have been introduced in 2017r1 and never cured. I can’t update as neither Webkit nor Native mode in HTMLViewer is doing their job (different issues). A feedback was raised for the former and confirmed quite a while ago, but it has not been cured.
Situation: The bulk of the application is a standard Form based management system, but it has a web-page based interrogation system pre-login that unskilled users can use to interrogate the database. All results need to be generated dynamically from SQLite / Cube databases, based upon a ‘theme’ folder which contains both language and images. All resulting pages are therefore local, with links detected and acted upon by the HTMLViewer events, and links to images etc. on the local machine.
Native: Despite all versions of Edge, IE, Chrome etc. rendering properly, the HTMLViewer implementation of DIV’s (possibly more, but DIVs are the killer) using absolute positioning etc. does not work. Instead of multiple blocks across the page (e.g. inline-blocks), ‘Native’ displays them beneath each other as if inline-blocks are not being supported. Bit off as this is meant to be ‘native’ and yet the ‘native’ browsers do not have any problem with it, but I’ve not pushed this one as Native is not my preferred choice in any case and I’d rather avoid it - if for no other reason that we sell Win, Mac and Linux versions of the product and I’d much prefer to have them all running Webkit as a standard choice (Mac and Linux BTW, have never given us problems - it’s always been the Win implementation).
Webkit: Does not honour local file paths (v2017r1 onwards, 2016r4 has no issue). This is the big one. This was reported last year as a feedback, confirmed by Xojo, but never fixed. With the implementation of Webkit3 in 2018r2, I’d hoped that this would be resolved, but in fact it is now worse - a complicated workaround at the time of copying all files (dynamics, images etc.) into temporary locations from the normal configuration every time they were built then loading from the temporary directory, no longer works /at all/. Doing a lot of non-xojo research there does seem to be random adherence to allowing access to local files in Webkit (TBH, this does not sound like the original feedback case I reported, but it certainly sounds like it now). I’ve found issues reported across the board, including C++, C# and VB, with some indicating that there is a webkit flag allowing access to local files that needs to be turned on (it can be turned on as a command-line switch for example, when starting Chrome), but it sounds like a build-flag that Xojo have decided to not utilise. The feedback case was not updated, either way.
I’m now at the point of deciding that post 2017r1, HTMLViewer is a totally useless control other than doing bog-standard display of web-server based webpages. I’m faced with recoding a massive swathe of the application to provide a custom interface rather than a very simple web-page solution that clients are familiar with through everyday use of browser - we are now nearly two years behind current Xojo release, and I can’t let this go any longer.
Naturally, I’d rather not have to redesign and recode. Has anyone been able to work around this problem?
Note: Before people start to suggest switching to a local webserver, internet server etc. as a solution, please don’t. This application is utilised by clients in locked down environments (where it is impossible for them to support local webserver implementations), or in locations where reliable internet access is not a guarantee. This solution /must/ be inherent to the application, and totally local.