Frustrating, isn’t it.  But the solution is a simple one.  Cancel out of that dialog and click OK and the follow up pop (that’s fun to say).

In the menu of Management Studio select Tools, then Options

On the options dialog select Designers and then Table and Database Designers.  Uncheck the option: Prevent saving changes that require table re-creation.

Click OK and now you can save your table changes.

I know you developers have been there.

But I can’t just throw it away, so here it is for all to enjoy.

Ever needed to use the Tab Module drop down that DotNetNuke uses to put modules on a page?  I did.

Start with a user control and put this code on the presentation page

<asp:Label runat="server" ID="lblErr" ForeColor="White"></asp:Label>
<asp:UpdatePanel runat="server" ID="upTabs" ChildrenAsTriggers="true">
    <Triggers>
        <asp:AsyncPostBackTrigger ControlID="ddlTabs" EventName="SelectedIndexChanged" />
    </Triggers>
    <ContentTemplate>
        <asp:Label runat="server" ID="lblModErr"></asp:Label>
        <asp:DropDownList runat="server" ID="ddlTabs" AutoPostBack="true">
        </asp:DropDownList>
        <asp:DropDownList runat="server" ID="ddlModules">
        </asp:DropDownList>
    </ContentTemplate>
</asp:UpdatePanel>

And this code belongs in the code behind

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
Try
  If Not Page.IsPostBack Then
    ddlTabs.DataSource = TabController.GetPortalTabs(Me.PortalId, -1, True, Localization.GetString("DefaultPagesListItem.Text", LocalResourceFile), True, False, False, True, True)
    ddlTabs.DataValueField = "TabID"
    ddlTabs.DataTextField = "IndentedTabName"
    ddlTabs.DataBind()
  End If
Catch exc As Exception    'Module failed to load
  ProcessModuleLoadException(Me, exc)
End Try
End Sub

Protected Sub ddlTabs_SelectedIndexChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles ddlTabs.SelectedIndexChanged
Try
  ddlModules.Items.Clear()

  Dim objModules As New ModuleController
  Dim tabModules As Dictionary(Of Integer, ModuleInfo) = objModules.GetTabModules(ddlTabs.SelectedValue)
  Dim result As New Dictionary(Of String, Integer)

  For Each tabModule In tabModules.Values
    ddlModules.Items.Add(New ListItem(tabModule.ModuleTitle, tabModule.ModuleID))
  Next
Catch ex As Exception
  lblModErr.Text = ex.Message
End Try
End Sub

Simple and yet no one else seems to have it on one page.  Now, at long last, well, not long last, but here it is!

With a dataset you would reference a field this way:

e.Row.DataItem(“FieldName”)

But when using a generic list you’ll get an error along the lines of

No default member found for {myclass}

Here’s how to set up the RowDataBound event when using a Generic List.

If e.Row.RowType = DataControlRowType.DataRow Then
  Dim obj As MyNameSpace.MyListInfo = CType(e.Row.DataItem, MyNameSpace.MyListInfo)
  Dim myVal as string = obj.MyField

  --any other code here---
End If

In this case “MyNameSpace” is the namespace…go figure…and MyListInfo is the class containing all the properties that correspond to fields in your table.

This is one of the reasons I love the list so much: I don’t have to remember all the names of the fields because they’ve all been turned into properties.

More to come on the Generic List!

There’s a better way.  In DotNetNuke 5 you can piggyback on the existing permissions functionality.

Let’s say we’re creating a module called Assets and we need a custom permission that allows particular users and roles to assign the asset to other users.  The standard “View Module” and “Edit Module” won’t get us there.

1.First create your customer module and include an App_Code folder.

2. The first thing we need to do is create a class called “Module Security” and place it in the App_Code folder of our module.  The code for the module looks like this (see notes below the code for explanation):

Imports Microsoft.VisualBasic
Imports DotNetNuke.Entities.Modules
Imports DotNetNuke.Security.Permissions

Namespace MyModules.Modules.Asset
    Public Class ModuleSecurity
        'Constants
        Public Const PERMISSIONCODE As String = "MYMOD_ASSET"       Â
        Public Const PN_ASSIGN As String = "ASSET_ASSIGN"        

        'private variables
        Private _ASSIGN As Boolean = False

        Private _moduleInfo As ModuleInfo

        Sub New(ByVal moduleInfo As ModuleInfo)
            ' TODO: Complete member initialization
            _moduleInfo = moduleInfo
            ModuleSecurity(moduleInfo)
        End Sub

        Public Sub ModuleSecurity(ByVal moduleInfo As ModuleInfo)
            Dim permCollection As ModulePermissionCollection = moduleInfo.ModulePermissions
            _ASSIGN = ModulePermissionController.HasModulePermission(permCollection, PN_ASSIGN)
        End Sub

        Public ReadOnly Property ASSIGN As Boolean
            Get
                Return _ASSIGN
            End Get
        End Property

    End Class
