Have u succesfully changed the SSTAB backcolor ?

Have u succesfully changed the SSTAB backcolor ?

When you are just changing the backcolor of the SSTAB, it will change only in the background area of the SStab which is not a developer wants.
Assume that u have 3 buttons in the SStab and you changed the back color of that. It will not be changing the faces of the SStab buttons (main area) and It will remain as same and you can see the changes only in the edges of the SStab.

Can any body give me solution or sample code for this.

Thanks in advance.
:wave:

We are not able to change the back color of the sstab it use the default windows color. But you can search some third party control for it.

I donot want to use third party tool.

Need to a solution from VB6 code itself

SStab has not any property for changing the back color, you can check your self. It use the windows default color you can do it only by changing the systems colors in control panel
Read This :wave:

It can be done with Subclassing, but I didn't know exactly how to subclass this control so i made this based on this MSFlexgrid Subclassing Submission to PSC made by a member of VBF:Link

It's nice to see that subclassing that way you can intercept WM_PAINT in many controls that can't access to it directly.

The version for SSTAB is attached. It shows 2 SSTABs , the first has a color as background and the other has a Picture. Each one needs its Picturebox to work.

Put an image or picture over each tab. Make it fit, fumble with the code. See if you can capture Picture1.click instead of the tab. Be creative!

Quote:

---

Originally Posted by jcis

It can be done with Subclassing, but I didn't know exactly how to subclass this control so i made this based on this MSFlexgrid Subclassing Submission to PSC made by a member of VBF:Link

It's nice to see that subclassing that way you can intercept WM_PAINT in many controls that can't access to it directly.

The version for SSTAB is attached. It shows 2 SSTABs , the first has a color as background and the other has a Picture. Each one needs its Picturebox to work.

---

Great One :thumb:

Hi
My SSTAB Backcolor and Picture Box Back Color Donot match

i.e; Noticiable diff in color

Quote:

---

Originally Posted by SREE432

Hi
My SSTAB Backcolor and Picture Box Back Color Donot match

---

Fixed and attached.

EDIT: mmm, it works but some 3d lines has gone, i would use the first code i attached, the backcolor is darker than the one in the picturebox because its melted with the default gray vb color (vbButtonFace) that the SSTab already has as Backcolor, but its not so bad, just change the color in the picturebox knowing that the result will be a little bit darker :)

I need the background color to be white (to imitate the Windows XP/Vista style)... Setting it to white does not work, any gray gets too dark.

This one does not help either because it paints the background (the part in the top right corner) with the color.

Quote:

---

Originally Posted by floppes

I need the background color to be white (to imitate the Windows XP/Vista style)... Setting it to white does not work, any gray gets too dark.
This one does not help either because it paints the background (the part in the top right corner) with the color.

---

Did you try the example in my last post? if you change the backcolor of the first Picturebox to White the first SSTab Backcolor will be White.

Edit: I see it doesn't looks good when using ssPropertypage Style with a White backcolor, this is because when using ssPropertypage style the Top and Left borders are already white, then they become invisible.

A little off-topic: does anyone know a tab control that applies the Windows XP and Vista theme?

I found great controls that work with the Windows XP/Vista theme at http://www.timosoft-software.de .

I have been using this code since one year.

http://www.vbforums.com/showthread.php?t=509087


Since our project was too big, we could not find out the cause that crashes our software. We recently came to know that this code was the culprit especially when run on a modal form.

I have attached a sample here.
http://www.vbforums.com/attachment.p...1&d=1234530800

If you click "End Program" on Form2, entire project crashes. Provided "End" is improper way of program termination, still it is troublesome. Please help...

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?

regards @si_the_geek

Please read this

Quote:

---

Originally Posted by nepalbinod

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. :thumb:

Quote:

---

Originally Posted by 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?

---

Why would network issues cause your program to terminate abnormally? :confused:

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.

Quote:

---

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.

Quote:

---

Originally Posted by si_the_geek

Why would network issues cause your program to terminate abnormally? :confused:

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?

Quote:

---

Originally Posted by nepalbinod

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

Originally Posted by si_the_geek

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.

Quote:

---

Originally Posted by nepalbinod

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.

---

Quote:

---

