Keith...here is a little more for you.  You are right in that when the Multi-Column option is used, the static state that is rendered is rendered by us rather than the standard .NET rendering (only because we are performing an OwnerDraw) and you get this appearance when the combo is set as a DropDownList instead of a DropDown.  So, you can do several things....first, set the other combo to use multi-columns but only supply a single column...or change the DropDownStyle when the editing state of the BO changes..this, too, would make these render in the same fashion.  The combo rendering is going to get a makeover before long and I will make this that all states and settings render the same, but unfortunately we are still using the standard .NET combo rendering for most cases.  Hope this gets you going.

Keith,

OK...I think that there is one thing going on here...first of all, we DID make a change a while back to allow the textboxes to support a DisabledForeColor and DisabledBackColor...however, the ComboBox doesn't have this option yet as it is MUCH more difficult to manually render a combo without requiring Application Themes to be turned on....one thing that you can do is set teh IgnoreManageReadonly state to False on the combos and it should look as though it is enabled.

The reason the default enabled colors are more legible on the textboxes is due to the previous complaints that the standard disabled colors were too dark...now as for the difference between your product and style code combos...I don't know.  I have tried my very best to reproduce this per your instructions and I have not been able to.  To rework the way that the combo renders altogether by adding the DisabledFore and BackColor properties is not going to happen this go around...it is not a quick fix...so we need to figure some other way to get you going.  I hope that this might help...if not then I will have to look at your project to see and environment to see what else could be going on.

Here is the image I refer to above, forgot to attach

Keith Chisarik

Ok right now i am very frustrated. My customer is bugging me for a version delivery and I am looking at a lot of work if I cant figure out what is going on here.



Can you please confirm if the disabled behavior I am seeing is desired or a bug that I need to fix / get fixed.



In the attached image each control is disabled and each looks different.



If it is a bug, please advise how I might go at a fix, this is easily reproduceable in another form/project/solution and it acts the same way when deployed to a "clean install" in-house and also at customers site.



The issue did exist for me with the comboboxes before I installed the maintenance releases. It then started with the testboxes after installing the maintenance releases.



My forms look bad when disabled since they all render different colors and will be a a huge effort to manually update them all based on BO edit state.



Thank you.

Keith Chisarik

No...I beleive you, but even though a picture is worth a thousand words...I still have to get it in a reproducable state before I can fix it...you know what I am sayin'

Try loading VS2008 (you should go to it anyway as life is much nicer on this side of the fence ) and see if this project works.  We can then start working backwards from there.

What do you think it might be then Trent?



I attached the pic so you could see for yourself that I'm not dreaming



My forms look horrible.



Thanks.

Keith Chisarik

This is really up to you and depends on if you are having issues, etc.  As for going in order, no, just get the latest one.

Yes, you can develop against the 1.6.1.  We did not change the assembly version, just the file version, so this should work immediately after isntall (I had you in mind on this one )

Not really...however, the only real change is the solution and project files.  Really the best solution in this example would be to create a branch within your source control so you can alwasy get back to this exact version.  This is what we do for our medical software so if there is a bug or something in the field, we can go straight to that version, make the fix, then merge it back with the main branch.

I updated the sample....one combo has a multi-column and the other doesn't...same results.  I really don't think that this is a VS2005 or VS2008 thing as they are both compiled in .NET 2.0.

Example attached.



Left = multicolumn = False

Right = multicolumn = True





Besides that these controls are identical. As it is right now, I will have to write a method to override the colors based on BO state.




Keith Chisarik

Good stuff Greg, thanks. Ill mess around with that.

Keith Chisarik

Well now that I look more I think you intended things this way, with the text on disabled controls a darker color, but they aren't consistent. A disabled combo without multicolumn turned on has a forecolor that is light gray to match the control border and the dropdown arrow while a multicolumn dropdown has a forecolor that is much much darker, making it look enabled (in my opinion).



Well I was looking for an excuse to start my own control library anyhow



How come the disableForeColor property of a combo is available only in code and not the properties sheet?



The multicolumn dropdown in your example Trent works fine, perhaps this is a 2008 versus 2005 thing?



Reproduce by setting toggling multicolumn on and off, you will see that the disabledforecolor is different, at least in VS2005.



I am glad it no longer blows up

Keith Chisarik