vb吧 关注：156,050贴子：1,166,194
不感兴趣
开通SVIP免广告
我遇到几个有点“莫名其妙的错误”，看老师有何解释。
说下其中的一个：
最近一段时间在弄的一个工具软件，在执行这个过程时，会出现如下图的错误提示。
这个错误在开初“代码规模比较小”时并没有出现，随着功能的扩展，后来就出现了。
这个错误只有在IDE下运行会产生，编译后的EXE程序运行完全正常。
最初的代码都是象上面粉红色框中的那句的格式：
直接把运算结果赋值给labPross.Width（Label控件的宽度属性）
PROSSBAR_WIDTH 是一个常量，Long类型。
后来出现“错误”后，尝试改变成各种形式的“运算”，都无法消除这个错误提示。
出现提示时，点“调试”，代码执行中断，停在上图中红色框中那样的“运算”语句上。
这时再按键盘“F5”，它又可以直接继续运行。
上面的运算中：是否使用CDbl()函数、pw用Double类型还是Single类型，结果一样。
并且，这其中又包含一个“奇特”的现象：
这个过程中并不是所有的这种语句都会“错误”，有一些“步骤”的计算它并不会提示出错。
我的这个过程，加载的“进度指示”共有下图中的“几个指示点”：
最左边一列是“宽度系数”，右边两列，是两处调用入口出现的不同状态。
虚线表示“xx * PROSSBAR_WIDTH”时没出现错误提示，×则表示出现错误提示。
比如0.05，后面两个标记都是虚线，表示两个调用入口中都不提示错误；
0.06 标记×和虚线各有一个，表示在调用入口1中引起错误，而入口2则没有错误；
0.1、0.2、0.3等等几个，两个标记都是×，表示两个调用入口中，它都提示错误。
还要注意一个重点：
这个“错误”几乎是不可“重现”的，如果我另外新建一个工程，
采用类似的方式写代码，却并不会出现提示，而是“一切正常”！
因此也别说我的VB6或操作系统有什么问题。
就事而事的说，pw = xxx * PROSSBAR_WIDTH这样的表达式，
应该是最基本的赋值运算了，哪来的“复杂”之说！比这复杂N倍的运算表达式多着呢！
另外，同一个过程中，“相同形式”的语句，却有一些提示出错而有一些则不出错！
无论哪一点，都是“很荒谬”的现象…………
说下其中的一个：
最近一段时间在弄的一个工具软件，在执行这个过程时，会出现如下图的错误提示。
这个错误在开初“代码规模比较小”时并没有出现，随着功能的扩展，后来就出现了。
这个错误只有在IDE下运行会产生，编译后的EXE程序运行完全正常。
最初的代码都是象上面粉红色框中的那句的格式：
直接把运算结果赋值给labPross.Width（Label控件的宽度属性）
PROSSBAR_WIDTH 是一个常量，Long类型。
后来出现“错误”后，尝试改变成各种形式的“运算”，都无法消除这个错误提示。
出现提示时，点“调试”，代码执行中断，停在上图中红色框中那样的“运算”语句上。
这时再按键盘“F5”，它又可以直接继续运行。
上面的运算中：是否使用CDbl()函数、pw用Double类型还是Single类型，结果一样。
并且，这其中又包含一个“奇特”的现象：
这个过程中并不是所有的这种语句都会“错误”，有一些“步骤”的计算它并不会提示出错。
我的这个过程，加载的“进度指示”共有下图中的“几个指示点”：
最左边一列是“宽度系数”，右边两列，是两处调用入口出现的不同状态。
虚线表示“xx * PROSSBAR_WIDTH”时没出现错误提示，×则表示出现错误提示。
比如0.05，后面两个标记都是虚线，表示两个调用入口中都不提示错误；
0.06 标记×和虚线各有一个，表示在调用入口1中引起错误，而入口2则没有错误；
0.1、0.2、0.3等等几个，两个标记都是×，表示两个调用入口中，它都提示错误。
还要注意一个重点：
这个“错误”几乎是不可“重现”的，如果我另外新建一个工程，
采用类似的方式写代码，却并不会出现提示，而是“一切正常”！
因此也别说我的VB6或操作系统有什么问题。
就事而事的说，pw = xxx * PROSSBAR_WIDTH这样的表达式，
应该是最基本的赋值运算了，哪来的“复杂”之说！比这复杂N倍的运算表达式多着呢！
另外，同一个过程中，“相同形式”的语句，却有一些提示出错而有一些则不出错！
无论哪一点，都是“很荒谬”的现象…………
不感兴趣
开通SVIP免广告
）
@涐吢铱舊囿儚
@cbm666
我查了一下msdn：
表达式过于复杂
浮点数计算表达式中允许书写的子表达式条数在不同平台下是不同的。举例而言，在32位的Windows操作系统上，浮点数表达式的子表达式被限制在8层以内。这种错误会这样出现，并且可以这样被解决：
出现情况：一个浮点数表达式包含了太多的嵌套子表达式。
解决方案：尽可能地将较长的浮点数表达式拆分为若干条较短的表达式来解决问题。
注意：早期版本的vb6不会出现这个问题，如果你有早期代码触发了此错误。建议你移除这些早期代码以避免错误发生。
分析：do loop循环内编译每个子表达式时做压栈处理，并为每个浮点数表达式及其子表达式分配存储空间。IDE内调试时，运行时库分析活动栈，累加浮点数存储空间。分析至栈低发现存储空间超界，报表达式过于复杂。又msdn提示较新版本vb才存在此情况，原因可能如下：vb6当初开发仅支持单线程。并不考虑多线程下的并发控制问题。于是多处的浮点数存储空间便使用覆盖较早的存储空间的方法加以解决。但是后来考虑到对ActiveX控件的更好支持—有些ActiveX控件可以异步调用，如果调用数据里存在被调着维护堆栈的情况则有可能破坏该vb6程序的执行序列。所以在浮点数存储空间超界的情况下报错。估计运行时库的存储空间动态维护，但不能超过某一最大值，所以出现海森堡现象。以上仅为我自己依靠原理的臆测，如果有闲来无事的调试高手能摸清真相，则感激不尽。
我建议是将循环中的某些表达式分解为函数并调用之。减小do loop循环体积。或者考虑用goto语句代之。
@cbm666
我查了一下msdn：
表达式过于复杂
浮点数计算表达式中允许书写的子表达式条数在不同平台下是不同的。举例而言，在32位的Windows操作系统上，浮点数表达式的子表达式被限制在8层以内。这种错误会这样出现，并且可以这样被解决：
出现情况：一个浮点数表达式包含了太多的嵌套子表达式。
解决方案：尽可能地将较长的浮点数表达式拆分为若干条较短的表达式来解决问题。
注意：早期版本的vb6不会出现这个问题，如果你有早期代码触发了此错误。建议你移除这些早期代码以避免错误发生。
分析：do loop循环内编译每个子表达式时做压栈处理，并为每个浮点数表达式及其子表达式分配存储空间。IDE内调试时，运行时库分析活动栈，累加浮点数存储空间。分析至栈低发现存储空间超界，报表达式过于复杂。又msdn提示较新版本vb才存在此情况，原因可能如下：vb6当初开发仅支持单线程。并不考虑多线程下的并发控制问题。于是多处的浮点数存储空间便使用覆盖较早的存储空间的方法加以解决。但是后来考虑到对ActiveX控件的更好支持—有些ActiveX控件可以异步调用，如果调用数据里存在被调着维护堆栈的情况则有可能破坏该vb6程序的执行序列。所以在浮点数存储空间超界的情况下报错。估计运行时库的存储空间动态维护，但不能超过某一最大值，所以出现海森堡现象。以上仅为我自己依靠原理的臆测，如果有闲来无事的调试高手能摸清真相，则感激不尽。
我建议是将循环中的某些表达式分解为函数并调用之。减小do loop循环体积。或者考虑用goto语句代之。
不感兴趣
开通SVIP免广告
