Fckeditor For Asp.net 3.5
Contents. Integration step by step Step 1 Suppose that the editor is installed in the /fckeditor/ path of your web site. The first thing to do is to include the 'ASP Integration Module' file in the top of your page, just like this:
I can't get FCKeditor to work on an Ajax-enabled page in ASP.NET 3.5. Integrating FCKeditor in ASP.Net Websites. You can find the dll file in location FCKeditor.Net_2.6.3 bin Release for both 2.0 and 1.1 version of ASP.Net.
Sample Code The complete sample - find the full sample in your Samples directory.
We are migrating CKEditor issue tracking to. Please, use GitHub to report any new issues. The former tracking system (this website) will still be available in the read-only mode. All issues reported in the past will still be available publicly and can be referenced. Important: we decided not to transfer all the tickets to GitHub, as many of them are not reproducible anymore or simply no longer requested by the community. If the issue you are interested in, can be still reproduced in the latest version of CKEditor, feel free to report it again on GitHub. At the same time please note that issues reported on this website are still taken into consideration when picking up candidates for next milestones.
To report a new issue, go to and follow the instructions in the issue template. Options futures and other derivatives john c hull ebook. Hi, I'm made a basic asp.net 2.0 Form with a FormView to edit a simple 'text'. My formview works with a FckEditor or a TextBox editor in it. If I surround the formview with an UpdatePanel, Then It doesn't works anymore. The Text Inside the FckEditor is not recorded into the database.
Neither when using insert nor update method. If I replace the FckEditor by a TextBox, then it works well again. Does FckEditore don't support Microsoft Asp.net AJAX, or UpdatePanels, or I have to do something to the FckEditor to support it?
Thanks for helping me. ( 23.5 KB) - added by Pete Hurst. FCKeditor.Net AJAX test ( 17.8 KB) - added by Pete Hurst. FCKeditor.Net AJAX extension v1.0.2 ( 2.4 KB) - added by Pete Hurst. Patch against FCKeditor trunk adding PreventSubmitHandler ( 80.2 KB) - added by Pete Hurst.
AJAX control implementation utilising PreventSubmitHandler to fix ( 2.0 KB) - added by Frederico Caldeira Knabben. ( 1.4 KB) - added by Frederico Caldeira Knabben. Part 1 of 2: Targeted to the FCKeditor trunk ( 3.1 KB) - added by Frederico Caldeira Knabben. Part 2 of 2: Targeted to the FCKeditor.Net trunk ( 1.4 KB) - added by Frederico Caldeira Knabben. Part 1 of 2: Targeted to the FCKeditor trunk ( 3.1 KB) - added by Frederico Caldeira Knabben.
Part 2 of 2: Targeted to the FCKeditor.Net trunk ( 4.3 KB) - added by Juraj Skripsky. Patch implementing the above mentioned optimizations Download all attachments as. Replying to: Do you think you can provide a test case for it.
Something like a VS project with a page that shows the problem. It would help us a lot to reproduce it here, making it possible to fix it quicker. I'm not the original poster, but I'm encountering the exact same problem. An example would be pretty large. In short, I have a GridView and a FormView.
The FormView has an FCKeditor in it. The editor gets its value from a database using Value='<%# Bind('ItemText')%'. When I don't wrap the FormView in an UpdatePanel, it works (user changes in the FCKeditor get saved to the database). When I wrap the FormView in an UpdatePanel, the changes 'don't stick.' See attached, I've inherited the original FCKeditor class and implemented IScriptControl. This ensures a client-side behaviour is attached which does nothing except to serve as a component placeholder which my WebFormOnSubmit function can search for. This OnSubmit function is registered in an OnLoad override in the control, using ClientScript.RegisterOnSubmitStatement.
The Javascript OnSubmit routine should only be executed once per postback (but only if the FCK is.inside. an UpdatePanel.), and will iterate through all AJAX components to see if any are of type FCKeditorAjax, in which case it will fire the component's onSubmit, which calls FCK's UpdateLinkedField method. I've tested this with a single instance of FCK, but theoretically it should work with any number of them.
As I mentioned in, this could be integrated with the original project but since it requires a reference to the AJAX libraries this could break existing applications. It could however be included in an alternate project/solution file. Usage:. Reference assembly in web.config:. Use on page with Please let me know if this works for you! Anksunamon: Please try my patched version. It will produce JS errors but should work.
(Unless this is a new problem in FF 2.0.0.12). Let me know if there are any unexpected problems.
ClearCarbon: No, I still haven't had time to look into the errors; however as stated above the editor will work anyway. The JS errors only start appearing if the FCK is removed from the page (during an AJAX refresh). The page will continue to work even with the errors. They are along the lines of ' does not exist'. I think some part of the FCK API is still trying to access the editor in the DOM after it has been removed. I'll check later on and post the full error message, in case anyone on the FCK team has an easy answer. (I need to know more about how to purge FCK from browser memory.) Alternately, a fix could be made in the FCK core.
Whichever line of code is producing the error, needs to first check whether the object it's looking for still exists. If it doesn't, it should stop trying!;). Attached ASP.NET website contains 4 test pages:. FCKEditor.Net.
FCKEditor.Net inside an UpdatePanel. FCKEditor.Net (AJAX fix) inside an UpdatePanel. FCKEditor.Net (AJAX fix).without.
UpdatePanel We are most interested in (demonstrates bug ) and (showing my fix as submitted, and the further Javascript errors). Instructions: open one of the tests, change some text, click 'Post'. The text received by server will be displayed underneath the editor.
The tests have clarified a couple of points;. To reproduce, just the UpdatePanel and FCKeditor are required; the FormView and GridView mentioned in the initial report are not related to the bug. The bug causes any editing done in the FCK to be lost; the initial value of FCKEditor.Value is always be posted back unchange. When using my patched version, everything is fine on the first postback. After the second postback, Javascript errors start appearing: FCK is not defined, fckeditorcodegecko.js line 31 (from Firebug console). I test in IE7, and discovered the fixed version worked absolutely fine with no errors. I then ran test and discovered IT worked in IE7.
So the bug could be just related to Firefox. Will test in more browsers!
Other notes:. Test currently fails. This is because I shortsightedly threw an exception in the FCKeditorAjax component when no ScriptManager is available. Fix will follow shortly. Further notes from stepping through script execution with Firebug. I think the error begins with AttachFormSubmitToAPI in fckeditorapi.js. It attaches an event listener to the parent form's 'submit' event.
This seems to be getting fired after each AJAX postback, after the editor has been removed from the DOM By this time the editor must have been deleted from the DOM, and the FCK object doesn't exist, causing the errors. It all seems like MS and/or Firefox being a bit backward but that's what it looks like is happening. I'm experimenting with adding a DetachFormSubmitFromAPI function in fckeditorapi.js itself and finding some way to fire it on the AJAX component's dispose event (or similar). Additionally I noted that in fckeditorapi.js you add an event listener on 'beforeunload' as well as 'unload'. However in this situation at least, the 'beforeunload' event doesn't get fired, just 'unload'; so the window.FCKUnloadFlag doesn't get set and the FCKeditorAPICleanup function does nothing.
I'm not even sure what the purpose of FCKeditorAPIConfirmCleanup is. But perhaps I could add a call to DetachFormSubmitFromAPI into that Cleanup function? I think this would be a reasonable cleanup operation whatever the circumstance.
With regards resolving this bug (pending ), I suggest I create two additional project files within the FCKeditor.NET solution:. FredCK.FCKeditorV2.vs2005ajax.csproj This will be compatible with.NET 2 / AJAX. This can't be built into the vanilla vs2005 project, since the AJAX dependencies (mainly on ScriptManager) may not always be available. I could either add the additional code directly into the FCKeditor component, and use #if directives to disable the code in other builds; or I could inlude the AJAX-compatible version as a second control, named FCKeditorAjax. I favour the first approach since then existing sites could be fixed just by swapping in the new.dll.
The second approach would require additional work renaming any existing occurrences of the component. FredCK.FCKeditorV2.vs2008.csproj This will be a native VS2008 (targetting.NET 3.5) version of the project. Since 3.5 has AJAX bundled as standard, we can safely use only the AJAX-compatible component here.
Since there are already vs2003 and vs2005 versions of the project, it makes sense to include a 2008 version in any case. There is a third possible approach using reflection to determine at run-time whether the ScriptManager class is available and if so use it - then no additional vs2005ajax project would be required at all; however this idea is untested in these circumstances. This solution would also be less optimal due to additional processing costs involved in reflection, although this hit should be minor.
Any thoughts or preferences as to which approach should be taken? I believe I've found a fix. By creating a DetachFormSubmit function in fckeditorapi.js, and adding a call to it in the Cleanup function, I thought I would have solved it. However there was an additional problem: the Cleanup routine wasn't getting called, because the 'beforeunload' event wasn't getting fired. I'm not sure if this is due to the way ASP.NET handles destruction of iframes, or a general symptom of dynamically removing iframes in Firefox. Additionally, the ParentForm object didn't seem to be available at the time of unload, so it wasn't possible to detach the events then. Either way, I attached an additional Cleanup function to the FCK object itself, which calls the normal onbeforeunload and onunload functions.
This Cleanup function can be called manually before dynamically removing an editor, to ensure it is disposed correctly. I can't yet confirm whether this fixes the general scenario of, although it seems it should. The onbeforeunload event handler merely sets a flag, which the onunload won't do anything without. This is apparently needed only to fix, and was added in rev. 546 (by martinkou).
This is to prevent an issue when running inside a WebBrowser control. I wonder if there's another way to fix that issue, rather than requiring an extra call to a Cleanup function, to work around this side effect of it? I'll upload a patch against trunk as soon as I've tested further against. Replying to: Ah, it needs a reference to the original FCKeditor.Net component. The supplied project just contains a class that extends the base class.
If you want you can remove that faulty reference and instead reference the V2.dll, alternatively get the FCKeditor.Net source and reference it in a solution, as I had it (hence the broken project file!). Unfortunately you'll still need a fix for in Firefox - I'll supply a fix for that tomorrow, as well as your issue fixed. It's really time I got onto resolving this finally.
Finally, I have the editor working perfectly inside an UpdatePanel! I had to add a configuration option in fckconfig.js, which prevents the submit handler from being attached altogether. In FCKeditorAjax I test ScriptManager.SupportsPartialRendering and if true I set the option. Finally, I use ASP.NET's hooks to wire up my own submit event, as previously described. I think this is the best solution since FCK's juggling of the submit event just seems to conflict with the AJAX framework and its own event handling. I think a 'DisableSubmit' option is a good remedy for any situation like this. It's very easy to add our own submit event to call UpdateLinkedField, but it's very difficult to detach FCK's submit once it's been attached.
Unfortunately this won't fix which is itself caused by the dodgy event wiring I am now bypassing! Can I get some feedback as to the best name for this setting?
Something more descriptive like 'PreventAttachSubmitEvent' or possibly instead have an 'AttachSubmitHandler' option set to true by default? I'll upload my current patch later today, I promise this time! Patch and a new version of the control attached. FCKeditor.Ajax.rar is now out of date and needs deleting! The new file (v0.9) should be used. I haven't updated the tests yet either.
Thought I'd just get the files out rather than keep saying I'm going to and not doing;) Also apologies for confusing version numbers and bad file names;) I seem to have regressed from 1.0.2 to 0.9. Should finally note I haven't implemented the additional change suggested by rafaelneri. I was going to try to fix this by moving the RegisterOnSubmitStatement into the Render method, but haven't had time to test this. So in its current state, this control may cause errors if used inside a MultiView. I can think of a test case which could break that method: You have a page with two update panels.
One panel contains an fckeditor and a submit button. The other contains something else, for our test purposes just a submit button. If the second panel gets updated, the fckeditor will remain as it is in the DOM - and none of the fckeditor code will runs when the postback is completed, so onSubmitStatements.push will not get called.
ASP.NET will throw away the old onSubmitStatements (I'm fairly sure they'll get trashed and re-created with each postback). So now there is no submit handler to call UpdateLinkedField the.next. time a postback happens.
I'll put this test case together and add it to the others, in case I'm not describing it clearly. I'm not definitely sure it'll fail but I suspect it will. I'll also update the tests to a patched FCK so we can see that working. Replying to: I've attached a patch that uses the pure JavaScript approach to solve this problem. It seems to work well in all different cases. It was tested with.Net 2.0 only.
It should work with the 3.5 also. Test results are welcome. Hi there, I am experiencing this problem in my application (.Net 2) in Firefox so I tried applying your patch, but it didn't seem to fix it. I then tried applying it to serializer's 'Test 2' in case it was something else wierd about my page, but again it didn't work. All I did was copy lines 150 to 186 in the patch file to the AttachFormSubmitToAPI function in fckeditorapi.js. I tried putting an alert in the function just to check it was being called, but it didn't get displayed so i'm not sure if it is being called at all! Is there something else that needs to be done to get it working?
Craig, You need to add?fcksource=true onto your URL. This will mean your modified files in source will be used, instead of the packaged fckeditorcodegecko.js and fckeditorcodeie.js, which are distributed with the editor. Once you've finished testing, you can then use 'fckpackager' to compile the files yourself, then?fcksource=true is no longer needed. The query string is checked by the FCKeditor.Net assembly, and if it finds fcksource=true then it uses 'fckeditor.original.html' instead of 'fckeditor.html'. This version references the original source files instead of the packaged ones. Replying to: Which one worked for you?
The or serializer's solution? It was 234.patch that I was referring to above. I tried serializer's solution first and it didn't seem to work, but I guess this was for the same reason that 234.patch didn't work for me initially.
234.patch seems more elegant than serializer's solution, with less set up involved. However, if this was part of an official release I guess this wouldn't be an issue, so it's really down to which solution gives the correct behaviour under all conditions. FredCK's patch is better in that it doesn't require an extra.js include - which my AJAX solution does. However in terms of architecture, it's bringing ASP.NET-specific code into the fckeditor core, breaking the usual separation of the server-specific implementions as separate components from the core editor.
Another concern is that the onSubmitStatements object is an internal feature of PageRequestManager which.could. be subject to change in future releases, since it's not publicly specified or documented. (Unlikely I admit, but a potential gotcha.) Another problem would be if a different Javascript framework decided to name something Sys.WebForms.PageRequestManager. Again very unlikely but would cause unexpected problems!
A further problem I'm not sure about, is what would happen if the fckeditorapi code ran.before. the PageRequestManager had loaded? Personally I don't know enough about the Javascript pipeline in different browsers to know how possible this is. Basically, are scripts.guaranteed. to be executed in the order that they are referenced in the page, or are they just executed as soon as they're downloaded? The other test case I outlined (comment 35) could be easily worked around by using the endRequest event of the PRM, there re-attaching our onsubmit event in case it has been deleted during the async operation. This might not even be necessary, I should have some time tomorrow to test this.
Here's the official PageRequestManager reference: It's pretty annoying that there's no publicly-exposed way to attach a submit event. 'beginRequest' and 'initializeRequest' only seem to be triggered for async postback, but we need something that will be triggered for ordinary (synchronous) postbacks as well.
So the only way officially endorsed is via the server-side RegisterOnSubmitStatement method, pretty strange for a client-side framework! The following note is at the end of the PRM reference: 'This class contains private members that support the client-script infrastructure and are not intended to be used directly from your code. Names of private members begin with an underscore ( ).' So onSubmitStatements is considered dangerous territory. But on the other hand, it works! Replying to: FredCK's patch is better in that it doesn't require an extra.js include - which my AJAX solution does.
However in terms of architecture, it's bringing ASP.NET-specific code into the fckeditor core, breaking the usual separation of the server-specific implementions as separate components from the core editor. I was aware of that and actually checked the effective impact of it in the core code.
So, that would not be a big issue, considering the importance of this compatibility fix. Another concern is that the onSubmitStatements object is an internal feature of PageRequestManager which.could. be subject to change in future releases, since it's not publicly specified or documented. (Unlikely I admit, but a potential gotcha.) I was pretty unhappy with it too.
I've actually minimized the usage of 'private' stuff to avoid possible incompatibilities. I've also checked if anything got changed in this sense since the.Net 2.0 and the 3.5 and everything we use here looks the same. But, this thing still makes me worried too. Only MS knows what could happen with.Net 4.0 or whatever. It could work for a temporary solution though. We always have the chance to fix it in the future.
Another problem would be if a different Javascript framework decided to name something Sys.WebForms.PageRequestManager. Again very unlikely but would cause unexpected problems! Unlikely to happen, but I've added it into a 'try' block just in case. A further problem I'm not sure about, is what would happen if the fckeditorapi code ran.before.
the PageRequestManager had loaded? Personally I don't know enough about the Javascript pipeline in different browsers to know how possible this is. Basically, are scripts.guaranteed.
to be executed in the order that they are referenced in the page, or are they just executed as soon as they're downloaded? This is not an issue because the API will get called only when the editor is loaded, far later the page loading completion. So, is still a possible solution. I've avoided other things to not introduce unwanted dependencies to the FCKeditor.Net assembly.
But, I still wanted to give it a try by using reflection. So, here we have the and patch files for it. It also introduces the PreventSubmitHandler setting.
What do you guys think about this one now? What should be the way to go?
Replying to: @serializer, @craigm: Any comment on this? I have to commit this thing to the upcoming release, and I'm still unsure which option to pick for it. I like my latest proposal, but I need some feedback to be sure it is ok in that way. Hi Fred, I have just tested your new solution (2342FCKeditor.patch and 2342FCKeditorNet.patch) in my app and it seemed to work fine. Although this would require users to update to the latest versions of both components (.), I think it is a cleaner solution and I believe it resolves the concerns raised by serializer regarding your previous solution.While I was applying your patch I noticed that the new solution seemed to work without the js patch. I tested this again by commenting out the changed lines and clearing the cache on the browser to ensure I had the latest files.
If this is the case it may be that the main editor patch does not need to be applied to the next release, and therefore users will only need to update the.Net component to fix this problem? Cheers, Craig. @FredCK: Sorry for causing delay here. Basically, I still prefer my original method - because it fits in neatly with the AJAX interface, rather than having to use Reflection which is less maintainable and less obvious what is going on.
However yours is more straightforward in that it does not require a separate build to support backwards compatibility, and it does not produce the additional.js include that I did. Really, both approaches are doing exactly the same thing; I just moved my client script into a separate resource rather than directly writing code in the RegisterOnSubmitStatement call. To this end your version outputs slightly more code on each page than mine did, at the tradeoff of one less include, which was pretty small anyway. Really the pros/cons of the two approaches aren't big enough in either case to be worth worrying about. I definitely prefer this method to your first patch, so I think we have a consensus that 2342FCKeditor.patch and 2342FCKeditorNet.patch are the way to go. Just one minor suggestion: instead of overriding the OnLoad method, how about moving that code into OnPreRender?
The main reason is if the control has Visible=false, then it won't exist on the page, and so the submit statement won't be needed. OnPreRender only gets called if the control is actually getting rendered. Replying to: Fixed with and. Special thanks to serializer. This fix would never come up without his great contributions. Thanks also to craigm and all others who have helped us on testing, giving their invaluable feedback.
I am using your new version at the moment and I had to change something. I'm afraid you forgot that people can use their own implementation of the ScriptManager, or the AjaxControlToolkit Scriptmanager, which has a BaseType of System.Web.UI.ScriptManager. So wouldn't it be better to check for the BaseType, or if that isn't enough the Type and BaseType? Replying to: I don't think even BaseType would be enough for all possible scenarios. What if I subclassed the AjaxControlToolkit Scriptmanager itself to create a further implementation? Then, the BaseType would be the AjaxControlToolkit implementation, not System.Web.UI.ScriptManager. Instead, use the Type.IsSubClassOf method to check the type.
Then any number of derivations will be supported. Yes, you are right. My post was just meant to show a problem with the current version. I knew this wasn't the best solution, but I didn't have the time to search for 'the better' solution:).
Download Asp.net 3.5
The code in PreRender is much slower than it needs to be. There are two areas that can be improved: Finding the page's ScriptManager Use the static method instead of recursively going through the page's control tree. Using ScriptManager.GetCurrent works for both 'plain' System.Web.Extensions and AjaxControlToolkit (using ToolkitScriptManager). Use of Reflection Do the Type.GetMethod/Type.GetProperty calls only once.
Do it at class initialization time and save the resulting MethodInfo/PropertyInfo for later use. I'll attach a patch implementing both ideas. Replying to: The code in PreRender is much slower than it needs to be. There are two areas that can be improved: Finding the page's ScriptManager Use the static method instead of recursively going through the page's control tree.
Using ScriptManager.GetCurrent works for both 'plain' System.Web.Extensions and AjaxControlToolkit (using ToolkitScriptManager). Use of Reflection Do the Type.GetMethod/Type.GetProperty calls only once. Do it at class initialization time and save the resulting MethodInfo/PropertyInfo for later use. I'll attach a patch implementing both ideas. FCK has to be backwards compatible with.NET 2.0 Correct me if I'm wrong, but GetCurrent isn't backwards compatible. I think that's the reason for choosing Reflection too. Replying to: FCK has to be backwards compatible with.NET 2.0 Correct me if I'm wrong, but GetCurrent isn't backwards compatible.
I think that's the reason for choosing Reflection too. My code uses GetCurrent only via reflection. On.NET 2.0 Type.GetType( 'System.Web.UI.ScriptManager, System.Web.Extensions' ) will return null. As a result 'getCurrentScriptManagerMethod' will be null. Hence we'll exit early in PreRender: if (!IsCompatible getCurrentScriptManagerMethod null ) return; No harm done. On the other hand, when 'System.Web.UI.ScriptManager, System.Web.Extensions' is known, all the MethodInfo/PropertyInfo will be!= null and invoked. Replying to: I was just going to point that out, but you were too quick;) Jskripsky thanks for this solution, it addresses all my previous concerns, in particular the slow traversal up the control hierarchy as you pointed out.
(Not so much of an issue in a small test page; but the project I'm working on has a vast and complex control hierarchy and I really was worried about the speed factor!) I'd started looking at fixing this but hadn't yet had time so you've saved me a fair bit of work:). This should also address the issues of subclassing ScriptManager as raised by kipusoep, since GetCurrent should quite happily return a reference to whatever ScriptManager (descended or otherwise) is managing the page. I'm reopening the ticket since I consider this patch provides critical improvements to the package - pending some tests to ensure it all works of course;). Replying to: Type.GetType( 'System.Web.UI.ScriptManager, System.Web.Extensions' ) This line doesn't work (in my scenario at least). Testing locally this returns null ( with System.Web.Extensions loaded). If I change it to: Type.GetType( 'System.Web.UI.ScriptManager, System.Web.Extensions',true ) Then I can see that a FileNotFoundException is being thrown. I think it might be because my GAC contains two different versions of System.Web.Extensions (Frameworks 2.0 and 3.5).
This situation is also quite likely on shared hosting. To get it working I had to change the line to: Type scriptManagerType = Type.GetType( 'System.Web.UI.ScriptManager, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35' ); Obviously this references a specific version and so wouldn't work with Framework 2.0. I've seen a method a Rick Strahl's blog which called AppDomain.CurrentDomain.GetAssemblies then looped through to find System.Web.Extensions. But this doesn't seem very optimal either, and I'm pretty sure the GetAssemblies call will fail in medium trust. So, I don't quite know what to do here. Perhaps we could just have two calls to Type.GetType, and check for both possible versions of System.Web.Extensions.
As and when newer versions of AJAX are released, this will need updating. Replying to: Replying to: Type.GetType( 'System.Web.UI.ScriptManager, System.Web.Extensions' ) This line doesn't work (in my scenario at least). You're right, Type.GetType needs a full assembly name including version and pubkey token to load from the GAC. I was using a heavily customized version of Mono for the testing. Obviously this references a specific version and so wouldn't work with Framework 2.0. I've seen a method a Rick Strahl's blog which called AppDomain.CurrentDomain.GetAssemblies then looped through to find System.Web.Extensions. But this doesn't seem very optimal either, and I'm pretty sure the GetAssemblies call will fail in medium trust.
So, I don't quite know what to do here. Perhaps we could just have two calls to Type.GetType, and check for both possible versions of System.Web.Extensions. As and when newer versions of AJAX are released, this will need updating. I did some research on possible options. Strahl's approach indeed seems to be our best bet.
.net 3.5
According to (search for 'trust'), it should work with medium trust as well.