Originally Posted by si_the_geek

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.

Quote:

---

Originally Posted by si_the_geek

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?

Quote:

---

Originally Posted by si_the_geek

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

---

Please explain what is that.

Quote:

---

Originally Posted by si_the_geek

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?

Quote:

---

Originally Posted by si_the_geek

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.

Quote:

---

Originally Posted by si_the_geek

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.

:thumb:

Quote:

---

Originally Posted by nepalbinod

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).

Quote:

---

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.

Quote:

---

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).

Quote:

---

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

---

It applies to subclassing in general.

Quote:

---

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.

Quote:

---

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.
:thumb:

---

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

Quote:

---

Originally Posted by si_the_geek

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

---

:) In all three cases, the same code (subclassing) is used.

Explicitly in Case 3, as I have said before, the form (on which subclassing) is used (is run) as a modal form. This is the only case which causes VB to halt.

Please do analyze each cases and you will know what I am talking about.

I am concerned only with--why this happens on modal forms only. Waiting for your observation and explanation.

Cheers!

The issue is not caused by modal forms, the same often happens without them.

I would expect the other cases to have the problem too, and assume that reason they don't is due to the program flow etc, but it would be a waste of time to work out exactly why that is - as not only would it be inconclusive, but you are also extremely unlikely to replicate the same behaviour in a larger program.

Quote:

---

Originally Posted by si_the_geek

The issue is not caused by modal forms, the same often happens without them.

I would expect the other cases to have the problem too, and assume that reason they don't is due to the program flow etc, but it would be a waste of time to work out exactly why that is - as not only would it be inconclusive, but you are also extremely unlikely to replicate the same behaviour in a larger program.

---

Sorry my friend, the problem is only with modal forms. I have uploaded the proof. For heaven's sake, please do give it a try once and you will know what I am talking about.

It does not only happen with modal forms, it can happen with any form, and that is well known by people with experience of subclassing.

Despite your claim you have not actually given proof, but merely an example of being lucky - most of the time projects will crash. I've had it just this week with non-modal forms (in a test project for fancy tooltips).


I could probably work out why you got lucky in those cases, but what would be the point?

You can easily avoid the crashes anyway (either by not using subclassing within VB, or by using error handling), so it seems foolhardy to try to find a more complex way to avoid them - especially due to the analysis being inconclusive as I said before.

Quote:

---

Originally Posted by si_the_geek

Despite your claim you have not actually given proof, but merely an example of being lucky - most of the time projects will crash.

---

First of all, I uploaded an example that in non modal form it does not crash and in modal form it does. It is simply crystal clear, it's simply a case of a form being run as modal or non modal.

Quote:

---

Originally Posted by si_the_geek

I could probably work out why you got lucky in those cases, but what would be the point?

---

Yet again, I compromise. I apologize for claiming it to be a "proof" or whatever. I even do agree that I was lucky in this case.

It would have been beneficiary for me (or others who have/will came/come across this situation) to deal with the situation if I knew why and have tried to explain as much as I could. It's up to you whether or not you like to work out on why it happens.

But if you think that it is thoughtful to know the reason why, believe me, if you knew why, it would be justifiable.

Anyway, thanks for the help.
:wave:

The situation is similar to crossing the road blindfolded, and getting safely across roads A and B, but not road C.

Rather than focus on the similarities/differences of those three roads (and based on that trying to make assumptions about crossing any other road while blindfolded), it would make more sense to avoid the obvious risk - get rid of the blindfolds, or use a bridge over the road (or both).


I've explained why subclassing inside the VB IDE is prone to crashes, and given two ways to avoid the risk.

I don't see the point of spending lots of my free time analysing the cases you put forward - as not only is it unreliable to assume that the similarities/differences in those cases would apply elsewhere, but there are already easy (and well tested) ways to eliminate the risk.


If you want to keep on crossing the road blindfolded then feel free, but I would personally prefer to take the safer options, and recommend you do too.

well, i've succeeded in making it invisible, if that counts...

Code:

---

Option Explicit
Dim g_nTransparency As Integer
    Dim color As Long
    Dim flag As Byte

