今天又发现了一些新问题，其中就有一个关于动态修改 SiteMapPath的问题。找了N个网页，也试了N种方法，不过其实也就那么几个来回重复。终于在一个帖子中找到了解决的方法，贴出来以备将来使用。

        由于原文是帖子问答的形式，本文整理为说明形式(原文的繁体未作修改)。

        原文地址：http://www.purecs.net/thread/topic376_1.aspx

                            http://www.purecs.net/thread/topic479_1.aspx

实例:

pure C# 技術社群 » ASP.NET » 動態修改SiteMapPath路徑  

        在網頁上放置一個SiteMapPath可以提供使用者一個清楚的瀏覽路標指示，如果你的SiteMap是靜態不會變動的倒是很簡單，只要編寫好一個XML檔放上去，其它的事就可以不用管了，但是在動態網頁中SiteMap的路徑可能會隨著不同的情況而有所更動，這時預先建立的靜態SiteMap似乎就不怎麼好用了，因為你無法事先去預測SiteMap該有哪些路徑(就像現在這個論壇上面的SiteMap)，這個時後你必需要用程式動態控制SiteMapPath中Node的連結路徑及顯示的文字，現在只要跟著下面的步驟做就可以簡單的做到這個功能。

1. 先在Web Form中建立一個ModifyPath方法

private SiteMapNode ModifyPath(Object sender, SiteMapResolveEventArgs e)  

 2. 在Page_Load 中註冊SiteMapResolve事件給ModifyPath方法

SiteMap.SiteMapResolve += new SiteMapResolveEventHandler(this.ModifyPath); 

3. 最後在ModifyPath中撰寫動態路徑及所顯示的文字程式碼即可

 private SiteMapNode ModifyPath(object sender, SiteMapResolveEventArgs e)   
...{   
    SiteMapNode currentNode = SiteMap.CurrentNode.Clone(true);   
     SiteMapNode modifyNode = currentNode;   
  
    modifyNode.Url = "http://www.bbb.net";   
    modifyNode.Title = "bbb";   
 
    if ( (modifyNode = modifyNode.ParentNode) != null)   
     ...{   
         modifyNode.Url = "http://www.aaa.net";   
         modifyNode.Title = "aaa";   
     }   
  
    return currentNode;   
 } 

        好了，你現在應該可以看到一點點成果，至少SiteMapPath中的結點能被程式控制了，剩下的只需要寫出ModifyPath中真正的取得路徑的程式碼，動態修改SiteMapPath就是這麼簡單。

        SiteMapNode有一個ChildNodes集合屬性，包含Add、Insert、Remove、Clear等方法可以用來新增或是刪除結點，所以不管是多少層都可以在SiteMapResolve事件中依邏輯增加或減少層級，例如你在這個網站上回文時原本的結點應該是

                            pure C# 技術社群 >> ASP.NET >> 動態修改SiteMpaPath路徑 >> 回覆文章

但是在程式中已經把 "回覆文章" 這個節點刪除掉了
程序如下:

 //currentNode 為"回覆文章"   
 SiteMapNode currentNode = SiteMap.CurrentNode.Clone(true);   
   
 if (currentNode.Key.EndsWith("PostEditor.aspx".ToLower()))   
 ...{   
     //currentNode 為"回覆文章"的上一層 "動態修改SiteMpaPath路徑"   
     currentNode = currentNode.ParentNode;   
     currentNode.ChildNodes.Clear();   
}  

  现在变成:

                       pure C# 技術社群 >> ASP.NET >> 動態修改SiteMpaPath路徑

ps:我对上面的路径理解不一定很对,也没有进行测试,如果有错会更新

      再如，在当前节点的显示中，加入新的节点可以如下操作(为避免歧义,贴出该功能的程序而与前面无关,当然,原文也是这么写滴,可以偷懒 : D )

效果:

                        pure C# 技術社群 » ASP.NET » 動態修改SiteMapPath路徑» 新的節點

程序如下:

