New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeDevelopment and...Development and...Building ExtensionsBuilding ExtensionsModulesModulesProperties problemProperties problem
Previous
 
Next
New Post
2/22/2011 4:15 AM
 
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?
 
New Post
2/22/2011 5:10 PM
 
I have been wondering about this VS "feature" as well. It is incredibly annoying and makes me dread changing my ascx files if there is more than 2-3 DNN controls on it.

I assume it is because my project location in my file structure is not relative to a DotNetNuke installation so it can't find the usercontrol in VS.
<%@ Register TagPrefix="dnn" TagName="Label" Src="~/controls/LabelControl.ascx" %>

I wonder if I move my module folder into a dotnetnuke installation in the desktopmodules folder it would fix this. Developing from that folder isn't desired though.
 
New Post
2/22/2011 8:54 PM
 
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
 
New Post
2/24/2011 3:19 AM
 
So you suggest developing the module in my DNN site and just use the module project in order to compile the module?
 
New Post
2/24/2011 5:37 AM
 
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
 
Previous
 
Next
HomeHomeDevelopment and...Development and...Building ExtensionsBuilding ExtensionsModulesModulesProperties problemProperties problem


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.