Private Sub cmdTranslucent_Click()
    color = RGB(240, 240, 240)
    flag = 0
    If chkColor.Value = 1 Then flag = flag Or LWA_COLORKEY
    If chkAlpha.Value = 1 Then flag = flag Or LWA_ALPHA
               
    g_nTransparency = txtTransparency.Text
    If g_nTransparency < 0 Then g_nTransparency = 0
    If g_nTransparency > 255 Then g_nTransparency = 255
    SetTranslucent Form2.hwnd, color, g_nTransparency, flag
    Exit Sub
End Sub

---

RGB(240, 240, 240) is the default form color.

My point of view is different.

Quote:

---

Originally Posted by si_the_geek

The situation is similar to crossing the road blindfolded, and getting safely across roads A and B, but not road C.

---

The probability of getting safely across any of these roads is 50%. You might cross roads safely, or you might not. If you take the risk repeatedly, you might not cross the road safely on any of the roads A, B, or C.

Quote:

---

Originally Posted by si_the_geek

If you want to keep on crossing the road blindfolded then feel free, but I would personally prefer to take the safer options, and recommend you do too.

---

In my example, you can attempt a one hundred million crosses, you will be on roads A & B safely, but you will not be able to cross road C.

Thanks for the recommendation, anyway. Programmatically, I can make my own 'sstab kinda thing' via other controls. But you know, sstab is a great control since it acts as a container and it's so easy to use and implement. The only thing it lacks is container-color.

Quote:

---

Originally Posted by Justa Lol

well, i've succeeded in making it invisible, if that counts...

Code:

---

Option Explicit
Dim g_nTransparency As Integer
    Dim color As Long
    Dim flag As Byte

Private Sub cmdTranslucent_Click()
    color = RGB(240, 240, 240)
    flag = 0
    If chkColor.Value = 1 Then flag = flag Or LWA_COLORKEY
    If chkAlpha.Value = 1 Then flag = flag Or LWA_ALPHA
               
    g_nTransparency = txtTransparency.Text
    If g_nTransparency < 0 Then g_nTransparency = 0
    If g_nTransparency > 255 Then g_nTransparency = 255
    SetTranslucent Form2.hwnd, color, g_nTransparency, flag
    Exit Sub
End Sub

---

RGB(240, 240, 240) is the default form color.

---

These constants are not defined:
LWA_COLORKEY
LWA_ALPHA

Actually, what does that do @Justa Lol ?

Quote:

---

Originally Posted by nepalbinod

My point of view is different.

---

Indeed, but your point of view is based on extremely limited and biased evidence, and goes against a huge wealth of experience on the subject from many highly respected VB developers.

Quote:

---

In my example, you can attempt a one hundred million crosses, you will be on roads A & B safely, but you will not be able to cross road C.

---

In those exact circumstances yes, but would it be the same if there was a reasonable change? for example:
...with some code in your forms?
...with a few extra controls on either of the forms?
...on another computer? (due to the extra ocx's etc, I didn't even get that far)
...with a different VB SP?
...while an unrelated (and compiled) VB6 program is running on the same computer?
...with a different version of Windows?

As a general rule of thumb, subclassing in the IDE will cause crashes in well over 90% of abnormal terminations.

Quote:

---

Thanks for the recommendation, anyway. Programmatically, I can make my own 'sstab kinda thing' via other controls. But you know, sstab is a great control since it acts as a container and it's so easy to use and implement. The only thing it lacks is container-color.

---

So why don't you use the SStab?

I have at no point implied that you should not use subclassing to achieve the extra feature - just that if you are going to subclass while running in the VB IDE, be careful.

Quote:

---

Originally Posted by nepalbinod

These constants are not defined:
LWA_COLORKEY
LWA_ALPHA

Actually, what does that do @Justa Lol ?

---

i forgot my modules... lol

well, it makes a color transparent

Quote:

---

Originally Posted by si_the_geek

Indeed, but your point of view is based on extremely limited and biased evidence, and goes against a huge wealth of experience on the subject from many highly respected VB developers.

---

I wholeheartedly respect others point of view, but can you please be more subjective.

Quote:

---

Originally Posted by si_the_geek

