7,785
社区成员
发帖
与我相关
我的任务
分享vb6----的确有点傻。。。。。。。。？
我的程序运行中都没报错，似乎一切正常。
可是，全部退出后，跟踪到form_unload的最后一句，也正常，但是最后vb6自己内部扫尾时，自己把自己崩溃了，最后报那个什么 violation .... read 0... 错误。
这样一搞，也没法调试。。。。。。。。问题好难找。。。。。
(当然问题可能还是程序中什么东西违规了。)
可是，全部退出后，跟踪到form_unload的最后一句，也正常，但是最后vb6自己内部扫尾时，自己把自己崩溃了，最后报那个什么 violation .... read 0... 错误。
这样一搞，也没法调试。。。。。。。。问题好难找。。。。。
(当然问题可能还是程序中什么东西违规了。)
...全文
请发表友善的回复…
发表回复
waaoo 2012-04-25
- 打赏
- 举报
技术问题何必人身攻击
ah_2046 2012-04-22
- 打赏
- 举报
msubClassText.UnHook
这句话的问题，我也试了，只要出错就会退出，这个好像没办法，VB6就这样。
这句话的问题，我也试了，只要出错就会退出，这个好像没办法，VB6就这样。
东方之珠 2012-04-22
- 打赏
- 举报
[Quote=引用 24 楼 的回复:]
引用 22 楼 的回复:
引用 13 楼 的回复:
引用 12 楼 的回复:
释放对象、卸载子类化一定要在Unload之前处理完毕，最好不要在Unload中进行处理。
你把我说糊涂了，楼上几位也是。
我以前一直是这样用的，没有问题。。。。。。。。。。
你的图像浏览器做得那么好，怎么在这些小问题上处理不好呢？要不就用SEH处理Win32异常:
http://topic.cs……
[/Quote]
那个本身就是2个类模块,你做成DLL是可以的.
引用 22 楼 的回复:
引用 13 楼 的回复:
引用 12 楼 的回复:
释放对象、卸载子类化一定要在Unload之前处理完毕，最好不要在Unload中进行处理。
你把我说糊涂了，楼上几位也是。
我以前一直是这样用的，没有问题。。。。。。。。。。
你的图像浏览器做得那么好，怎么在这些小问题上处理不好呢？要不就用SEH处理Win32异常:
http://topic.cs……
[/Quote]
那个本身就是2个类模块,你做成DLL是可以的.
嗷嗷叫的老马 2012-04-22
- 打赏
- 举报
技术问题何必人身攻击.
PctGL 2012-04-22
- 打赏
- 举报
把你的子类化代码类贴出来看看
舉杯邀明月 2012-04-21
- 打赏
- 举报
看来只有象你那样的高手才能遇到这种高深莫测的问题。
-_-!!!
-_-!!!
啊的发哦 2012-04-20
- 打赏
- 举报
这都什么人啊，生活中估计也是凡事都是别人的问题!
看了看代码，写的挺脑残的
看了看代码，写的挺脑残的
dafu2003 2012-04-20
- 打赏
- 举报
[Quote=引用 30 楼 的回复:]
引用 29 楼 的回复:
引用 27 楼 的回复:
这都什么人啊，生活中估计也是凡事都是别人的问题!
看了看代码，写的挺脑残的
SB，你不懂就不要在这胡说八道，我的问题已经解决了。
你看看这篇文章吧。
Basic Forms of Madness
Visual Basic is an enigma. Pitched at inexperienced progr……
[/Quote]
一看你就是一傻逼，纯属找骂。
你真有本事，就给老子说出个所以然来。
对你这号人，老子懒得理你了。
引用 29 楼 的回复:
引用 27 楼 的回复:
这都什么人啊，生活中估计也是凡事都是别人的问题!
看了看代码，写的挺脑残的
SB，你不懂就不要在这胡说八道，我的问题已经解决了。
你看看这篇文章吧。
Basic Forms of Madness
Visual Basic is an enigma. Pitched at inexperienced progr……
[/Quote]
一看你就是一傻逼，纯属找骂。
你真有本事，就给老子说出个所以然来。
对你这号人，老子懒得理你了。
啊的发哦 2012-04-20
- 打赏
- 举报
[Quote=引用 29 楼 的回复:]
引用 27 楼 的回复:
这都什么人啊，生活中估计也是凡事都是别人的问题!
看了看代码，写的挺脑残的
SB，你不懂就不要在这胡说八道，我的问题已经解决了。
你看看这篇文章吧。
Basic Forms of Madness
Visual Basic is an enigma. Pitched at inexperienced program……
[/Quote]
问题解决了也是脑残一枚，你的代码扫一眼就知道是脑残，找问题的方式更脑残
引用 27 楼 的回复:
这都什么人啊，生活中估计也是凡事都是别人的问题!
看了看代码，写的挺脑残的
SB，你不懂就不要在这胡说八道，我的问题已经解决了。
你看看这篇文章吧。
Basic Forms of Madness
Visual Basic is an enigma. Pitched at inexperienced program……
[/Quote]
问题解决了也是脑残一枚，你的代码扫一眼就知道是脑残，找问题的方式更脑残
dafu2003 2012-04-20
- 打赏
- 举报
[Quote=引用 27 楼 的回复:]
这都什么人啊，生活中估计也是凡事都是别人的问题!
看了看代码，写的挺脑残的
[/Quote]
SB，你不懂就不要在这胡说八道，我的问题已经解决了。
你看看这篇文章吧。
Basic Forms of Madness
Visual Basic is an enigma. Pitched at inexperienced programmers, its
evolution as a programming language has been slow, yet each new
version ships with an overwhelming array of new plug-in technology
for data access and component building. On the one hand we're
expected to build increasingly sophisticated distributed
applications, but on the other hand we're not allowed to get too
technical. VB's rudimentary code editor pegs it as a tool for the
new breed of tinkertoy developer, yet language features aimed at
getting novices started simply get in the way of developers who have
accumulated enough experience to do anything useful. One such
example is the behaviour of forms, which we'll look at in detail
here.
Forms are essentially classes - 'essentially', because they're also
a little bit more than classes. We can mostly use a form anywhere we
can use a class (see Chapter 1 for some exceptions), but obviously a
form can have visible attributes too. It doesn't have to be visible:
for example, we might use a form in place of a regular class module
because we need a class that uses a timer control. When working with
forms we also need to appreciate that the visual part of a form can
be in a 'loaded' or 'unloaded' state; as we'll see, most of the
problems with forms revolve around these two states.
If, as is the case with classes, we were compelled to define
instances of our forms before using them, one of the most confusing
form issues would cease to be an issue. This would mean that we'd
always need code like this to use any form in our program:
Dim oMyForm As New Form1
oMyForm.Show vbModal
Unfortunately, whether or not we define any instances of a form,
Visual Basic creates one for us. We reference this object via an
implicitly-defined global variable that has the same name as the
class. That last sentence deserves to be printed in bold in Chapter
1 (or perhaps Chapter 6!) of every Visual Basic book and to be
taught on the first morning of every Visual Basic training course,
since it explains unambiguously why we can use the identifier
'Form1' to mean two entirely different things in two different
contexts:
Form1.Show ' Form1 is an object name
Dim oNewForm As New Form1 ' Form1 is a class name
Sadly, VB books and programming courses almost inevitably teach
programmers to use VB's implicitly-defined forms without explaining
what's going on. Creating explicit instances of forms is usually
taught as a minor 'advanced' topic, to be glossed over hurriedly
when MDI applications are considered. The unfortunate consequence is
that many intermediate and 'advanced' VB programmers just don't
understand what they're doing. You can program without ever touching
VB's implicitly-defined forms, and I suggest that you do (see
Chapter 1 if you need to be persuaded).
To have a full understanding of forms we need to know about the
different states a form can exist in. To do that, first we need to
look at the different ways in which class instances are created.
With classes things are relatively simple: our class instance
(object) either exists or it doesn't. When it comes into existence,
the Class_Initialize event handler runs, and when it is destroyed,
the Class_Terminate event handler runs. There's also an issue of
when the object is actually created, which differs according to how
we write the code:
Dim oMyObj As CMyClass ' (1)
Set oMyObj = New CMyClass ' (2)
oMyObj.SomeProperty = 2 ' (3)
or
Dim oMyObj as New CMyClass ' (4)
oMyObj.SomeProperty = 2 ' (5)
In the first example, the object is actually created at line (2). By
'actually created' we mean that the object has memory allocated and
its Class_Initialize event handler runs. This is fairly intuitive,
as Line (1) is a simple variable definition and not an executable
statement. Most importantly, we can say unambiguously that the
object has been created and initialized by line (3) - effectively we
can consider the Set statement as a call to the Class_Initialize
event handler.
By contrast, in the second example the object isn't created until
line (5), which is the first reference to any property or method -
most certainly NOT intuitive! In a real application, of course, the
first reference may be pages away from the variable definition and
such references are very likely to be added and deleted throughout
the development of the program. As a result, there is no line we can
point to and say with certainty that it creates the object. This may
。。。。。。。。。
a Form_Load
event. (To convince yourself of this, check out the following
example program.)
Example Code:
Auto-instantiated Form
For this example you need two forms. Form1 has two command
buttons, and you should paste the following code into the
forms. The buttons load and unload an instance of Form2, which
clicking on Form1's background displays Form2's caption. The
beeps just tell you when the Form_Load and Form_Unload events
are executed.
Note that the the variable f, an instance of Form2, is NOT
auto-instantiated - this object remains in existence during
the lifetime of Form1. Despite this, the visual part of Form2
(an anonymous object created from the Form interface) IS
auto-instantiated, since we can manipulate it (though 'it' is
really a new object) even after the form is unloaded.
Form1
Private f As Form2
Private Sub Command1_Click()
Load f
f.Caption = "hello"
f.Show
End Sub
Private Sub Command2_Click()
Unload f
End Sub
Private Sub Form_Click()
MsgBox f.Caption
End Sub
Private Sub Form_Load()
Set f = New Form2
End Sub
。。。。。。。。。。。。。
quality software.
这都什么人啊，生活中估计也是凡事都是别人的问题!
看了看代码，写的挺脑残的
[/Quote]
SB，你不懂就不要在这胡说八道，我的问题已经解决了。
你看看这篇文章吧。
Basic Forms of Madness
Visual Basic is an enigma. Pitched at inexperienced programmers, its
evolution as a programming language has been slow, yet each new
version ships with an overwhelming array of new plug-in technology
for data access and component building. On the one hand we're
expected to build increasingly sophisticated distributed
applications, but on the other hand we're not allowed to get too
technical. VB's rudimentary code editor pegs it as a tool for the
new breed of tinkertoy developer, yet language features aimed at
getting novices started simply get in the way of developers who have
accumulated enough experience to do anything useful. One such
example is the behaviour of forms, which we'll look at in detail
here.
Forms are essentially classes - 'essentially', because they're also
a little bit more than classes. We can mostly use a form anywhere we
can use a class (see Chapter 1 for some exceptions), but obviously a
form can have visible attributes too. It doesn't have to be visible:
for example, we might use a form in place of a regular class module
because we need a class that uses a timer control. When working with
forms we also need to appreciate that the visual part of a form can
be in a 'loaded' or 'unloaded' state; as we'll see, most of the
problems with forms revolve around these two states.
If, as is the case with classes, we were compelled to define
instances of our forms before using them, one of the most confusing
form issues would cease to be an issue. This would mean that we'd
always need code like this to use any form in our program:
Dim oMyForm As New Form1
oMyForm.Show vbModal
Unfortunately, whether or not we define any instances of a form,
Visual Basic creates one for us. We reference this object via an
implicitly-defined global variable that has the same name as the
class. That last sentence deserves to be printed in bold in Chapter
1 (or perhaps Chapter 6!) of every Visual Basic book and to be
taught on the first morning of every Visual Basic training course,
since it explains unambiguously why we can use the identifier
'Form1' to mean two entirely different things in two different
contexts:
Form1.Show ' Form1 is an object name
Dim oNewForm As New Form1 ' Form1 is a class name
Sadly, VB books and programming courses almost inevitably teach
programmers to use VB's implicitly-defined forms without explaining
what's going on. Creating explicit instances of forms is usually
taught as a minor 'advanced' topic, to be glossed over hurriedly
when MDI applications are considered. The unfortunate consequence is
that many intermediate and 'advanced' VB programmers just don't
understand what they're doing. You can program without ever touching
VB's implicitly-defined forms, and I suggest that you do (see
Chapter 1 if you need to be persuaded).
To have a full understanding of forms we need to know about the
different states a form can exist in. To do that, first we need to
look at the different ways in which class instances are created.
With classes things are relatively simple: our class instance
(object) either exists or it doesn't. When it comes into existence,
the Class_Initialize event handler runs, and when it is destroyed,
the Class_Terminate event handler runs. There's also an issue of
when the object is actually created, which differs according to how
we write the code:
Dim oMyObj As CMyClass ' (1)
Set oMyObj = New CMyClass ' (2)
oMyObj.SomeProperty = 2 ' (3)
or
Dim oMyObj as New CMyClass ' (4)
oMyObj.SomeProperty = 2 ' (5)
In the first example, the object is actually created at line (2). By
'actually created' we mean that the object has memory allocated and
its Class_Initialize event handler runs. This is fairly intuitive,
as Line (1) is a simple variable definition and not an executable
statement. Most importantly, we can say unambiguously that the
object has been created and initialized by line (3) - effectively we
can consider the Set statement as a call to the Class_Initialize
event handler.
By contrast, in the second example the object isn't created until
line (5), which is the first reference to any property or method -
most certainly NOT intuitive! In a real application, of course, the
first reference may be pages away from the variable definition and
such references are very likely to be added and deleted throughout
the development of the program. As a result, there is no line we can
point to and say with certainty that it creates the object. This may
。。。。。。。。。
a Form_Load
event. (To convince yourself of this, check out the following
example program.)
Example Code:
Auto-instantiated Form
For this example you need two forms. Form1 has two command
buttons, and you should paste the following code into the
forms. The buttons load and unload an instance of Form2, which
clicking on Form1's background displays Form2's caption. The
beeps just tell you when the Form_Load and Form_Unload events
are executed.
Note that the the variable f, an instance of Form2, is NOT
auto-instantiated - this object remains in existence during
the lifetime of Form1. Despite this, the visual part of Form2
(an anonymous object created from the Form interface) IS
auto-instantiated, since we can manipulate it (though 'it' is
really a new object) even after the form is unloaded.
Form1
Private f As Form2
Private Sub Command1_Click()
Load f
f.Caption = "hello"
f.Show
End Sub
Private Sub Command2_Click()
Unload f
End Sub
Private Sub Form_Click()
MsgBox f.Caption
End Sub
Private Sub Form_Load()
Set f = New Form2
End Sub
。。。。。。。。。。。。。
quality software.
无·法 2012-04-20
- 打赏
- 举报
[Quote=引用 11 楼 的回复:]
VB 的基础开发属于傻瓜式的，这都用不好，等级在傻瓜以下了！
[/Quote]说的很有道理。
VB 的基础开发属于傻瓜式的，这都用不好，等级在傻瓜以下了！
[/Quote]说的很有道理。
lliai 2012-04-19
- 打赏
- 举报
多半是你自己程序的问题。
dafu2003 2012-04-18
- 打赏
- 举报
[Quote=引用 22 楼 的回复:]
引用 13 楼 的回复:
引用 12 楼 的回复:
释放对象、卸载子类化一定要在Unload之前处理完毕，最好不要在Unload中进行处理。
你把我说糊涂了，楼上几位也是。
我以前一直是这样用的，没有问题。。。。。。。。。。
你的图像浏览器做得那么好，怎么在这些小问题上处理不好呢？要不就用SEH处理Win32异常:
http://topic.csdn.net/u/20110……
[/Quote]
看了下，本项研究一下，但是你的包里没看到那个dll文件，没法用。
引用 13 楼 的回复:
引用 12 楼 的回复:
释放对象、卸载子类化一定要在Unload之前处理完毕，最好不要在Unload中进行处理。
你把我说糊涂了，楼上几位也是。
我以前一直是这样用的，没有问题。。。。。。。。。。
你的图像浏览器做得那么好，怎么在这些小问题上处理不好呢？要不就用SEH处理Win32异常:
http://topic.csdn.net/u/20110……
[/Quote]
看了下，本项研究一下，但是你的包里没看到那个dll文件，没法用。
PctGL 2012-04-18
- 打赏
- 举报
[Quote=引用 13 楼 的回复:]
引用 12 楼 的回复:
释放对象、卸载子类化一定要在Unload之前处理完毕，最好不要在Unload中进行处理。
你把我说糊涂了，楼上几位也是。
我以前一直是这样用的，没有问题。。。。。。。。。。
[/Quote]
没问题，不释放都没问题（就是不写.unhook），只要不拦截关闭消息
不过我有些好奇你的那个子类化的类
引用 12 楼 的回复:
释放对象、卸载子类化一定要在Unload之前处理完毕，最好不要在Unload中进行处理。
你把我说糊涂了，楼上几位也是。
我以前一直是这样用的，没有问题。。。。。。。。。。
[/Quote]
没问题，不释放都没问题（就是不写.unhook），只要不拦截关闭消息
不过我有些好奇你的那个子类化的类
东方之珠 2012-04-18
- 打赏
- 举报
[Quote=引用 13 楼 的回复:]
引用 12 楼 的回复:
释放对象、卸载子类化一定要在Unload之前处理完毕，最好不要在Unload中进行处理。
你把我说糊涂了，楼上几位也是。
我以前一直是这样用的，没有问题。。。。。。。。。。
[/Quote]
你的图像浏览器做得那么好，怎么在这些小问题上处理不好呢？要不就用SEH处理Win32异常:
http://topic.csdn.net/u/20110329/10/78f7baa9-d526-4a6f-8e23-6141d9bb76d3.html
引用 12 楼 的回复:
释放对象、卸载子类化一定要在Unload之前处理完毕，最好不要在Unload中进行处理。
你把我说糊涂了，楼上几位也是。
我以前一直是这样用的，没有问题。。。。。。。。。。
[/Quote]
你的图像浏览器做得那么好，怎么在这些小问题上处理不好呢？要不就用SEH处理Win32异常:
http://topic.csdn.net/u/20110329/10/78f7baa9-d526-4a6f-8e23-6141d9bb76d3.html
zhouleyiman 2012-04-18
- 打赏
- 举报
VB尽量不用unload函数，除非你只用做关闭该form。unload函数不能返回任何值的，因为该form已经没了，不在内存中。如果你返回值，此时会出现VB异常错误，该错误也没什么信息。
ttsffgg 2012-04-17
- 打赏
- 举报
根据我处理你说的一样问题的经验,就如chenjl1031所说,释放对象、卸载子类化一定要在Unload之前处理完毕，最好不要在Unload中进行处理。
贝隆 2012-04-17
- 打赏
- 举报
淡定来看看，淡定的离开。
worldy 2012-04-17
- 打赏
- 举报
on error Resume Next
是一个隐藏错误的好方法，除非一些控件或类或API调用不能产生错误外，你的错误都可以使用on error Resume Next来隐藏，当然，隐藏了错误后你当然也得不到正确的结果。
使用Hook，Unhook是另一个容易造成崩溃的原因，即使你说的类没有问题，但是，再你的代码中如果遇到没有处理的错误，也有可能造成崩溃，因为子类化后，一般就不能进入VB的Debug。
是一个隐藏错误的好方法，除非一些控件或类或API调用不能产生错误外，你的错误都可以使用on error Resume Next来隐藏，当然，隐藏了错误后你当然也得不到正确的结果。
使用Hook，Unhook是另一个容易造成崩溃的原因，即使你说的类没有问题，但是，再你的代码中如果遇到没有处理的错误，也有可能造成崩溃，因为子类化后，一般就不能进入VB的Debug。
dafu2003 2012-04-17
- 打赏
- 举报
[Quote=引用 15 楼 的回复:]
汗，用了 on error Resume Next ，它还报什么错！！！
你说的“我的程序运行中都没报错，似乎一切正常。”，实际上可能就根本就不正常。
[/Quote]
改为on error goto ...是一样的，后面的语句都执行了的。
汗，用了 on error Resume Next ，它还报什么错！！！
你说的“我的程序运行中都没报错，似乎一切正常。”，实际上可能就根本就不正常。
[/Quote]
改为on error goto ...是一样的，后面的语句都执行了的。
加载更多回复（17）