End Namespace

PermissionCode: This is the Group label for the permissions. All permissions for the module should have the same PermissionCode

PN_Assign: The nomenclature here is “Permission Name Assign”.  I use this for each permission.  Another permission might be PN_Retire – to retire an asset.

2. In your DotNetNuke database use this format and run the following query for each permission you create

Insert into Permission(PermissionCode, ModuleDefID, PermissionKey, PermissionName, ViewOrder, CreatedByUserID, CreatedOnDate, LastModifiedByUserID, LastModifiedOnDate)
Select '{PermissionCode}', ModuleDefID, '{PermissionKey}', '{PermissionName}', 10000, 1, GETDATE(), 1, GETDATE() Â
from ModuleDefinitions Where FriendlyName = '{Asset}'

For our example the query would like this:

Insert into Permission(PermissionCode, ModuleDefID, PermissionKey, PermissionName, ViewOrder, CreatedByUserID, CreatedOnDate, LastModifiedByUserID, LastModifiedOnDate)
Select 'MYMOD_ASSET', ModuleDefID, 'ASSET_ASSIGN', 'Assign Asset', 10000, 1, GETDATE(), 1, GETDATE() Â
from ModuleDefinitions Where FriendlyName = 'Asset'

The ViewOrder should start at 10000 because DotNetNuke reserves 0-9999 for DotNetNuke permissions.

3. To use the permission in your module put in some code like this:

'At Module level
Private msSecurity As ModuleSecurity
Private msAssign As Boolean = False

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

    msSecurity = New ModuleSecurity(Me.ModuleConfiguration)
    msAssign = Convert.ToBoolean(msSecurity.ASSIGN)
  Â
    'on our page we have an ASP:Button called btnAssign          Â
    if msAssign Then btnAssign.Visible = False
End Sub

4. The last piece is set up the DotNetNuke module manifest to automatically insert the permissions into the database when the module is installed  The manifest file should look like this:

<moduleDefinitions>
    <moduleDefinition>
        <moduleControls>
             --module definitions deleted for brevity----
        </moduleControls>
        <permissions>
            <permission code="ATPI_ASSET" key="ASSET_ASSIGN" name="Assign Asset" />
        </permissions>
    </moduleDefinition>
</moduleDefinitions>

And that should do it.  Now you’re permissions should show up in the Settings of your module with the DotNetNuke permissions, they should be accessible in your module, and they should automatically populate when the module is installed using the DotNetNuke Extension installer.

I scratched my head for quite a while on this one.  Looked all over the web without luck until I came across a note that caused me to investigate the web.config.  The suggested solution didn’t resolve the problem, but I did notice something else.  The new module that I had installed, using the DotNetNuke install process, was listed in the codeSubDirectories section of the Web.Config, but the Log module was not.

I had installed the Log module manually; meaning I just pushed up the files, ran the SQL script and added the extension and it’s controls by hand in the extensions section of DotNetNuke.  Since I installed it manually an entry in codeSubDirectories was never created.

On a lark, I manually added the Log module to the codeSubDirectories and my error went away.

Conclusion: When a custom module is listed in the codeSubDirectories section any custom module listed as a dependency in the manifest file must also be listed in the codeSubDirectories section.

Normally, if I need to fire off a client script server side I would do it like this:

1. An asp:Button called myButton has been clicked on the page
2. The following event is fired:

   Private Sub myButton_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles myButton.Click
        'Do some server side processing
   
        Dim script as String = ""
        script = "<script language='javascript' id='myScript'>"
        script += "alert('some alert text');"
        script += "</script" + ">"
   
        If Not ClientScript.IsClientScriptBlockRegistered("myScript") then ClientScript.RegisterClientScriptBlock(System.Type.GetType("System.String"), "myScript", script)
   End Sub

3. If you’re building you’re application in DotNetNuke replace that last line calling the ClientScript with this line:

   If Not Page.ClientScript.IsClientScriptBlockRegistered("myScript") Then Page.ClientScript.RegisterClientScriptBlock(Page.GetType(), Guid.NewGuid().ToString(), script)

