document.getElementById("div1").innerText　这句脚本，怎么让它也支持这句脚本呢？

从网络拆抄了两种方法：

if(document.all){
　　 document.getElementById('element').innerText = "my text";
} else{
　　document.getElementById('element').textContent = "my text";
｝

这种方法比较简单明了。但有一点区别是textContent会包含不应有的HTML代码。

另一种方法是：

try{
        HTMLElement.prototype.__defineGetter__
        (
        "innerText",
        function ()
        {
            var anyString = "";
            var childS = this.childNodes;
            for(var i=0; i<childS.length; i++)
            {
                if(childS[i].nodeType==1)
                    anyString += childS[i].tagName=="BR" ? '"n' : childS[i].innerText;
                else if(childS[i].nodeType==3)
                    anyString += childS[i].nodeValue;
            }
            return anyString;
        }
    ); 
}
catch(e){}

这种方法我没有试过，你们不防可以试看看。问题总是的解决办法的，只要你有心。

using PDF = PDFMAKERAPILib;

   string wordPath = string.Empty;
        string pdfPath = string.Empty;

        PDF.PDFMakerApp app = new PDFMAKERAPILib.PDFMakerApp();
       int iReslut= app.CreatePDF(wordPath, pdfPath, PDF.PDFMakerSettings.kConvertAllPages, true, false, true, System.Type.Missing);
       if (iReslut == 0)
       {
           this.lblInfo.Text = "转换成功！";
       }
       else
       {
           //转换失败！
           this.lblInfo.Text = Enum.GetName(typeof(PDF.PDFMakerRetVals), iReslut);
       }

后来要求改变 必须用ASP.NET 来调用 心想，代码复制到Web窗体里面不就行了吗？
在用WebDev.WebServer.exe 时候 OK,没问题，当用IIS时，就是转换不成功，花了点时间，发现原因是两个的用户不同，一个是管理员，一个是Asp.net 帐户或者是network Service 看IIS是5.0 还是6.0。想通过更改设置权限来解决，改了不少，效果是从一个错误，变成了另一个错误！
后来从网上查资料，受了点启发：（我做COM测试的时候喜欢用VB.NET  代码简练。）

Imports Word = Microsoft.Office.Interop.Word
Imports PDF = ACRODISTXLib

  Dim Range As New Object()
        Range = Word.WdPrintOutRange.wdPrintAllDocument
        Dim Item As New Object()
        Item = Word.WdPrintOutItem.wdPrintDocumentContent
        Dim PageType As New Object()
        PageType = Word.WdPrintOutPages.wdPrintAllPages
        Dim ManualDuplexPrint As New Object()
        ManualDuplexPrint = False
        Dim OutPutFileName As String = "C:\Topdf\123456.ps"

        Dim wordApp As New Word.Application()
        wordApp.Documents.Open("C:\Topdf\123456.doc", False, False, False, "", "", False, "", "", Word.WdOpenFormat.wdOpenFormatAuto, , , , , , "")
        wordApp.Documents.Save()

        wordApp.ActivePrinter = "Adobe PDF"
      
        wordApp.PrintOut(False, , Range, OutPutFileName, , , Item, 1, "", PageType, False, True, "", , False, 0, 0, 0, 0)

        wordApp.Quit()

      

        Dim pdftest = New PDF.PdfDistiller()
        pdftest.bShowWindow = 0

        pdftest.FileToPDF(OutPutFileName, "C:\Topdf\123456.pdf", "")
        pdftest = Nothing
        ''连续调用会出错，可以先杀掉进程 

思路是先用Word 将doc 转换为ps,然后用pdfDistiller 将ps转换为pdf,经过测试，可以在IIS下成功执行。
在此将代码写出来，希望碰到此类问题的，能够少走些弯路！
当然，最好是不调COM,方法是找到了，就是要花钱，先这样用着吧！

转载：http://www.cnblogs.com/bit-sand/archive/2007/07/27/834148.html

今天突然有兴做了两下有关字符串为空的性能测试，与大家分享！结果如下：
两种赋值方式的比较：
string str="";
string str=string.Empty;
理论上讲：
string.Empty是一个Static的属性，使用时不分配存储空间，而在用""时，系统会分配一个长度为空的存储空间。不过编译系统应该会优化，也就是说，比如你程序中有10个地方用到了""，但好的编译系统应该引用的是同一个对象。所以用""也就是浪费一个对象空间而已。
实战：
测试程序如下：
namespace testEmpty
{
    class Program
    {
        static void Main(string[] args)
        {
            Test test = new Test();
            test.testEmpty();
            test.testEqualEmpty();
            Console.Read();
        }       
    }
    class Test
    {
        public void testEmpty()
        {
            string str;
            for (int i = 0; i < 10000; i++)
            {
                str = "";
            }
        }
        public void testEqualEmpty()
        {
            string str;
            for (int i = 0; i < 10000; i++)
            {
                str = string.Empty;
            }
        }
    }
}

 测试过程是分别将赋值语句str=""和str=string.Empty用两个函数执行10000次，所用时间如下所示：
    
所以说：单独执行testEmpty()执行10000次用了0.262669毫秒，单独执行testEqualEmpty()执行0.026849毫秒。前者是后者的10倍.

下面介绍的是几种判断语句的比较：
我想到的所有的判断空字符串的语句就这几种了，大家还有其它方法的欢迎讨论！
str == ""
str.Equals("")
str==string.Empty
str.Equals(string.Empty)
str .Length==0

测试程序如下：
using System;
using System.Collections.Generic;
using System.Text;

namespace testEmpty
{
    class Program
    {
        static void Main(string[] args)
        {
            Test test = new Test();
            test.test1();
            test.test2();
            test.test3();
            test.test4();
            test.test5();
            Console.Read();
        }       
    }
    class Test
    {
        string str = string.Empty;
        public void test1()
        {
            for (int i = 0; i < 10000; i++)
            {
                if (str == "")
                {
                    Console.WriteLine("1 This string is emput");
                }
            }
        }
        public void test2()
        {
            for (int i = 0; i < 10000; i++)
            {
                if (str.Equals(""))
                {
                    Console.WriteLine("2 This string is emput");
                }
            }
        }
        public void test3()
        {
            for (int i = 0; i < 10000; i++)
            {
                if (str==string.Empty)
                {
                    Console.WriteLine("3 This string is emput");
                }
            }
        }
        public void test4()
        {
            for (int i = 0; i < 10000; i++)
            {
                if (str.Equals(string.Empty))
                {
                    Console.WriteLine("4 This string is emput");
                }
            }
        }
        public void test5()
        {
            for (int i = 0; i < 10000; i++)
            {
                if (str .Length==0)
                {
                    Console.WriteLine("5 This string is emput");
                }
            }
        }
    }
}

在这个测试程序中，用了5个分别含有这5种判断语句的方法，目的就是为了测试每个方法耗费的时间。
在这里说明一下，笔者在这个程序中起的名字不可取，程序员不应该这样为方法起名字的，见笑了！
测试结果如下：

 呵呵，可以从这个方法耗费时间详细说明表中看出，这些方法耗费时间都比较，这主要是因为里面的Console.WriteLine()语句影响的。但是每个方法中都有这一语句，所以说它并不影响我们的比较结果！
得出的结论：在字符串为空时，这五种判断语句的耗费时间由短到长
str .Length==0
str.Equals("")
str==string.Empty
str.Equals(string.Empty)
str == ""
你平时有的哪种比较语句呢？呵呵……
需要说明的是：这只是在字符串为空时结果是这样的，那么字符串不为空时呢，结果又是怎样的呢？

转载：http://www.cnblogs.com/rijing2004/archive/2007/07/25/830654.html
有些朋友看到这个标题可能会有疑问，难道在视图中使用*符号还有何要注意的地方吗？对于这个问题，我们先不必回答，先看一下例子吧。

        我这里，使用的数据库是SqlServer2000自带的Northwind，这样方便大家自己私下里测试。首先，创建两个视图，视图的脚本如下：

--视图 vCustomersA
create view vCustomersA
as
select CustomerID ,CompanyName,ContactName,ContactTitle,
Address,City,Region,PostalCode,Country,Phone,Fax
from dbo.Customers
go
--视图 vCustomersB
create view vCustomersB
as
select * from vCustomersA
go

然后，使用这两个视图查询客户ID为ALFKI的资料，查询语句如下：

select * from vCustomersA where CustomerID = 'ALFKI'
select * from vCustomersB where CustomerID = 'ALFKI'

查询的结果如下：

一切正常，这个时候，需求发生了变化，我们需要改动vCustomersA，改动后的脚本如下：（为了说明问题，我们只是把CompanyName和ContactName互换一下位置）

--改动后的视图vCustomersA
alter view vCustomersA
as
select CustomerID ,ContactName,CompanyName,ContactTitle,
Address,City,Region,PostalCode,Country,Phone,Fax
from dbo.Customers
go

这个时候，当我们再次使用视图vCustomersB查询客户ID为ALFKI的资料的时候，错误已经悄然来临，你注意到了吗？让我们来看一下这两个视图的查询结果吧，查询语句如下：

select * from vCustomersA where CustomerID = 'ALFKI'
select * from vCustomersB where CustomerID = 'ALFKI'

查询的结果如下：

你注意到数据的异常了吗？使用视图vCustomersB查询的结果出现了错误，CompanyName显示的资料是：Maria Anders,而在视图vCustomersA查询的结果中CompanyName是：Alfreds Futterkiste。我们仅仅是在vCustomersA中互换了两个字段的位置，再次使用vCustomersB查询数据却发生了数据错位的现象，这是什么原因导致的呢？

       带着这个问题，让我们去了解一下，何谓视图？在Sql Server2000的帮助文档中是这样描述视图的，定义如下：“视图是一个虚拟表，其内容由查询定义，同真实的表一样，视图包含一系列带有名称的列和行数据。但是，视图并不在数据库中以存储的数据值集形式存在。行和列数据来自由定义视图的查询所引用的表，并且在引用视图时动态生成。”通过这个定义我们可以看出，视图是一个虚拟的表，它仅仅包括视图的定义脚本，查询的内容则是动态的生成。当我们创建了一个视图以后，视图的脚本会保存到当前数据库的系统表syscomments里，我们可以通过系统提供的存储过程：sp_helptext查询得到视图的定义脚本。从定义上看，好像并不能得到我们想要的答案，那么我们就先不管Sql Server2000是如何实现视图的，我们先来解决一下当前的问题（我上面提到的）。可能有些朋友已经知道了解决问题的办法了，那就是把vCustomersB的定义脚本重新执行一下（其实只需要把create换成alter执行一下就可以），脚本如下：

--重新执行一下vCustomersB的定义脚本
alter view vCustomersB
as
select * from vCustomersA
go

那么，除了这个方法以外，其实SqlServer2000也提供了一个扩展存储过程sp_refreshview来帮我们做这件事情，调用的脚本如下：

 

--刷新指定视图的元数据
exec sp_refreshview 'vCustomersB'

我个人目前就知道这两个办法，不知道，你还有没有其他的办法，有的话可以一起分享一下。

sp_refreshview的功能描述为：“刷新指定视图的元数据。由于视图所依赖的基础对象的更改，视图的持久元数据会过期。”由于sp_refreshview的代码被封装了（没有公开），所以我们看不到它的内部实现，不过看了这个存储过程的描述，你是否对视图有了新的认识呢？根据现有的迹象，我推测，视图的工作原理大致如下：

从这里，我们可以看到，当我们使用一个视图查询数据的时候，其实我们是在使用视图的元数据来查询的，当视图依赖的对象发生了变化以后，视图的元数据就需要更新，这样，使用视图时才不会违背我们的意愿。

       知道了问题的产生的原因后，那么我们在重新修改一个表或视图的脚本时，我们就需要更新依赖于该对象的视图，否则就会出现意想不到的错误。如何找到依赖于该对象的对象（包括视图，触发器，存储过程）呢？SqlServer2000在该数据库的系统表sysdepends里记录这些依赖关系，所以你可以查询该表获取你想要的信息，但其实，你可以通过使用系统提供的存储过程：sp_depends来获取该对象的所依赖的对象（返回的第一个表）以及依赖于该对象的对象（返回的第二个表），脚本如下：

 

--查询vCustomersA的依赖的对象以及依赖于vCustomersA的对象
exec sp_depends 'vCustomersA'

查询的结果如下图：

注：sp_depends的代码是公开的，有兴趣的可以看一下其实现过程。

       到此，你应该明白，当你更新你的表或视图的时候，你还要刷新依赖于这些对象的视图的元数据，即需要调用sp_refreshview来刷新依赖于该对象的视图。但是你在查询依赖于一个表或者视图的对象集合的时候需要注意的一点是，在你更新了一个表或视图之后，那些之前创建的依赖于该表或视图的依赖关系将会丢失（你更新的表或视图所依赖的对象集合不会丢失），用我之前的例子来看，vCustomersB依赖于vCustomersA，那么当我们修改了vCustomersA以后，vCustomersB与vCustomersA之间的依赖关系将会丢失而vCustomersA所依赖的Customers将不会丢失（依赖关系在对象创建或更新时创建，更新时，会把先前的依赖关系删掉）。（调用sp_depends你就可以看出来这种微妙的变化）

       希望在你阅读了本文以后，你在使用视图的时候会更加的得心应手，避免错误发生。文中有不对的地方欢迎指正批评！

转载：http://www.cnblogs.com/JeffreyZhao/archive/2007/01/18/Break_the_Browsers_Restrictions_1.html

我们已经知道，脚本文件的并行下载能够提高页面的加载速度。但是目前还有一个急需解决的问题，那就是对于FireFox浏览器的优化。在我们之前使用的优化方法，无论是简单实用的document.write还是食之无味的defer属性，FireFox浏览器都对此置若罔闻。不过FireFox也不是绝对地“冥顽不灵”，开发人员还是有方法对它进行优化的。

　　这个方法就是动态添加script元素。

动态添加script元素

　　不知道“动态添加script元素”这个说法是否正确，我在这里的意思是使用JavaScript编程，向<head />里添加script元素。下面的代码动态添加了5个script元素：

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server" id="head">
<title>Untitled Page</title>
<script type="text/javascript" language="javascript">
for (var i = 0; i < 5; i ++)
{
var script = document.createElement("script");
script.type = "text/javascript";
script.src = "Script.ashx?a=" + i;
document.getElementById('head').appendChild(script);
}
</script>
</head>
<body>
...
</body>
</html>

　　请注意，由于在JavaScript代码执行时页面还没有加载完毕，因此还不能使用document.getElementsByTagName方法来获得head元素，我们只能为head元素添加一个id，并使用document.getElementById方法来获得它。打开这张页面，就会发现，无论是IE（图9）还是FireFox（图10）的元素加载都会发现优化的效果：

图9：IE中动态加载script元素效果

图10：FireFox中动态加载script元素效果

　　我们姑且不关心为什么FireFox中每个脚本文件会使用2.5秒进行加载，但是并行加载的效果切切实实的出现了！加上多域名，效果更明显。

　　细心的朋友不知道回想起什么了吗？没错，当年在ASP.NET AJAX某个版本中（我记得是Beta 1，有些模糊了）加载自定义脚本时使用了Sys.Application.queueScriptReference方法，它能够让脚本文件并行加载。但是由于接下来会谈到的几个问题，最终还是选择了传统的加载方式。不过ASP.NET AJAX还是细心地考虑到脚本加载的影响，ScriptManager和ScriptReference已经提供了LoadScriptsBeforeUI属性，我们现在就能够控制script元素是出现在UI之前还是之后了，我们可以影响性能但是无需“急用”的脚本放在所有UI的最后进行加载，以降低它对于性能的影响（这个是在刚发布的ASP.NET AJAX正式版中新增的功能，我在阅读代码时无意发现）。

　　再说句题外话，虽然这个脚本加载方法已经被取消了，但是功能依旧存在，因为UpdatePanel在Partial Rendering之后只能选择动态加载脚本文件。我们也能够自己使用这样的加载方式，然而这就超出了今天这篇文章讨论的范围。不过既然ASP.NET AJAX正式版已经发布了，我也能够放心的继续《深入Atlas系列》了。:)

