Can i use artisteer 3.1 in latest version of mojo??

Thanks

Omar

Hi Joe,

While you're at it (hope you're not through it already), you might consider incorporating this menu fix I found into the layout.master of the Artisteer skins.  This fixes the problem with the ASP.NET javascript overriding the styles set for the menu by Artisteer.

I detailed how I found the fix at the end of this post: http://www.mojoportal.com/Forums/Thread.aspx?pageid=5&mid=34&ItemID=4&thread=8023&pagenumber=2

I've taken the liberty of making a suggested update to your "Trouble with ASP.NET menus" article.  I'm including it here in html form to preserve the formatting I did outside this post editor:

<p>In older versions of ASP.NET the menu control and Treeview control rendered as a set of nested html table elements with lots of hard coded inline styles, it was not a very semantic way to markup a menu. After ASP.NET 2.0, Microsoft came out with the CSSAdapters to adapt the Menu and Treeview controls to produce a nicer set of ul and li elements which is much better structure for a menu. We have used those adapters modified to meet our needs, and we made our own mojoMenu and mojoTreeview controls which inherit from <code>&lt;asp:Menu</code> and <code>&lt;asp:Treeview</code> respectively, but also applies the CSS Adapters and lets us have more control over the markup rendered by the menu and treeview.</p>
<p>In ASP.NET 4 there were additional changes to the <code>&lt;asp:Menu</code> such that now there is some javascript associated with the Menu, and this javascript adds some inline style. Since our mojoMenu inherits from the ASP.NET menu it also has this unwanted javascript. Questions about this have come up over and over in the forums so I decided it was time to write a document about it so that I can link to it whenever the question comes up.</p>
<p>When you view the source of the page you will not see the extra style because it is applied from javascript, so the only way you can see it is to use something like Firebug to inspect the html after the javascript has modified it. What you will find is things like:</p>
<ul>
<li>ul elements have <code>style=&quot;position: relative; width: auto; float: left;&quot;</code></li>
<li>li elements have <code>style=&quot;position: relative; float: left;&quot;</code></li>
</ul>
<p>These things can interfere with your own CSS rules and have unintended consequences that are contrary to your design goals. In particular, these menus will not respect the float settings applied in Artisteer after the unwanted Javascript loads.</p>
<p>There is one direct method of disabling the unwanted Javascript, and four workaround methods.</p>
<p>The direct method involves asking the ASP.NET script loader to refer to your own file instead of ASP.NET's default script. The Javascript file in question is <code>MenuStandards.js</code>. Normally, ASP.NET will automatically detect the presence of an ASP Menu and fetch this file from the server, where it is hardcoded into the Web controls DLL. In order to override it, you need to find the <code>&lt;asp:ScriptManager&gt;</code> tag and change it to something like the following markup:</p>
<pre><code>&lt;asp:ScriptManager ID=&quot;ScriptManager1&quot; EnablePageMethods=&quot;true&quot; runat=&quot;server&quot; &gt;
&lt;Scripts&gt;
&lt;asp:ScriptReference name=&quot;MenuStandards.js&quot; assembly=&quot;System.Web&quot; path=&quot;MenuStandards.js&quot;/&gt;
&lt;/Scripts&gt;
&lt;/asp:ScriptManager&gt;
</code></pre>
<p>The <code>&lt;asp:ScriptReference&gt;</code> tag will instruct ASP.NET to fetch that particular script from the filesystem instead of the Web controls DLL. To complete the job, you need to create a file in your skin directory called <code>MenuStandards.js</code>. Leave this file empty and there will be no styles added to the menu.</p>
<p>While this seems to work fine, it's always a bit dicey to override a built-in part of ASP.NET without knowing all of what the default script is used for. In practice, we haven't seen anything wrong with this method, but in case something should pop up, you may want to use one of the other workarounds instead.</p>
<p>There are four workarounds to the problem.</p>
<ol style="list-style-type: decimal">
<li><p>You can configure the Menu to behave as it did in .NET 3.5 by this setting from theme.skin:</p>
<portal:mojoMenu runat="server" SkinID="SiteMenu" UseNet35Mode="true" /></li>
</ol>
<p>The only down side to this solution is that we lose one benefit of the.NET 4 menu. The .NET 2/3.5 Menu always renders a style block at the top of the page and this can also work against your intended styles. In .NET 4 the Menu has a property IncludeStyleBlock that you can set to false to eliminate the style block, but when you configure it to behave like .NET 3.5 it ignores this setting.</p>
<ol start="2" style="list-style-type: decimal">
<li><p>You could try using TreeView instead of Menu since it also renders as a list and it does not have javascript that applies style.</p></li>
<li><p>You can use the !important in your CSS rules to override the inline style rules that interfere with yours.</p></li>
<li><p>You might be able to write some javascript that runs after the menu script and remove those hard coded styles.</p></li>
</ol>
<p>For example if the <code>float:left</code> is causing you a problem which is very common when designing for right to left languages, you can overcome (using approach number 3) it by marking your css rules as important like this:</p>
<pre><code>.AspNet-Menu-Horizontal {float:right !important;}
.AspNet-Menu-Horizontal ul li {float:right !important;}
</code></pre>
<p>That should work in most modern browsers but might not work in older versions of some browsers. If you need to support older browsers you could use a Treeview or, you could possibly devise some javascript of your own that runs after the menu is initialized and then remove the inline style that was added by the menu javascript.

That's certainly good enough for me, just wanted to share.  It had always been a bit disconcerting to work with Artisteer skins and immediately run into menu issues with anything that didn't float left.  Since those skins are Artisteer-specific, I figured you might want to have a default for those skins that isn't broken by...well, default.  But there's certainly the risk of breaking other stuff by nulling out the script.  I just figured it might be better to fix a known bug and risk another in the bush than to just let users continue encountering the bug and only find the answer by having the wherewithal to go searching on the site.

Perhaps you might comment this solution into layout.master as an alternative, with a link to the "trouble" article.

In any case, glad to share, and I certainly appreciate the Artisteer love.  Thanks!

Awesome!  Great to hear.  Looking forward to 3.1.