In those exact circumstances yes, but would it be the same if there was a reasonable change? for example:
...with some code in your forms?
...with a few extra controls on either of the forms?
...on another computer? (due to the extra ocx's etc, I didn't even get that far)
...with a different VB SP?
...while an unrelated (and compiled) VB6 program is running on the same computer?
...with a different version of Windows?

---

Please prove me wrong that 'end' + 'subclassing' will not crash in nonmodal forms.

Quote:

---

Originally Posted by si_the_geek

As a general rule of thumb, subclassing in the IDE will cause crashes in well over 90% of abnormal terminations.

---

I don't agree with you. What do you mean by 90% of abnormal terminations.?

I think there's something wrong with the 'subclassing code' or that is something related with the behavior of VB6 on modal forms.

Quote:

---

Originally Posted by si_the_geek

I have at no point implied that you should not use subclassing to achieve the extra feature - just that if you are going to subclass while running in the VB IDE, be careful.

---

Yes, I entirely do agree with you.

Quote:

---

Originally Posted by Justa Lol

i forgot my modules... lol

well, it makes a color transparent

---

It does not help change the container color of SSTab control. Anyway, thanks for the post. It will be useful on other cases.

Hello,

Just did a bit of search and I found a way to avoid crashes.

From the thread: http://www.vbforums.com/showthread.php?t=420617

Quote:

---

Originally Posted by jcis

Found this, seems much better. Example: you want to change Form2 from modal to modalness or vice versa, pass the Hwnd of the Parent Form to MakeModal Function:
In a module

VB Code:

Public Declare Function EnableWindow Lib "user32" (ByVal hwnd As Long, ByVal fEnable As Long) As Long
 
Public Enum MakeAsModal
    Modal = 0
    Modalless = 1
End Enum
 
Public Sub MakeModal(ByRef frmParent As Form, ByVal isModal As MakeAsModal)
    On Error Resume Next
    Dim RetVal As Long
    RetVal = EnableWindow(frmParent.hwnd, isModal)
End Sub

In Form1

VB Code:

Private Sub Command1_Click()
    Form2.Show
End Sub

In Form2

VB Code:

Private Sub Command1_Click()
    MakeModal Form1, Modal
End Sub
 
Private Sub Command2_Click()
    MakeModal Form1, Modalless
End Sub

Edit: It works, but you wont get the typical Flash window and "beep" that VB6 makes when clicking a Form without Focus, not sure about VBA.

---

If that works for you then great, but just be aware that it might not always avoid the crashes.

Quote:

---

Originally Posted by nepalbinod

I wholeheartedly respect others point of view, but can you please be more subjective.

---

You might not like what I said, but all three of your test cases were clearly based on very restricted conditions (such as no code in the forms, and others I listed), and therefore they are heavily biased.

You may not understand the reasons why, but those conditions can make a huge difference.

Quote:

---

Please prove me wrong that 'end' + 'subclassing' will not crash in nonmodal forms.


I don't agree with you. What do you mean by 90% of abnormal terminations.?

I think there's something wrong with the 'subclassing code' or that is something related with the behavior of VB6 on modal forms.

---

If you don't want to believe my advice (based on experience of hundreds of real-world cases of my own), which is echoed by thousands of other people with experience in this area, then that is your choice.

If you feel the need for proof, I'm afraid I will not spend my time creating it - you can find it yourself, whether that is an intentional process or not.

Quote:

---

Originally Posted by si_the_geek

If that works for you then great, but just be aware that it might not always avoid the crashes.

---

Error handling is an integral part of coding. I just needed a case where I could simulate errors and output understandable error messages for each individual cases. But when I worked with subclassing in modal forms, VB6 threw errors which was anticipated, but in return, it caused the IDE to crash and I was lost in the middle of nowhere.

The solution I found was making a nonmodal form behave as a modal form and believe me, now I can code along with the errors and deal with then specifically.

Quote:

---

Originally Posted by jcis

Fixed and attached.

EDIT: mmm, it works but some 3d lines has gone, i would use the first code i attached, the backcolor is darker than the one in the picturebox because its melted with the default gray vb color (vbButtonFace) that the SSTab already has as Backcolor, but its not so bad, just change the color in the picturebox knowing that the result will be a little bit darker :)

---

Thanks much.. It works.