动态添加script元素的缺陷

　　世界上很少有完美的事物。动态添加的script元素能够使IE和FireFox里都得到优化，它应该也会有些麻烦，否则为什么这个方法没有被推广呢？

　　而且事实上，动态添加script元素的做法是“优化难度”最高的方法。我现在就来一一列举这些“缺陷”：

1、无法阻碍页面加载

　　其实这个问题和在IE中使用defer属性遇到的问题相同。如果您需要在页面中直接使用脚本文件里定义的函数，就不能轻易使用这个做法。即使它的确能够优化页面的加载速度。

2、影响window.onload事件的触发

　　如果对于window.onload事件的处罚有所影响，但是这种影响能够在不同浏览器中得到统一倒也罢了，还相对容易处理一些。现在的问题就在于，在IE中，window.onload事件会在页面其它元素被加载完毕之后立即触发，而FireFox里的window.onload事件会等待动态添加的那些脚本文件也被加载完毕后才触发。虽然我们开发人员是伟大的，可是要兼容这两种情况依旧不是一件易如反掌的事情。

3、动态加载脚本的执行顺序

　　这一点才是最致命的。

　　虽然我们动态加载的script元素是有严格顺序的，但是浏览器可不一定这样认为。在FireFox中，脚本文件会按照它动态加载的script元素的顺序执行，而IE会根据脚本文件下载完毕的顺序执行。

