Switching technology services

I have now had the help from Lansa support for a very specific problem. We have a number of solutions, some of which use the XHTML technology service, some the PPC_XHTML technology service.

None of these solutions use more than one technology service.

PPC_XHTML is no longer supported by Lansa so when we upgraded to v.14 this presented a problem. Support found a way to make it work and we continued, making only minor adjustments to the code.

Now we have been upgraded to v.14.1 and something broke in the process.

It can still be made to work but we can only have either XHTML or PPC_XHTML working at the same time. Due to a deadline we will live with that for a short time and then we will start the migration of the PPC_XHTML solutions.

The work-around is this:

Getting XHTML to work: Use Tools -> Import to import the v.14.1. weblets. Done.

Getting PPC_XHTML to work: Use Tools -> Import to import the old v.12 weblets. Check out the specific design weblets made for our solution. Check out the WAM that we need to work with. Done.

So, not bad but not optimal either. That is of course the problem using a technology that is no longer supported.

Advertisements

Old application and new(-ish) browser

Back in a web application built using Visual Lansa v. 12.5 and using the technology service PPC_XHTML, I got the task of getting it to work on a new unit. It was – unsurprisingly – a PDA application and the new “PDA” would be a modern, fast and capable android unit.

The application was built for an Internet Explorer for the handheld units and on an Android it is logical to look at Chrome.

To my surprise very little had to be done to get it to look nice. CSS media queries and a tiny bit at that and I was practically done.

However, one of the WAMs had an auto-submit when the user made a change to the selection in a radio and in Chrome 54 for Android, that resulted in a request with the old value being sent. The radio button was updated but as the request contained the old value, the response was “wrong”. The problem was that the request body was being constructed, on the click event, before the radio button change had taken effect.

The fix was rather simple – I inserted a bit of javascript using jQuery:

$("input#RADIOBUTTON1").mousedown(function() {
   $("input[name=RADIOGROUP]").val($(this).val());
});
$("input#RADIOBUTTON2").mousedown(function() {
   $("input[name=RADIOGROUP]").val($(this).val());
});

This way, as the mousedown event fires before the click event (remember, a click event is combination of a mousedown and a mouseup on the same element), the radio button was updated before the request body was constructed.

Unfortunately the final unit turns out to run a browser built on Chromium 52. And there is a bit difference for the web application.

I have not solved it yet – we might be able to get the units with a newer browser – but I needed to test it on my own machine. And getting an old Chrome/Chromium does take some steps.

First of all, you can’t really get an old Chrome. But Chromium should be good enough.

I found the guide on the Chromium website but I will repeat it here, just it case:

And then I could confirm that the issue exists in Chromium 52. Now I could just find the cause in the change logs.

Update: I think I managed to “fix” my problem. The browser was built using the system component WebView on Android. WebView, which uses Chromium and will be using Chrome on Android 7, can be updated using the Google Play Store and after doing that, it now runs on Chromium 55 and our web application works as intended.