CwComboBox

[jackiezachman]

VA Smalltalk 7.5, Windows XP OS:

I'm using WBPro to design a window layout. I place a CwComboBox on the window. The default background color for this widget is White - which is what I want. I save the window, then edit it, then save it again. Now, suddenly, the background color for my CwComboBox is no longer white - it is the color returned by the #background class method in OSWidget (OS getSysColor: ColorBtnface).

I have found I can solve the problem if I change the OSComboBox #background class method from this:

Code: Select all

background
   "Answer the default background color for instances of the recevier."
   IsWin95 ifTrue: [^OS getSysColor: ColorWindow].
   ^super background

to this:

Code: Select all

background
   "Answer the default background color for instances of the recevier."
   Is95Shell ifTrue: [^OS getSysColor: ColorWindow].
   ^super background

(IsWin95 was changed to Is95Shell.) I hesitate to do this because the change is in WindowPlatformWidgets. Is this a bug? Is this an appropriate solution?

[tc]

Hello,

I tried what you had written and got the same behavior. Your fix worked as well. I opened an internal case with the information you posted. I am hesitant to just change it without support considering the consequences of a change. For example, there may be users who want the widget to operate that way.

For your situation, if the widget is giving you the behavior you need then version the app and use it. I do not see any problem with your change.

In the method 'WindowsPlatformFramework 'class>>#_PRAGMA_PlatformGlobals', 'IsWin95' and 'Is95Shell' are defined as:

(name: IsWin95 isConstant: false comment: 'True if Windows 95, 98, ME')
(name: Is95Shell isConstant: false comment: 'True if Windows 95, 98, ME, NT 4.0, 2000, XP, etc.')

. . . as you can see, 'Is95Shell' includes a lot more platforms.

--tc

[jackiezachman]

Thanks for the information. I will make the change in my own version. The only difficulty with this is that when I upgrade to the next version of Smalltalk, I need to keep track of my 'in-house' changes like this and make the same change on the next version. But at least it will work for now.

I'm curious as to why one would use IsWin95 vs. Is95Shell. If you check out the #background class method of OSWidget and it's subclasses, both are used in different places but with no indication why.

[rjs]

I will make the change in my own version. The only difficulty with this is that when I upgrade to the next version of Smalltalk, I need to keep track of my 'in-house' changes like this and make the same change on the next version. But at least it will work for now.

Why not create a subclass with your change, and perhaps a subclass of AbtComboBox to reference the new CW subclass?

[tc]

The only difficulty with this is that when I upgrade to the next version of Smalltalk, I need to keep track of my 'in-house' changes like this and make the same change on the next version.

Keep any modified apps in a config map. All the base stuff is loaded then load the changes to the base apps (ie load the 'Base Changes' config map). When you work with a new version of ST, export the 'Base Changes' config map to the new repository and 'Browse Changes'.

Browse changes can be done at the config map level, appllication level, or class level (and method). One way to handle it is to create a 'base changes' config map in the new ST and release the current applications to it. Version that. Then there are two CM versions, one CM with the original apps and another CM with the apps that were exported (that have your changes). Select those two CM versions and browse changes.

In general, there should not be that much change in an app, if at all.

Why not create a subclass with your change, and perhaps a subclass of AbtComboBox to reference the new CW subclass?

If you create a subclass then at the WindowBuilder level, you will always have to remember to use the new combo box class. I think I would tend to keep things easy at the WB level, ie no subclass.

--tc

[wembley]

This is a bug and it will be fixed in V8 (case 37444 -- fixed in V8.0.0). Testing Is95Shell is the correct change.