　　那还得了？

那么为何称之为王道？

　　既然麻烦这么多，为什么还称之为“王道”？其实我们只要合理的使用这个方法，就能够大大提高页面的Perceived Performance。

　　可能在这里我需要重新定义一下“Perceived Performance”的概念。它的意思是“用户感受到的性能”。我们打开一个页面，例如Windows Live个人主页，会发现页面的框架都被加载了，但是每一个框架都是Loading状态。然后每一个模块陆陆续续地加载成功。

　　我们来想象一下这个场景。一个页面的所有内容（包括模块），需要20秒钟才能加载完毕。但是它用了10秒钟就显示出了模块的框架，在接下来10秒钟内每个模块慢慢的出现。还有一种情况，就是等待整整20秒才能看到页面。从用户角度来看，哪个性能比较高呢？

　　这个就是Perceived Performance的经典应用。从所谓的Web 2.0开始，Perceived Peformance的重要性可以说被提高到了一个前所未有的高度。

　　那么我们现在就用语言来简单描述一下应该如何实现这样的效果：

1. 首先，在页面上用传统方式（最好使用document.write）加载所需要的基础脚本以及所有的HTML，这时候所有的模块处于Loading状态。
2. 在window.onload事件被触发后，动态加载每个模块所需的脚本。我们只需要在IE浏览器中响应script元素的onload事件或者在其它浏览器中响应script元素的onreadystatechange事件，就可以捕捉脚本文件的加载情况。
3. 在上述事件的handler中，如果script元素的readyState为"complete"或"loaded"（script元素的readyState使用字符串表示），那么判断某个模块需要的脚本有没有加载完毕，如果完毕了，则显示那个模块的具体内容。

