Welcome Guest Search | Active Topics | Sign In | Register

Spell Checker button doesn't seem to trigger event Options
diadem
Posted: Tuesday, November 22, 2011 12:46:34 PM
Rank: Member
Groups: Member

Joined: 11/22/2011
Posts: 12
I just had my client buy the Web control suite and I am in the process of implementing the spell checker into an existing web application.

I have two dialog spell checker scenarios, one on a page that uses a master page, and one that does not. I am developing on Windows 7 ultimate with VS 2010. Both scenarios work like they are supposed to. When transferring the application to the staging production server (Windows server 2008 R2) The page running under the master pages fails to trigger the spell checker dialog. The page that does not run with a master page works fine. These pages are passed key values in the query string. They use these values to look up values in a database then build HTML to populate a placeholder. When the spell check button is clicked it is almost like the querystring is being wiped on postback and the values normally populated are blank.

Both environments (development and staging) use IE9 as the browser
Any help is appreciated. Any ideas what to look for? As usual the client needed the functionality a week before they finally decided to pull the trigger and buy the product.
eo_support
Posted: Tuesday, November 22, 2011 1:26:57 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,194
Hi,

Thank you very much for your business. Do you mean that when the SpellChecker button is clicked, instead of opening up the SpellChecker dialog, it actually posts back the whole page (and wipe out all the query string parameters for the post back)?

Thanks!
diadem
Posted: Tuesday, November 22, 2011 4:15:35 PM
Rank: Member
Groups: Member

Joined: 11/22/2011
Posts: 12
Yes, that is essentially what it is doing. I will confirm this and test with other browsers to see if If I can isolate it to a browser problem.

If it would help I have captured the source from the page so you can see the code being generated. It is available at

http://www.bentspoonsystems.com/images/eo_spellfail_source.txt
eo_support
Posted: Tuesday, November 22, 2011 4:26:43 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,194
Hi,

This does not appear to be a browser related issue. The issue appears to have to do with how ASP.NET generates ClientIDs for controls, which are different between ASP.NET 2.0 and ASP.NET 4.0. Our early builds have problems with this thus does not work correctly on ASP.NET 4.0 under some scenarios. I believe that has been fixed in the latest build. So you may want to first check your server's ASP.NET version to see if it is indeed running ASP.NET 4.0, if that's the case, check your EO.Web.dll version and see if it is the latest build (check our download page to see the latest build number) and update to the latest build if you are not running it yet.

Thanks!
diadem
Posted: Tuesday, November 22, 2011 4:47:48 PM
Rank: Member
Groups: Member

Joined: 11/22/2011
Posts: 12
The site is definately ASP.Net 2.0

My EO.WEB.DLL version is 9.0.33.2 (from the developer download)
eo_support
Posted: Tuesday, November 22, 2011 4:56:07 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,194
Hi,

Then we do not know what it is. We will try to reproduce it here and see if we can see the problem. If we can reproduce it, then we should be able to tell you what's wrong. If we can not reproduce it, then we will need you to create a reproducing project or provide a reproducing environment for us to investigate further.

Thanks!
diadem
Posted: Tuesday, November 22, 2011 5:03:57 PM
Rank: Member
Groups: Member

Joined: 11/22/2011
Posts: 12
Thanks for the timely help!

Here is a snapshot of the source of the same page on the development machine where it is working. Notice that some info has been XXXX out for privacy issues

http://www.bentspoonsystems.com/images/eo_spellworking_source.txt
diadem
Posted: Tuesday, November 22, 2011 11:13:33 PM
Rank: Member
Groups: Member

Joined: 11/22/2011
Posts: 12
I have been able to confirm a couple of the things

1. The load events fire for the Dialog, and spell checker
2. It is not failing because I am generating a button using straight HTML and adding it to a placeholder. I thought that it may have been a timing issue. Even though it works in development, I hard coded a button on the form and link the spell checker to that. It still fails

3. The component is not wiping out the querystring. I was able to code to catch the postback and repopulate the screen values properly when the button is clicked and no dialog pops up.

4. I hardcoded the following button on the form
<INPUT TYPE=SUBMIT value='Spell Check' name='btnSC2' onclick='var spellChecker = eo_GetObject("SC1"); spellChecker.start();'>

When clicked on in the failing environment I get the following error from the spell checker
EO.Web control ‘ctl00_mainContentZone_SC1’ Error Message: One of the control (‘null’) specified by ControlToCheck is invalid

