A few months back I posted a query regarding custom Action Icons for Containers (Please see: How to Customize Module Actions Icons Programatically? - http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/109/threadid/254282/scope/posts/Default.aspx )

In DNN V4.9.1 and earlier editions, one would have to register Action Buttons up to 5 times, depending on which controls you wanted available with your container. Like so:

<%@ Register TagPrefix="dnn" TagName="ACTIONBUTTON5" Src="~/Admin/Containers/ActionButton.ascx" %>
<%@ Register TagPrefix="dnn" TagName="ACTIONBUTTON4" Src="~/Admin/Containers/ActionButton.ascx" %>
<%@ Register TagPrefix="dnn" TagName="ACTIONBUTTON1" Src="~/Admin/Containers/ActionButton.ascx" %>
<%@ Register TagPrefix="dnn" TagName="ACTIONBUTTON2" Src="~/Admin/Containers/ActionButton.ascx" %>
<%@ Register TagPrefix="dnn" TagName="ACTIONBUTTON3" Src="~/Admin/Containers/ActionButton.ascx" %>

The corresponding custom icon references and control placement would be as follows:

<dnn:ACTIONBUTTON5 runat="server" id="dnnACTIONBUTTON5" commandname="ModuleHelp.Action" displayicon="True" displaylink="False" iconfile="Icon_Help.gif" />
<dnn:ACTIONBUTTON4 runat="server" id="dnnACTIONBUTTON4" commandname="ModuleSettings.Action" displayicon="True" displaylink="False" iconfile="Icon_Settings.gif" />
<dnn:ACTIONBUTTON1 runat="server" id="dnnACTIONBUTTON1" commandname="AddContent.Action" displayicon="True" displaylink="False" iconfile="Icon_Edit.gif" />
<dnn:ACTIONBUTTON2 runat="server" id="dnnACTIONBUTTON2" commandname="SyndicateModule.Action" displayicon="True" displaylink="False" iconfile="Icon_RSS.gif" />
<dnn:ACTIONBUTTON3 runat="server" id="dnnACTIONBUTTON3" commandname="PrintModule.Action" displayicon="True" displaylink="False" iconfile="Icon_Print.gif" />

Where the image referred to in "iconfile="Icon_Help.gif" would be in the root of the container folder.

In DNN V5.0.0, you only have to register the Action Buttons once.  Like so:

<%@ Register TagPrefix="dnn" TagName="ACTIONBUTTON" Src="~/Admin/Containers/ActionButton.ascx" %>

And then the corresponding control placement would be as follows:

<dnn:ACTIONBUTTON runat="server" ID="dnnACTIONBUTTON1" CommandName="AddContent.Action" DisplayIcon="True" DisplayLink="True" />
<dnn:ACTIONBUTTON runat="server" ID="dnnACTIONBUTTON2" CommandName="SyndicateModule.Action" DisplayIcon="True" DisplayLink="false" />
<dnn:ACTIONBUTTON runat="server" ID="dnnACTIONBUTTON3" CommandName="PrintModule.Action" DisplayIcon="True" DisplayLink="false" />
<dnn:ACTIONBUTTON runat="server" ID="dnnACTIONBUTTON4" CommandName="ModuleSettings.Action" DisplayIcon="True" DisplayLink="false" />

I have 3 Questions, that I'm hoping someone (Timo Breumelhof?) could answer please.

1. When I apply a custom icon using "iconfile="myfilenamehere.gif" for dnnACTIONBUTTON1, all other module-specific icons (e.g. the Export & Delete Icons in Hosts > Portals) .... display that icon.  What is the best way to include custom Module icons either programmatically or with CSS?
2. If I use custom icons, how do I prevent DNN from displaying the same icon for other functions - Like Export, Import, View options, etc..?
3. How do I set custom module icons for DNN 5?

Again, any help would be appreciated.

Thanks
Jon

Shebang Websites - A product of Mogridge Design
Hey, we're partnered with UntangleMyWeb.com

Hi Timo

Thank you for the response.

Did you try in 4.9.1..?  or 5.0.0 - They both do the same thing.  Set your test container to the default Admin container, go to HOST > PORTALS.
The problem I'm having is that the default EXPORT PORTAL icons, etc all take on the same icon as ACTION 1 (the DNN Blue Pencil Icon).  Also, in a Module like the Ventrian Simple Gallery, the "View Options" icon takes on the same icon as ACTION 1. 

Can I send you a screenshot...?  Do you want to test and get back to me..?

Jon

Shebang Websites - A product of Mogridge Design
Hey, we're partnered with UntangleMyWeb.com

This is not a specific DNN 4.9 or 5.0 issue, I tested this in DNN 4.8.4 and it is the same.
So it is not new, although I never noticed it before.

The only "solution" for now would be to use a different container for the admin interface.