　　大体方式就是这样，逻辑非常简单，不过在编码上可能就会遇到一些问题。不过对于使用ASP.NET AJAX的开发人员可能就略有福气些了，因为ASP.NET AJAX内置就有动态添加脚本元素的机制，已经实现了很好的跨浏览器特性。它们能够稍稍便于我们的开发，有机会我将详细的介绍它们，并且和大家一起来设计和实现一个好用的脚本库。

　　我对于加载脚本文件的优化心得就只有这些了，不过我们还可以在其他方面进行优化。例如，AJAX应用里最常见的XMLHttpRequest对象，我们也可以有技巧地使用它。不过这些内容，就要等下次再和大家分享了。:)

转载：http://www.cnblogs.com/JeffreyZhao/archive/2007/01/18/Break_the_Browsers_Restrictions_1.html

最近在为某个人门户站点作优化。

　　从传统意义上来说，这个站点的各方面都属中规中矩。不过作为一个以客户端为中心的Web应用，其性能，尤其是它的感知性能（Perceived Performance），经常会严重受制于浏览器本身。一个没有对客户端数据访问模型经过精心设计和优化的应用，其导致的结果往往就是无法充分利用带宽，让用户等待的时间变长。换句话说，其Perceived Performance需要进一步的提高。

　　突破浏览器限制，充分利用带宽，提高性能，尤其是Perceived Performance等等，就是我这次优化的目的。在接下来的几篇文章里，我将以数据说话，探讨浏览器的限制，并从多个方面来谈一下这次优化的各种方式。由于该个人门户使用了ASP.NET AJAX进行开发，因此我也将会给出一些基于ASP.NET AJAX的解决方案，希望会有一定参考价值，对朋友们能有所帮助。

