WYSIWYG Editing of HTML in a Windows Forms Control

By Yaakov Ellis | March 19, 2007 - 14:52 | Articles, c#, Code, windows forms

In a WinForms project that I am working on right now, I have text stored in HTML format in the database. I need a way for novice users to be able to edit this text using a WYSIWYG interface.

The most obvious choice for this in the Windows.Forms control library that is part of the .Net 2.0/3.0 framework is the RichTextBox control. This control gives you a textbox that has functionality similar to the WordPad application found in the Windows OS. It can display formatted pretty well. Aside from the fact that you have to handle all formatting of text in code, RichTextBox it has one major shortcomings: It can only input/output plain text or RTF encoded text. If I wanted to use a RichTextBox control to edit HTML, I would need some way to translate from the source HTML (stored in the DB) to RTF (to be displayed in the RichTextBox) and then back to HTML (to be stored again in the DB). Although I found some components from Sautin Software that seem to do the job, they cost money that I would rather not spend, and add a layer of complexity to my code library that I would rather avoid.

I found a couple of controls that extend the RichTextBox in order to allow input of HTML: An extended RichTextBox to save and load “HTML lite” files by Oscar Londoño (Code Project – For .Net 1.1/VS 2003) and RichTextBox that Displays XHTML by Eric Voreis. Both of these controls extend the RichTextBox control in the Windows.Forms library so that it can translate on the fly between RTF and HTML code (so you can input HTML code, see it displayed in the RTB and export HTML code). However, both are old and only support a small subset of HTML tags (although this can be extended in the source, it required knowledge of how RTF works). Also, since they use a RichTextBox control for editing and display, the display is similar but not identical to what you would get using a WebBrowser.

The next method that I found for providing this type of error is HTML Editor by Carl Nolan (Microsoft Consulting Services). This control (written in 2003 for .Net 1.1) modifies a WebBrowser control to allow inline editing and display of HTML. It is professionally written, provides support for many HTML tags and does just about everything that I need (and is free). The one problem is that it is pre-.Net 2.0. It uses a WebBrowser control from before this control was included as part of the Windows.Forms library in .Net 2.0 and thus has to reference Win32 calls and perform other types of acrobatics in order to get the control to function properly. This matters to me because it decreases portability of the control (using Mono, for instance), and makes it harder for me to customize and edit.

The control that I am using in the end employs the same general idea used in HTML Editor, but takes advantage of new features (like the native WebBrowser class) provided by the .Net 2.0/3.0 framework and and Visual Studio 2005. A Windows Forms based text editor with HTML output by Kevin DeLafield uses a WebBrowser control with modified functionality to allow WYSIWYG display and editing of HTML text. It provides all of the functionality that I am looking for and allows for easy modifications and customizations in Visual Studio 2005. I recommend that anyone in need of similar functionality take a look at this control.

Global Application Error Handling in Windows Forms Applications

By Yaakov Ellis | March 2, 2007 - 13:30 | Articles, c#, Code, windows forms

1 Comment

In my current project, I would like to log all Windows Forms errors, including those that are not caught explicitly. Lacking a built-in method (like Application_Error in the Global.asax file of an ASP.net application), I needed another way to easily catch all errors. After a bit of searching, I found a solution by Craig Andera: WinForms Catch-All Exception Handling. Here is the short version:

In the main entry point for your application (found by default in the Progrsm.cs file, Main() method), add a listener for the Application.ThreadException event.

[STAThread]
static void Main() {
  Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
  Application.Run(new Form1());
}

private static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e) {
  // Handle Exception
}

This should allow you to catch all Exceptions in your application that were not caught at the source.

Cannot Access a Disposed Object

By Yaakov Ellis | January 28, 2007 - 18:52 | Articles, c#, windows forms

14 Comments

In a Windows Forms application that I am working on, I had the following scenario: while the main form (Main.cs) is loading, I prompt the user to prove their credentials. If they are unable to do so, the form is closed (using this.close) and application execution is halted.

