We're using your IgniteUI controls (V16.1) within an MVC project.
There are three developers on the project - 1 developer using Windows 7 (64-bit) and the other 2 developers using Windows 10 (64-bit). We're all using Chrome (V61.0.3163.100).
To load the required IgniteUI resources we're using the igLoader (using the MVC helper). This renders the following: //
We're successfully using the igGrid controls within our views.
The problem comes with the editor controls (we've tried the TextEditor and DatePicker). Using exactly the same code, the controls render correctly on the Windows 7 PC, but throw the following client error on the Windows 10 PC's:"igEditor is not a function" (in infragisics.loader.js)
The controls are rendered using the MVC helpers as follows:
@(Html.Infragistics().TextEditor().ID("tb").Render())@(Html.Infragistics().DatePicker().ID("dp").Render())
Do you have any suggestions how to fix this?
Regards, Dave
The rendered igLoader code was stripped out of my original post. Here it is:
$.ig.loader({ scriptPath: '/Scripts/Ig', cssPath: '/Content/Ig', theme: '' });
Hello dogle,
Thank you for posting in our community!
It seems the required js resources for the editors are missing from the Path’s specified by the igLoader. As you are using a different location for these resources in your project than the default one ($.ig.loader({ scriptPath: '/Infragistics/js/', cssPath: '/Infragistics/css/', .. });), it is very likely some of the resources are not copied correctly, AND/OR for the machine they are working ok , it is possible there is an additional reference to the resources or they are simply existing in the Paths specified.
I suggest you to double-check if there are missing resources from the browser’s network tab and as well as from the specified paths in your project.
More Info: The stand alone js file the editors depend on is infragistics.ui.editors.js and usually under \src\js\modules.
The other dependencies for each one of the editors can be found in the API and for the igTextEditor as example can be found here .
Related: https://www.igniteui.com/help/using-infragistics-loader
Hello Ivaylo,
Thanks for your suggestions.
We've double-checked and all the required js resources exist on the erroring Windows 10 PC's. We even copied all the resources over from the working Windows 7 PC to be sure.
We've checked the network tab in Chrome's dev tools - I've posted a couple of screenshots showing the "infragistics.ui.editors.js" file is loaded, along with the client error.
Curiously, on the Windows 10 PC's the igGrid controls display correctly. This error only occurs with the igEditor controls.
In addition, the website has been deployed to a Windows Server 2008 R2 box - when viewing the deployed website, the Windows 10 PC's can see the igEditor controls correctly, without error.
Hello dogle,Thank you for the details! It seems rather strange to have such difference in behaviors. Based on the exception, I suggest you may be using a mixed source of IgniteUI 16.1 with a previous version where there was a common base igEditor widget for the editors. With the 15.2 release of Ignite UI™ a new set of editor controls were introduced. There is a detailed documentation topic regarding migrating each of the editors. If this is the case with you, you may refer to the following forum topic for more details:https://ko.infragistics.com/community/forums/f/ignite-ui-for-javascript/106582/igeditor-is-missing-from-v15-2-and-v16-1---where-is-it
I can’t think of any other reason what can be causing the exception at this time. Without more details and debug information anyway.
PS: You can check the version of the IgniteUI files you are using, checking the first couple of lines in the corresponding js file. For example, for the "infragistics.ui.editors.js" file it can be something like: /*!@licenseInfragistics.Web.ClientUI Editors 16.1.20161.2270.
We've got to the bottom of the problem Ivaylo...
The project reference to "Infragistics.Web.Mvc.dll" defaulted to "Specific Version" = false. On the Windows 10 PC's it was picking up an older version of the dll.
We've resolved all PC's to use the 2016.1 dll and everything is now working as expected.
Thanks for your help with this issue.
Regards,
Dave
We've checked and the files are all V16.1.20161.1009.
What additional debug information would you require?