工具

　　本着实事求是的原则，我们需要使用数据来说话，于是我们也就需要一些好用的工具。它们可以帮助我们统计各种数据，以便我们进行分析和优化。

　　在IE中，我们需要使用Http Watch这个工具来统计页面中每个请求的信息，例如开始时间，持续长度等等，能够轻松得出详细的数据（图1），非常好用。而且对于我们来说，一个Free Edition已经足够使用了。Free Edition虽然无法得到每次请求的所有信息，但是我们已经有了再熟悉不过的Fiddler。我们完全可以通过那些数据使用Excel作出统计图表（图2），进行分析。

图1：访问http://www.google.com的统计数据

图2：使用Office 2007绘制的统计图表

　　在FireFox下面，我一开始使用的是Google Page Load Analyzer，但是发现使用起来实在不方便，它既无法向Http Watch一样得到详细的信息，以便我们作出统计图表；而它自动生成的示意图又非常难看，很难进行分析。后经人提醒，最新的FireBug也有类似的功能。装上一看，果然好用。虽然无法获得精确数据，但是它生成的示意图（图3）已经可以直接进行分析了。

图3：访问http://www.cnblogs.com时FireBug绘制的统计示意图

　　此外，为了在本地或局域网内模拟低网速的情况，我再推荐一款工具NetLimiter 2 Pro。它能够对于某个程序、进程甚至某个连接在访问网络时的带宽进行限制，无论是因特网、局域网还是本机（图4）。最后，例如IE Dev Toolbar等工具自然也是必备的，我们可以在需要的时候使用它们。

图4：使用NetLimiter 2 Pro限制IE的带宽 

　　有了上面这些工具，就可以开始我们的分析优化之旅了。