The problem is, when I first tried this, I an exception was thrown in Program.cs on the following line:

Application.Run(new Main());

The exception was of type System.ObjectDisposedException, and the accompanying message was “Cannot access a disposed object”.

What happened? According to the official documentation, the method System.Windows.Forms.Application.Run(Form) has the following purpose: “Begins running a standard application message loop on the current thread, and makes the specified form visible.” When this line of code is called, it first instantiates a new instance of the given Windows.Form implementation (in my case, Main.cs) and after it is instantiated, sets the Form.Visible parameter to true, thereby showing the form. In my case, during the instantiation of the form, the Close() method on the form was called, which disposes the Forms object. So when Program.cs attempts to set Main.Visible = true, Main is already disposed and the above error is thrown.

What is the workaround? I can think of two ways off the top of my head (the first one is the one that I ultimately used). Can you think of any others?

Substitute the line in Program.cs with the following. Here the Main class is instantiated first, and only if it is still in existence and not disposed will Application.Run be called. Thus, if Main is closed during instantiation, Application.Run will never be called and the application will close on its own.

Main main = new Main();
if (main != null && !main.IsDisposed) {
  Application.Run(main);
}

Do not call the user authentication code during the instantiation of the main Form of the application. Instead, call it in some event (like Activate) that is tied directly to the creation of the Form, but is not part of the initial instantiation code. In this case the class will instantiate, Application.Run will execute, and only after will the user authentication (and possible subsequent disposal of the form and exit from the application) take place.

Visual Studio 2005 Add-Ins and Tools That I Use

By Yaakov Ellis | December 19, 2006 - 12:13 | c#, Code, WebDev, windows forms

9 Comments

I am right now in the middle (about 20% and 18K lines of code through) a pretty substantial Windows Forms project using Visual Studio 2005 (C#). Here are some of the add-ins that I have been using (ranked in order of essential to useful):
(more…)

Porting .Net Assemblies to Mono using MoMA

By Yaakov Ellis | November 28, 2006 - 19:00 | asp.net, c#, Code

Error when sending Html Mail from ASP.net WebApp

By Yaakov Ellis | September 27, 2006 - 13:10 | asp.net, c#, Code

2 Comments

On an ASP.net site (1.1), I was trying to send an email message using good old SmtpMail.Send(MailMessage message). When I did so, I got the following message “could not access CDO.message object“. After some Googling, I tried out all of the different security/smtp/relary/permissions related suggestions (most can be found on the systemwebmail.com site, a very handy reference if you have some questions regarding use of the System.Web.Mail library in ASP.net 1.1). Still not working. I checked the InnerException. It looked something like this:

InnerException: {“Unknown Error” }
Message: “Exception has been thrown by the target of an invocation.”
Source: “mscorlib”
StackTrace:
” at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)\r\n
at System.RuntimeType.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParameters)\r\n
at System.Type.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args)\r\n
at System.Web.Mail.LateBoundAccessHelper.SetProp(Type type, Object obj, String propName, Object propValue)\r\n
at System.Web.Mail.LateBoundAccessHelper.SetProp(Object obj, String propName, Object propValue)”

But nothing apparently wrong there. The one weird thing that I could find is that if I set MailMessage.BodyFormat = MailFormat.Html, it would not work. If I set it to MailFormat.Text, it would work fine. Very suspicious.

In the end, the following solution worked for me. It was posted by Kyle Parker on the DotNetNuke forums:

Close Visual Studio
Open a Command Window
regsvr32 cdosys.dll /u
iisreset /restart
regsvr32 cdosys.dll
resume work in VS

After unregistering and reregistering this DLL, suddenly I was able to send Html mail again from my site. Kyle reported on his post that this only worked as a temporary solution. It is working for me so far.

Anyone know why this happened? Some other program messed up the dll that handles Html mail?

@yaakov

Subscribe

Archive

Mock Integration

Category Archives: c#