IE11 for Win7 not supported?

Today I’ve downloaded new IE11 for Win7 and got this message. Xojo doesn’t support IE11? Really?!?!

You must be using an older version of Xojo. They fixed this in 2013R3. The problem was that Microsoft decided to change the format of their User Agent string in IE11.

ok thx, Then I will recompile it…

If you’re using an older version of Xojo, you can simply Return True in the Session.AllowUnsupportedBrowser and it will allow the browser to connect anyway.

Hi Tomas,

Internet explorer’s mode can be changed to emulate many versions of browsers.

In Internet Explorer, press the F12 keyboard button and change the mode to a different User Agent String.

IE can emulate the following browsers:
Internet Explorer 10
Internet Explorer 9
Internet Explorer 8
Internet Explorer 7
Internet Explorer 6
IE10 -Windows Phone 8
IE9 -Windows Phone 7
IE - Xbox One
IE - Xbox 360
Google Chrome
Mozilla Firefox
Opera
Apple Safari (iPad)
Bing Bot

I am running 2014 Release 2 and I am getting this with Internet Explorer 11? Any ideas?

See the first two posts in the thread ?

But he’s running 2014r2…

In AllowUnsupportedBrowser, check the BrowserVersion property and see what it’s reporting.

This is the Session Header that IE is reporting. If I return True from AllowUnsupportedBrowser then it works. But I don’t want to do that because then ANY browser would be allowed in as good.

So you’ll notice that it says “compatible; MSIE 7”. That means that the browser is running in Internet Explorer 7 compatibility mode. As far as the app is concerned, it’s IE7.

And IE 7 is not supported, right ?

Coincidentally I was just installing a brand new Windows pc, and after tons of updates I ended up with IE11 of course.
I tested some of my cgi Xojo testapplications and saw them alle working. But: since IE11 the KEY-EVENTS I used to enable the user to use arrows, pgup/pgdn and end/home to go through the listview, are not working in IE11. It did work in IE10 I am sure.
So I tested with Firefox (latest version) and Safari (latest version) and even Chrome (all under Win7) and that all worked fine.

I think if I am going to play with IE11 compatibility settings, I will get it working again, but this is just what I don’t want because I have to instruct users.
So I am very curious about others’ experiences. It’s clear that we have to test our WE applications on a bunch of browsers every time.

B.t.w. Safari (Mac) and Firefox (CentOS) are working fine with the key-events too.

Following a post in this forum about the arrow keys issue in IE, I have found that IE uses OnKeyDown which is absent from Xojo WE. I have a JavaScript workaround somewhere in my disk. I can look for it if you want.

It would be nice if you could share it Michel.
Users are often complaining that they cannot be very productive with WE business applications because they have to use the mouse all the time.

[quote=125863:@Joost Rongen]It would be nice if you could share it Michel.
Users are often complaining that they cannot be very productive with WE business applications because they have to use the mouse all the time.[/quote]

I digged the code.

I have attached the event to a TextField called txtcmp_code1 by placing this in the Window Shown event :

ExecuteJavaScript(" $('#"+txtcmp_code1.ControlID+"').keydown(function(e) { if (e.keyCode == 37 || e.keyCode == 38 || e.keyCode==39 || e.keyCode==40 )"+_ " { window.location.replace('#'+'kycde'+(e.keyCode));} }) ; ")

So all arrow keys entered in that TextField will change the Hashtag value, which will then be trapped by session.hashTagChanged. Here is an example of what I did :

dim key as string if left(HashTag,5) = "kycde" then key = right(HashTag,len(HashTag)-5) WebPage1.TextField1.Text = WebPage1.TextField1.Text + key + " " HashTag = "" end if

Use this in the page shown event for the entire page keydown :

ExecuteJavaScript(" $(document).keydown(function(e) { if (e.keyCode == 37 || e.keyCode == 38 || e.keyCode==39 || e.keyCode==40 )"+_ " { window.location.replace('#'+'kycde'+(e.keyCode));} }) ; ")

Today with WebSDK you can create a self-contained control that uses JavaScript and passes the values to Xojo without using the hash tag. But the initial way of getting the key value remains.

Here is a more elaborate description of key events with the diverse browsers :
http://www.quirksmode.org/js/keys.html

Keep in mind that the framework actually does handle this. It’s also important to remember that by the time you have a chance to react the key has already been pressed and there’s nothing you can do about it like you can on the desktop. Because of this (and the fact that different keys are captured by different key events), we decided to expose this as a single event.

It’s also important to mention that Michel’s solution changes the DOM and is unsupported.

I just verified again, since what I posted was created for 2014R1, but KeyPressed still does not fire for arrow keys in Internet Explorer. So from what I can see, the framework does not handle arrow keys with IE.

At the time I looked into it, a message was posted in the forum signaling the issue, and I suggested the OP to file a bug report. Unfortunately, he did not. So I just created a bug report myself :
35149 - KeyPressed does not fire for arrow keys in Internet Explorer

Sorry for the unsupported JavaScript solution using Keydown, that is the only way I found as a workaround, until the issue is fixed. From what I can figure, it is not quite Xojo’s fault, since IE exhibits the problem with keypress in JavaScript.

I mentioned WebSDK as a possible wrapper to capture the arrow keys in a supported way, but it is far more complex…