public partial class SiteMapPathDemo : System.Web.UI.Page   
 ...{   
     protected void Page_Load(object sender, EventArgs e)   
     ...{   
        SiteMap.SiteMapResolve += new SiteMapResolveEventHandler(SiteMap_SiteMapResolve);   
    }   
  
    private SiteMapNode SiteMap_SiteMapResolve(object sender, SiteMapResolveEventArgs e)   
     ...{   
         SiteMapNode currentNode = null;   
   
         if (SiteMap.CurrentNode != null)   
         ...{   
            currentNode = SiteMap.CurrentNode.Clone(true);   
   
             SiteMapNodeCollection childNodes = new SiteMapNodeCollection();   
   
             SiteMapNode newNode = new SiteMapNode(e.Provider, "newNode", "OthrePage.aspx", "新的節點");   
            newNode.ParentNode = currentNode;   
             childNodes.Add(newNode);   
             currentNode.ChildNodes = childNodes;   
   
             currentNode = newNode;   
         }   
   
         return currentNode;   
     }   

只好在给 ASPxMenu 数据绑定之后添加：

this.ASPxMenuMain.SelectedItem = null;

正确的方法

overflow 水平及垂直方向内容溢出时的设置
overflow-x 水平方向内容溢出时的设置
overflow-y 垂直方向内容溢出时的设置

以上三个属性设置的值为visible、scroll、hidden、auto

visible 默认值。使用该值时，无论设置的"width"和"height"的值是多少，其中的内容无论是否超出范围都将被强制显示。
hidden 效果与visible相反。任何超出"width"和"height"的内容都会不可见。
scroll 无论内容是否超越范围，都将显示滚动条。
auto 当内容超出范围时，显示滚动条，否则不显示。

scroll属性对比演示：
代码:
<div style="height:100px;width:100px;overflow-y:scroll;">
test
</div>

<div style="height:100px;width:100px;overflow-y:scroll;">
test<br>test<br>test<br>test<br>test<br>test<br>test<br>
test<br>test<br>test<br>test<br>test<br>test<br>test<br>
</div>


auto属性对比演示：
代码:
<div style="height:100px;width:100px;overflow-y:auto;">
test
</div>

<div style="height:100px;width:100px;overflow-y:auto;">
test<br>test<br>test<br>test<br>test<br>test<br>test<br>
test<br>test<br>test<br>test<br>test<br>test<br>test<br>
</div>


应用：

没有水平滚动条
style="overflow-x:hidden"

没有垂直滚动条
style="overflow-y:hidden"

没有滚动条
style="overflow-x:hidden;overflow-y:hidden" 或 style="overflow:hidden"

但是IE6总是无法正常显示

大家知道IE有两种渲染模式：Quirks Mode和Strict Mode。Quirks Mode基本上是非标准的，包括盒模型在内，它的渲染方式与W3C的标准有些出入。而Strick Mode基本上是标准的（反正都不是绝对标准也不是绝对不标准……）。IE6及以前版本会根据写在XHTML文档第一行（也只能是第一行）的DocType声明来选择渲染模式。如果发现了一个它能识别的DocType，比如XHTML Transitional或者XHTML Strict等等，它就使用Strict Mode来渲染。其他所有情况下都使用Quirks Mode。

      有些开发者为了显式地声明他们的XHTML文档是一个XML，会在文档的第一行（问题就在这里，它也必须在第一行）加上XML的序言（prolog）。比如：

                             <?xml version="1.0" encoding="gb2312"?>

    　虽然初衷是为了让文档更“标准”，但由于IE不认这行字，结果还是按Quirks Mode来渲染。

      IE7 解决这个问题，它会跳过prolog来看检查DocType。所以可能会出现IE6及以下版本用Quirks Mode渲染而IE7 用Strict Mode渲染的情况。

       现在让IE7渲染textbox的模式是Quirks Mode，这样textbox的overflow:visible属性就可以像IE6效果一样了，所以只要把XHTML文档第一行的DocType声明删除就可以了。

       这样问题就解决了。。。

      注意：虽然在IE7和IE6中显示一样的，但是在FF中还是不一样，所以这种方法只能解决IE7中的问题，FF中的是无能为力的。

 详见

 http://www.cnblogs.com/sunrack/articles/1301465.html

现在，最令网页设计者头痛的问题就是网页在各个浏览器中的兼容性。而兼容性差最长见的，也是最令人恐惧的便是“页面布局混乱”。常常一个页面在IE6下显示的非常完美，而到了IE7（或者FireFox）中，则惨的“不堪入目”。到底是什么让这些页面那么的“水土不服”呢？

       其实，这些都是IE6酿下的恶果，IE6对web标准的支持过于不足，甚至理解的有偏差，才导致了这些页面的“脆弱”。而IE7则修正了很多的那种“IE6对css解释和渲染”的bug。这种bug有很多。今天，这里只讲其中一个，但是确是最重要的一个，很多的“十分”混乱的页面都是它造成的。可以不客气地说，它简直就像“页面布局混乱黑帮”的幕后黑手，是引起页面布局混乱的祸首之一，而且是最大的一个。 它就是潜伏在网页背后的“‘overflow:visible’IE6渲染bug”。

原因——IE6对“overflow:visible”的误解

Visible： "This value indicates that content is not clipped, i.e.,it may be rendered outside the block box（注：后面这句可能是后续版本补充上来的）".

       注意，w3c只是说，超出容器的内部不会被剪切。但是它并没有说，超出来的内容可以“撑开”容器。所以下面这个例子中IE7的解释和渲染是正确的，而IE6则是错误的（因为它错误的认为，只有让容器内的内容“撑开”容器，才能让容器内的内容在超出时不被剪切），IE7和FireFox是一样的。

解决方法

       大家知道IE有两种渲染模式：Quirks Mode和Strict Mode。Quirks Mode基本上是非标准的，包括盒模型在内，它的渲染方式与W3C的标准有些出入。而Strick Mode基本上是标准的（反正都不是绝对标准也不是绝对不标准……）。IE6及以前版本会根据写在XHTML文档第一行（也只能是第一行）的DocType声明来选择渲染模式。如果发现了一个它能识别的DocType，比如XHTML Transitional或者XHTML Strict等等，它就使用Strict Mode来渲染。其他所有情况下都使用Quirks Mode。

      有些开发者为了显式地声明他们的XHTML文档是一个XML，会在文档的第一行（问题就在这里，它也必须在第一行）加上XML的序言（prolog）。比如：

                             <?xml version="1.0" encoding="gb2312"?>

    　虽然初衷是为了让文档更“标准”，但由于IE不认这行字，结果还是按Quirks Mode来渲染。

      IE7 解决这个问题，它会跳过prolog来看检查DocType。所以可能会出现IE6及以下版本用Quirks Mode渲染而IE7 用Strict Mode渲染的情况。

       现在让IE7渲染textbox的模式是Quirks Mode，这样textbox的overflow:visible属性就可以像IE6效果一样了，所以只要把XHTML文档第一行的DocType声明删除就可以了。

       这样问题就解决了。。。

      注意：虽然在IE7和IE6中显示一样的，但是在FF中还是不一样，所以这种方法只能解决IE7中的问题，FF中的是无能为力的。

这几天用div+css写网站，样子 上中下，中间是个左中右3列，可这3列不是等高偏巧有不同颜色的背景，结果就是ie、firefox...这些浏览器无一例外的现实的效果都是长短不齐，如何让这3列可以自适应高度？

调试了半天，搜索了一番，终于找到解决办法了，采用 Div + CSS 进行三列或二列布局时，事先不知道具体高度，只能根据内容的增减自适应高度，要使两列（或三列）的高度相同，用 Table 很容易实现，但采用 Div + CSS 就显得比较麻烦了。按照一般的做法，大都采用背景图填充或 JS 脚本的方法使高度相同，但这些都不是最好的办法，我认为…

下面介绍采用“隐藏容器溢出”和“正内补丁”和“负外补丁”结合的方法

主要代码：

完整例子代码

//二进制转十进制
Console.WriteLine(Convert.ToInt32(”100111101″, 2));
//八进制转十进制
Console.WriteLine(Convert.ToInt32(”76″, 8));
//十六进制转十进制
Console.WriteLine(Convert.ToInt32(”FF”, 16));  

简介

幸运的是当编写一个典型的Windows 窗体程序时，窗体和控件的绘制、效果等操作是不需要特别加以考虑的。这是为什么呢？因为通过使用 .Net 框架，开发人员可以拖动一系列的控件到窗体上，并书写一些简单的与事件相关联的代码然后在IDE中按F5，一个完完全全的窗体程序就诞生了！所有控件都将自己绘制自己，窗体或者控件的大小和缩放都调整自如。在这里经常会用到的，且需要引起一点注意的就是控件效果。游戏，自定义图表控件以及屏幕保护程序的编写会需要程序员额外撰写用于响应 Paint 事件的代码。

本文针对那些Windows 窗体开发人员并有助于他们在应用程序编制过程中使用简单的绘图技术。首先，我们会讨论一些基本的绘图概念。到底谁在负责进行绘制操作？Windows 窗体程序是如何知道何时该进行绘制的？那些绘制代码究竟被放置在哪里？之后，还将介绍图像绘制的双重缓冲区技术，你将会看到它是怎样工作的，怎样通过一个方法来实现缓存和实际显示的图像间的交替。最后，我们将会探讨”智能无效区域”，实际就是仅仅重绘或者清除应用程序窗体上的无效部分，加快程序的显示和响应速度。希望这些概念和技术能够引导读者阅读完本文，并且有助于更快和更有效的开发Windows 窗体程序。

Windows 窗体使用GDI+图像引擎，在本文中的所有绘图代码都会涉及使用托管的.Net 框架来操纵和使用Windows GDI+图像引擎。

尽管本文用于基本的窗体绘图操作，但是它同样提供了快速的、有效的且有助于提高程序性能的技术和方法。所以，在通读本文之前建议读者对.Net框架有个基本的了解，包括Windows 窗体事件处理、简单的GDI+对象譬如Line，Pen和Brush等。熟悉Visual Basic .Net或者C#编程语言。

概念

Windows 应用程序是自己负责绘制的，当一个窗体”不干净”了，也就是说窗体改变了大小，或者部分被其它程序窗体遮盖，或者从最小化状态恢复时，程序都会收到需要绘制的信息。Windows把这种”不干净”状态称为”无效的(Invalidated)”状态，我们理解为：需要重绘，当Windows 窗体程序需要重绘窗体时它会从Windows消息队列中获取绘制的信息。这个信息经过.Net框架封装然后传递到窗体的 PaintBackground 和 Paint 事件中去，在上述事件中适当的书写专门用于绘制的代码即可。

上述代码分成两个基本的步骤来创建示例程序。首先 InitializeComponent 方法包含一些属性的设置和附加窗体 Paint 事件的处理过程。注意，在方法中控件的样式也同时被设置，设置控件的样式也是自定义Windows 窗体及控件行为的一种有效途径，譬如：控件的"ResizeRedraw"属性指示当窗体的大小变化发生以后需要对其完全进行重绘，也就是说重绘时总是需要对整个窗体的客户区域进行重绘。窗体的“客户区域”是指除了标题栏和边框的所有窗体区域。可以进行一个有趣的试验，取消该控件的属性然后再运行程序，我们可以很明显的看出为什么该属性会被经常的设置，因为窗体调整大小后的无效区域根本不会被重绘。

BasicX 示例程序的运行界面

双重缓冲区绘图技术

双重缓冲区技术能够使程序的绘图更加快速和平滑，有效减少绘制时的图像闪烁。该技术的基本原理是先将图像绘制到内存中的一块画布上，一旦所有的绘制操作都完成了，再将内存中的画布推到窗体的或者控件的表面将其显示出来。通过这种操作后的程序能使用户感觉其更加快速和美观。

下面提供的示例程序能够阐明双重缓冲区的概念和实现方法，这个示例所包含的功能已相当完整，且完全可以在实际应用中使用。在该章节后面还会提及该技术应该配合控件的一些属性设置才能达到更好的效果。

那么到底作怎么样的改动才能使上面的SpiderWeb程序实现简单的双重缓冲区技术呢？原理其实相当简单，就是将应该画到窗体表面的绘制操作改成先画到内存中的位图上，LineDrawRoutine向这个在内存中隐藏的画布执行同样的蜘蛛网绘制操作，等到绘制完毕再通过调用Graphics.DrawImage方法将隐藏的画布上内容推到窗体表面来显示出来，最后，再加上一些小的改动一个高性能的绘图窗体程序就完成了。

上面的示例代码创建了内存位图对象，它的大小等于窗体的客户区域(就是绘图表面)的大小，通过调用Graphics.FromImage将内存中位图的引用传递给Graphics对象，也就是说后面所有对该Graphics对象的操作实际上都是对内存中的位图进行操作的，该操作在C++中等同于将位图对象的指针复制给Graphics对象，两个对象使用的是同一块内存地址。现在Graphics对象表示的是屏幕后方的一块画布，而它在双重缓冲区技术中起到至关重要的作用。所有的线条绘制操作都已经针对于内存中的位图对象，下一步就通过调用DrawImage方法将该位图复制到窗体，蜘蛛网的线条就会立刻显示在窗体的绘制表面而且丝毫没有闪烁出现。