When clicked in the development environment the dialog flashes up for second and then disappears, then the page posts back.
diadem
Posted: Wednesday, November 23, 2011 12:23:13 PM
Rank: Member
Groups: Member

Joined: 11/22/2011
Posts: 12
I think I found the cause for the issues

When the browser is set to browser mode IE9 Compatability view, document mode IE7 standards , it works properly (the original code)
The hard coded button with a javascript start Just flashes the dialog and the dialog disapears

When the browser is set to browser mode IE9, document mode IE9 (default)
The dialog fails to show in the original code and the page posts back
The hard coded button with the javascript start gives the following error
EO.Web control ‘ctl00_mainContentZone_SC1’ Error Message: One of the control (‘null’) specified by ControlToCheck is invalid
eo_support
Posted: Wednesday, November 23, 2011 1:20:35 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,194
Hi,

Please try to set the SpellChecker's ControlToCheck to the full ClientID of the control you wish to check. By default, you can set it to the ID of the control inside the same naming container. However if the control is in a different naming container (for example, when the SpellChecker is in the master page and the control to be checked is in the content page), then just using ID won't be sufficient. In that case you will need to set it to the full ClientID of the control. The error message indicates that document.getElementById(id_you_passed_to_ControlToCheck) is returnning null.

Thanks!
diadem
Posted: Wednesday, November 23, 2011 1:47:01 PM
Rank: Member
Groups: Member

Joined: 11/22/2011
Posts: 12
That does eliminate the error, but does not change the behavior. The test area had a name property of "txtETR" but no ID property. Fixing that only eliminates the error from poping up. The dialog still does not show.

In IE9 default (non compatability mode) the hard coded flashes the dialog briefly then posts back,

the code generated button (original) does not invoke the dialog, the page only posts back.

These are both non asp.net (straight HTML) buttons so their IDs do not get swapped when the pages are generated. Such as ctl00_mainContentZone_textAreaID vs textAreaID
eo_support
Posted: Wednesday, November 23, 2011 2:01:20 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,194
Hi,

Can you try to isolate the problem into a small test project and send it to us? We will PM you as to where to send.

Thanks!
diadem
Posted: Wednesday, November 23, 2011 2:11:21 PM
Rank: Member
Groups: Member

Joined: 11/22/2011
Posts: 12
I will attemp to do so, but it might take a day or two.
eo_support
Posted: Wednesday, November 23, 2011 2:13:40 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,194
No problem. As soon as we have that we will look into it and get back to you as soon as possible.
diadem
Posted: Wednesday, November 23, 2011 2:28:24 PM
Rank: Member
Groups: Member

Joined: 11/22/2011
Posts: 12
I added the following to the web config to force the page into compatability mode

<system.webServer>
<httpProtocol>
<customHeaders>
<clear />
<add name="X-UA-Compatible" value="IE=EmulateIE7" />
</customHeaders>
</httpProtocol>
</system.webServer>

The following button code does work now. The dialog is invoked and works properly

<INPUT TYPE=SUBMIT value='Spell Check' name='btnSC2' onclick='var spellChecker = eo_GetObject("SC1"); spellChecker.start();'>

The original button method of just setting the SpellChecker.ControlToCheck still fails. But the good news is that the above work around allows me to get spell checking into the hands of the users for now. I will still build an error demonstration project as soon as I can.

If I have not told you yet, thank you for the great support, It makes all the difference out here in the trenches.
eo_support
Posted: Wednesday, November 23, 2011 3:10:49 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,194
You are very welcome. We do our best. Usually the difficult part is for us to reproduce the problem. It looks like you already have a working solution. If you still need us to look into it, please feel free to send us a sample project and we will be more than happy to investigate.

Thanks
diadem
Posted: Thursday, November 24, 2011 2:53:25 PM
Rank: Member
Groups: Member

Joined: 11/22/2011
Posts: 12
While building a test app I discovered the true nature of the problem I was having. When a HTML button does not have an “ID” property, only a “Name” property, the spell checker fails to find the button when in IE9 standard mode. The spell checker will also fail to find a textbox or text area if it does not have an “ID” property. When in compatibility mode (IE7) the spell checker can find the button. I assume that IE uses to the “Name” property to respond to ID requests.

I don’t consider this a bug, just an example of pilot error, i.e. copying old code. I consider this issue closed. Maybe if somebody else runs across the same issue it will save them some time. Thanks for all that helped!
eo_support
Posted: Friday, November 25, 2011 8:53:33 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,194
Excellent discovery! Thank you very much for sharing!


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.