But, if myButton is included as a trigger on an Update Panel then the ClientScript won’t fire.  The Update Panel itself is firing client side code which will keep ClientScript from being added to the view state and firing.

Instead, use ScriptManager:

Private Sub myButton_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles myButton.Click
     'Do some server side processing

     Dim script as String = ""
     script = "<script language='javascript' id='myScript'>"
     script = +"alert('some alert text');"
     script = +"</script" + ">"

     ScriptManager.RegisterClientScriptBlock(Page, Page.GetType(), Guid.NewGuid().ToString(), script, True)
End Sub

For more detailed info: Differences between RegisterClientScriptBlock & RegisterStartupScript and how they work with AJAX Update Panel

However, there’s been a fix using the PersistentCookieTimeOut option.  Once set in the web.config the user will be automatically logged in; that is, the login page will be bypassed and the user will be immediately directed to the home page.  To clear this option the user simply does a manual log out instead of just closing the browser.

For some sites this is a problem.  You wouldn’t want this on your banking site, for example.  Someone just has to open your computer, go to the page, and they are in!  However, for other work flows its not so much an issue.  Say you are in and out of the site all day and don’t want to have to keep logging in, but at the end of the day you officially log out.

Here’s the code to make it happen:

In the web.config add the following line to the <appSettings> section

<add key=”PersistentCookieTimeout” value=”20160″ />

Where 20160 is two weeks in minutes, but you can set it to whatever you like.

For more information see this post by Cathal Connolly at DotNetNuke: New Solution to An Old Problem

SELECT DATEPART(YEAR,myDateField) AS 'Year',
           DATEPART(wk,myDateField) AS 'Week #',
           MIN(DATEADD(wk, DATEDIFF(wk,0,myDateField), 0)) AS 'Week date',
           SUM(COALESCE([Hours],0)) AS 'Hours'
FROM myTable
GROUP BY DATEPART(YEAR,myDateField),DATEPART(wk,myDateField)
ORDER BY 1,2

In this example we put a CheckBox on each row, allow the user to select whichever records they want to approve and then approve them with the click of a button.

1) Build your GridView and display your data. The following code only applies to the current page, so if your GridView allows paging you will want to balance between showing too many records versus showing enough records for an efficient approval process.  Make sure you set the DataKeyNames field to your Table’s Identity field.

2) Add the following row to your GridView:

<asp:TemplateField>
    <ItemTemplate>
        <asp:CheckBox runat="server" ID="chkApprove" />
    </ItemTemplate>
</asp:TemplateField>

3) Add a button to your page

 <asp:Button runat="server" ID="btnApprove" Text="Approve Selected" />

4) Add the code to iterate through the GridView records to the Button Click event.

Protected Sub btnApprove_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles btnApprove.Click
01   Try
02       For Each row As GridViewRow In grdContent.Rows
03           If row.RowType = DataControlRowType.DataRow Then
04               Dim cChk As CheckBox = CType(row.FindControl("chkApprove"), CheckBox)
05                   If cChk.Checked Then
06                       ApproveMyRecord(grdContent.DataKeys(row.RowIndex).Value)
07                   End If
08           End If
09       Next
10   Catch ex As Exception
11      lblMsg.Text = "Approve error: " & ex.Message
12    End Try
End Sub

Breakdown:
Lines 01, 10-12: Basic Try/Catch error trapping routine.  The lblMsg control is arbitrary.  Display errors as you see fit.
Lines 02, 03, 08, 09: We are iterating through every displayed row in the GridView and checking for DataControlRowType.DataRow rows (this will exclude header and footer rows).
Line 04: Create a CheckBox variable and assign the row checkbox to it.
Line 05, 07: Check to see if the CheckBox is checked and if not, skip it.
Line 06: This is where you run the code to approve the individual record.  Grab the record ID from the DataKeys using the RowIndex value.

You can improve this code by collecting the ID’s and sending them to a Stored Procedure as a list and reducing the number of calls to the database.

First, check to see if it exists and if it does, drop it.

IF OBJECT_ID('tempdb..#MyTempTable') IS NOT NULL
Drop Table #MyTempTable

Second, build your table.  The “#” is important.  The “#” denotes it as a temp table.  Forget the hash and you’ll be creating permanent tables in your database every time the code runs.

Create Table #MyTempTable
 ( MyID int,
   MyText varchar(50)
 )

When creating you’re table you can include any kind and amount of fields that you can in a regular table. This is just a demo.

At this point you can fill the temp table with records and do whatever queries against it that your code requires as long as they occur in the same context.  Once the code stops running the temp table ceases to be available.

Now, go create some temp tables!