VB6和.NET中，Excel 空值的区别造成的转换问题

Question

本帖最后由 yiko628 于 2014-07-08 09:53:07 编辑

Answer 1

在C#中，判断一下是否是null就是了。
比如： if (!object.Equals(null, yourobj))
            {            }

Answer 2

这样做的话，我要在所有可能是空值的地方都做判断的吧。要改的太多了。其实总结我的帖子的意思就是，当等式是作字符串运算的话，等式中Excel的空值返回空字符；当等式是作数值运算的话，等式中的Excel空值返回0。

Answer 3

if(null == oYourObj || string.IsNullOrEmpty(oYourObj.ToString()) return;或者继续你的操作

Answer 4

现在在.net中如果一个表达式 worksheet.Cells(row,column) +100,其中单元格是Noting的话，就直接报错了。

Answer 5

我猜测可能是由于VB6和.net底层处理的机制不同造成的。VB6在数值运算的时候当Object是null的话则视作为0，字符运算的时候视作空字符。而.net则有更高的安全性所以才不这么做。但如果我要让.net实现类似VB6的功能，该怎么做？

Answer 6

几十万行的读写语句，我头都大了，但是为什么不用VB6制作一个ADD-IN插件呢。
真是无语了。

Answer 7

可以说我也头大了，起初这个程序是一个外行写的，所以不专业，我的理解：他把Excel当作了 数据库、变量和列表 来使用了。所以导致非常多的Excel读写语句。至于不写Add-in，这是个WinForm程序，Excel只是程序的一部分，你想这个程序员所有数据的存储，临时变量的存储都用Excel，怎么可能不庞大~要我改他所有的Excel，我自问是没有这么大的耐心以及完全不出错的信心。

Answer 8

可以说我也头大了，起初这个程序是一个外行写的，所以不专业，我的理解：他把Excel当作了 数据库、变量和列表 来使用了。所以导致非常多的Excel读写语句。至于不写Add-in，这是个WinForm程序，Excel只是程序的一部分，你想这个程序员所有数据的存储，临时变量的存储都用Excel，怎么可能不庞大~要我改他所有的Excel，我自问是没有这么大的耐心以及完全不出错的信心。
我移植过vb6到VB.NET.没你想的那么恼火。
代码直接拷贝过来都可以用，
需要修改的地方就是VB6里面可以直接使用某些参数，到了.NET里面你就必须换成别，需要手动翻资料。至于C#，哥们你就节哀吧。。

Answer 9

如果说对象在worksheet.cells(row,column)返回的是OBJECT，我猜他是后期绑定。
既然这样，转换为VB.Net的时候你需要弄成前期绑定。

Answer 10

可以说我也头大了，起初这个程序是一个外行写的，所以不专业，我的理解：他把Excel当作了 数据库、变量和列表 来使用了。所以导致非常多的Excel读写语句。至于不写Add-in，这是个WinForm程序，Excel只是程序的一部分，你想这个程序员所有数据的存储，临时变量的存储都用Excel，怎么可能不庞大~要我改他所有的Excel，我自问是没有这么大的耐心以及完全不出错的信心。
那个家伙真是个人才.
难道不能把读写EXCEL封装成函数,放到类里,哪里需要哪里调用么
我觉得你还是推翻重来算了,这样来回读写文件,也不怕出现不可预测的问题
比如该用变量存中间结果,不用,写到文件里,写错地方了,那整个全乱套.

Answer 11

EXCEL+VB  一般就是VBA 代码，不是真正的面向对象代码
C#是完全面向对象的语言两者之间还是有差异的，比如在空值的处理上建议VBA中对EXCEL处理下，用其它的特定的一个值来代替空值在C#中将特定值转换为空值

Answer 12

其实还有个办法，将你的VB6的代码复制到新的VB6 DLL文件中，然后使用.NET进行调用。这个是我能想到的最简单的办法了。不用移植任何代码到新的语言，用户也看不到有啥效果上的区别。