Have u succesfully changed the SSTAB backcolor ?

[si_the_geek]

Using End is a very bad idea - if you read the help for it, you will see that it basically says "Don't use this, what it does is intentionally crash your program!"

As you are using subclassing, crashing your program is so bad that it also causes VB to crash, and that is entirely expected.


There are a couple of articles about this in our Classic VB FAQs (in the FAQ forum, which is shown near the top of our home page).

First off, there is Why is using the 'End' statement (or VB's "stop" button) a bad idea?

Then for an explanation (and example code) for how you should be closing a form/program, see the article How should I close my form/program/class?

[nepalbinod]

regards @si_the_geek

Please read this

We recently came to know that this code was the culprit especially when run on a modal form.

I am known to the fact that "end" is an abnormal way of program termination. But due to so many unavoidable circumstances a program ends abnormally. I think you agree with me on this.

Provided I will not use the "end" statement, the program might still end abnormally. For your kind information, if there is disruption in network connectivity, the program will terminate. In such cases, the subclassing that is provided in this thread causes the program to become unresponsive. If program terminates throwing an error, it can be handled and error can be trapped.

My only concern for this code is that it freezes the software. I think the culprit is the code or subclassing itself.

I googled and have been to so many forums but all none of the solution really worked out. What do you think on this, can it be resolved?


Cheers.

Using End is a very bad idea - if you read the help for it, you will see that it basically says "Don't use this, what it does is intentionally crash your program!"

As you are using subclassing, crashing your program is so bad that it also causes VB to crash, and that is entirely expected.


There are a couple of articles about this in our Classic VB FAQs (in the FAQ forum, which is shown near the top of our home page).

First off, there is Why is using the 'End' statement (or VB's "stop" button) a bad idea?

Then for an explanation (and example code) for how you should be closing a form/program, see the article How should I close my form/program/class?

[si_the_geek]

Why would network issues cause your program to terminate abnormally?

I can understand why it would cause an error (which as you rightly say can be trapped, and then dealt with gracefully), but am having trouble thinking how it could terminate your program outside of your control.

But due to so many unavoidable circumstances a program ends abnormally. I think you agree with me on this.

I'm afraid I don't... in over 10 years of writing VB6 programs, I've yet to find a situation where abnormal termination couldn't be avoided.

[nepalbinod]

Why would network issues cause your program to terminate abnormally?

I can understand why it would cause an error (which as you rightly say can be trapped, and then dealt with gracefully), but am having trouble thinking how it could terminate your program outside of your control.

I'm afraid I don't... in over 10 years of writing VB6 programs, I've yet to find a situation where abnormal termination couldn't be avoided.

As developing some sort of database application, I preimagine some conditions that would cause an error and then implement some sort of error handling. In our case, while in the development phase, error handling is done step by step. I will explain you my situation now.

I used this subclassing with SSTAB on a new form on which I preliminarily designed the form and did some coding.

For my convenience:
A. I generally test new forms by directly specifying them as startup form,
B. but later on that would be run as a modal form.

On Case A
It was okay.

On Case B
Since this form was still on 'test', I had an encounter with some sort of errors (may network disconnection, or whatever). For your kind information, now the entire project was unresponsive and I could not do anything but end the process VB6.exe via TM. The harm was done and I had to start from the scratch.



Findings:

In other cases where subclassing is not used, error is shown whenever there is an error and the runtime terminates happily and is returned to the project.


Justification

Case 1

• Please download the project I uploaded in the previous post.
• Make Form1 as startup object.
• Press F5. Click the button 'End Program' on Form1.

Case 2

• Please download the project I uploaded in the previous post.
• By Default, Form2 is startup object.
• Goto Command1_Click Event on Form2 and change 'Form1.Show 1' to 'Form1.Show'
• Press F5. Click the button 'Show Form1' on Form2.
• Press F5. Click the button 'End Program' on Form1.

Case 3

• Please download the project I uploaded in the previous post.
• By Default, Form2 is startup object.
• Press F5. Click the button 'Show Form1' on Form2.
• Press F5. Click the button 'End Program' on Form1.

Case 1 & Case 2
The program terminates gracefully and you return to the project.

Case 3
The entire project freezes because this subclassing only affects modal forms.


Questions/Concerns

• Please do not explain that 'End' is ........ Why does Visual Basic halt on Case 3 only, Why Not on Case 1 or 2 ?
• Is this a bug of 'Visual Basic' or 'subclassing code' provided here?
• Is there anybody there who can optimize this code?

[si_the_geek]

As developing some sort of database application, I preimagine some conditions that would cause an error and then implement some sort of error handling. In our case, while in the development phase, error handling is done step by step.

Error handling should not be an after-thought, it should be added while the code is being written, and extended later to deal with specific errors if needed.

In many cases, simply calling a generic error handling sub is enough - and if you use something like MZTools you only need to press a button to add complete error handling to a routine. I posted a brief example here.

On Case B
Since this form was still on 'test', I had an encounter with some sort of errors (may network disconnection, or whatever). For your kind information, now the entire project was unresponsive and I could not do anything but end the process VB6.exe via TM. The harm was done and I had to start from the scratch.

That is entirely expected, because you didn't handle the error.

You have two choices of what to do - you can either handle errors in all routines that might need it, or don't do the subclassing while running the code in VB.

Please do not explain that 'End' is ........ Why does Visual Basic halt on Case 3 only, Why Not on Case 1 or 2 ?

An error where there is no error handling is almost identical behaviour to using End.

Either of those things will cause a crash, and probably some sort of damage. The difference with subclassing is that the damage is immediately obvious to you (with databases you are likely to cause locking issues and/or corruption, which you may not realise you caused).

If you wouldn't use End, it is hard to justify leaving out error handling.

Is this a bug of 'Visual Basic' or 'subclassing code' provided here?

No, it is a lack of understanding on your part.

Subclassing works by getting Windows to send messages to your code - and when your program exits abnormally, the code does not exist any more, but the messages are still being sent (because you 'forgot' to say stop).

While running in VB, this leads to memory corruption within VB that it cannot handle, thus the crash. While running as an executable, Windows intercepts the memory corruption that you are trying to cause.

Is there anybody there who can optimize this code?

Optimise? Possibly, but that does not seem to be what you want - it sounds like you want to stop crashes that happen because you can't be bothered to handle the errors.

[nepalbinod]

Error handling should not be an after-thought, it should be added while the code is being written, and extended later to deal with specific errors if needed.

Please read this carefully.

As developing some sort of database application, I preimagine some conditions that would cause an error and then implement some sort of error handling. In our case, while in the development phase, error handling is done step by step.

In many cases, simply calling a generic error handling sub is enough - and if you use something like MZTools you only need to press a button to add complete error handling to a routine. I posted a brief example here.

That is entirely expected, because you didn't handle the error.

Despite of being a very novice programmer, I know how to use errorhandling in sub procedures.

You have two choices of what to do - you can either handle errors in all routines that might need it, or don't do the subclassing while running the code in VB.

Please explain me how to handle the entire errors on cases when work is still in progress and I am using subclassing, as well?

An error where there is no error handling is almost identical behaviour to using End.

Please explain what is that.

2Subclassing works by getting Windows to send messages to your code - and when your program exits abnormally, the code does not exist any more, but the messages are still being sent (because you 'forgot' to say stop).

Does your explanation apply to the all cases that I have mentioned or simply Case 3 only?

Optimise? Possibly, but that does not seem to be what you want - it sounds like you want to stop crashes that happen because you can't be bothered to handle the errors.

I admit. Provided I really am not bothered to handle the errors, why this happens only in Case 3? Why not in Case 1 and Case 2.

If you wouldn't use End, it is hard to justify leaving out error handling.
No, it is a lack of understanding on your part.

Since this is a forum for VB developers where we share knowledge. I am here to increase my understanding abilities where guys like you help me out.

[si_the_geek]

Please read this carefully.

I have again, and my advice still stands.

In some cases (like when a database connection fails) you will want to perform some specific action(s), but in others the errors should still be handled in some way (eg: by showing a generic error message).

Please explain me how to handle the entire errors on cases when work is still in progress and I am using subclassing, as well?

If you are handling errors (in whatever way you want), you should be fine.

If you aren't handling the errors, don't subclass - disable it until you are handling errors.

Please explain what is that.

An unhandled error has basically the same effect as End - it forces your program to exit without tidying up as needed (which is important even during development).

Does your explanation apply to the all cases that I have mentioned or simply Case 3 only?

It applies to subclassing in general.

I admit. Provided I really am not bothered to handle the errors, why this happens only in Case 3? Why not in Case 1 and Case 2.

I haven't analysed the cases in detail, as that would take time that I would otherwise be using to answer questions.

Any abnormal termination (ie: crashing your program) while subclassing is likely to crash VB - so if you have any risk of abnormal termination and don't want VB to crash, don't subclass.

Since this is a forum for VB developers where we share knowledge. I am here to increase my understanding abilities where guys like you help me out.

Absolutely, and I'm happy to pass on what I've learnt.