After a long time of searching what is wrong with the TextEditor control I found what happens with my projects. I used to put the TextEditor control in my modules and I had no problem with it. The control used to appear properly but when I used the Text property of the control to have access to the typed text the Visual Studio was acting like there is not such a property. I have spend a lot of time searching for a solution and I have found what causes the problem but I can not find a solution for this problem.

When I make a change to the aspx file and save the file, Visual studio changes the declaration of the TextEditor control in the designer.vb file. For some reason the following declaration

Protected WithEvents ctlTextEditor As Global.DotNetNuke.UI.UserControls.TextEditor

becomes

Protected WithEvents ctlTextEditor As Global.System.Web.UI.UserControl

I open the designer.vb file and I change it in order to have the right declaration of the control but when I make another change to the aspx file the visual studio replaces again what is correct with the incorrect declaration.

Is there a way to disable this action of the visual studio?

I have encountered this same VS issue when developing modules outside of their normal location within a child folder of DesktopModules. Oddly in any given project it is almost always the same DotNetNuke user control (most often the TextEditor or DNNLabel) that looses its correct type declaration in the .ascx.designer.vb file. I have tried variations on setup of the project's web properties for Project URL and Override Application URL without eliminating the problem completely. You have also probably noticed that the DotNetNuke usercontrols do not get properly rendered in the VS Designer (which I never use anyway) and show the squiggly underline in the @ Register directives in source view since VS cannot locate the user control. Fortunately that can be ignored.

When I have developed inside a child folder of DesktopModules, this issue does not occur. I, too, prefer to develop outside of the DotNetNuke website install and thanks to MS Build scripts which deploy the necessary controls and assemblies to the test site on each build find this approach to development the best for me.

I wish I had the solution for this.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner

I always create a custom dnn install when creating a new module - and build the module directly in the desktopmodules folder of that install.

Also unless I know explicitly that I will distributing the module to 3rd parties - I build the modules using the WSP development model - there is no compile cycle this way - and no waiting for the application pool to reload.  You can pretty much test cycle develop this way, with the site live and running in your web browser and coding is VS at the same time - change a line of code - refresh - and its there live.

The other advantage of rolling each new module in its own dnn install is that you can setup regression / compatibility versions much easier - create and dnn instance of the lowest level version you want to be compatible with - and build against it.

Westa