Using OI 4.1.3 on Win2000 Professional…

I disable a combo box. The background color and foreground colors automatically change (foreground color being the font). Uh ok, so I reset the background color, and there is no problem. Although, when I try to reset the foreground color it has no effect. This is all while the combo box is disabled. Once the combo box is enabled again both the background color and foreground color resets automatically just fine. Minor bother. Here is the code I am using.

FOCUS=@WINDOW:'.DETAIL'

BACKCOLOR=GET_PROPERTY(FOCUS,'BACKCOLOR')

FORECOLOR=GET_PROPERTY(FOCUS,'FORECOLOR')

RESULT=SET_PROPERTY(FOCUS,'ENABLED',0)

RESULT=SET_PROPERTY(FOCUS,'BACKCOLOR',BACKCOLOR)

RESULT=SET_PROPERTY(FOCUS,'FORECOLOR',FORECOLOR)

Richard,

So you want the disabled combo to keep its enabled appearance, with black text on white background?

What about making the combo read-only instead? Must confess I tried myself but failed. I couldn't get the normal way of setting controls read-only to work:

equ WM_USER$ to 1024 equ EM_SETREADONLY$ to WM_USER$ + 31 Handle=Get_Property( @Window : ".COMBO", "HANDLE" ) call SendMessage( Handle, EM_SETREADONLY$, true$, 0 )

But perhaps you got more luck. Sorry - knowledge.

- Oystein -

Thanks Oystein,

Good idea! I never thought of using "read only". HA!

I will play with it and let you know what results I get.

Richard,

I said I wasn't able to set combos programmatically to read-only. It seems I can't on other controls either (I tried an edit box). This is in 4.1.2. I seriously believed this stuff worked back in OI16.

I have used this technique a couple of places in my apps. Nothing critical, but it would be nice if it still worked in OI32. Please tell me how you get along.

Well now I'm assuming you need to change from normal to read-only at runtime, but I might have got that wrong. If you're fine with read-only from the start you shouldn't have any problems, since you can set it at design time.

On the other hand if you need to switch at runtime, and you get the same problem as me, I assume you could work around by having two versions of the control - one normal and one read-only, and show only one of them at a time.

- Oystein -

Oystein,

I also can not get the read only during runtime to work for combo boxes. I can change the background color, I just can not change the foreground color. I will just leave it as that for now.

I would expect that you would have to send the readonly message to the Edit control within the combobox, rather than the combo box itself. Remember that a combo box is just that - a control made up from a combination of components - in this case, an edit control, a list box, and sometimes a button.

We wrote an SENL article detailing this some time ago, though the code may need some tweaking for the 32-bit API.

The Sprezzatura Group

World Leaders in all things RevSoft

Sprezzatura,

Seems some tweaking also is necessary to get the readonly message to work with something as simple as an edit box. This worked in OI16 but not in 4.1.2.

The reason that I started using the readonly message back in OI16 is the following:

I had instances of an edit box bound to a data-heavy symbolic. The field being symbolic made the edit box disabled. Being disabled made the edit box unscrollable. The edit box being unscrollable made my users frustrated since they couldn't see all the data.

Setting the edit box to read-only at design time didn't help. It had to be done at runtime. And crucially - before programmatically setting the edit box read-only it had to be programmatically enabled (a fix I got from Gene Gleyzer). Here's the code I used:

$insert Logical
equ WM_USER$ To 1024
equ EM_SETREADONLY$ To WM_USER$ + 31
/* enable */
Void=Set_Property( @Window : ".EDITBOXBOUNDTOASYMBOLIC", "ENABLED", true$ )
/* set read-only */
hwndEdit=Get_Property( CtrlEntID : ".EDITBOXBOUNDTOASYMBOLIC", "HANDLE" )
call SendMessage( hwndEdit, EM_SETREADONLY$, true$, 0 )

But now in OI32 (at least in 4.1.2) the read-only message doesn't seem to work.

Luckily I've discovered setting read-only at design time now works in 4.1.2 - even in my case with the symbolic. So I'm in the clear.

But presumably Richard is not.

So on his behalf: Wizards to the rescue please!

- Oystein -

Correction to that code I used in OI16 - even if this code is meant to be in the CREATE handler using @Window or CtrlEntID might not make any difference.

$insert Logical
equ WM_USER$ To 1024
equ EM_SETREADONLY$ To WM_USER$ + 31
/* enable */
Void=Set_Property( @Window : ".EDITBOXBOUNDTOASYMBOLIC", "ENABLED", true$ )
/* set read-only */
hwndEdit=Get_Property( [b]@Window[/b] : ".EDITBOXBOUNDTOASYMBOLIC", "HANDLE" )
call SendMessage( hwndEdit, EM_SETREADONLY$, true$, 0 )

- Oystein -

Oystein,

equ EM_SETREADONLY$ to 0x00CF

And you should be fine. Don't add WM_USER$ to this value either :)

The Sprezzatura Group

World leaders in all things RevSoft

Sprezzatura,

Thanks!

- Oystein -

Encore - thanks, Sprezz

I'm sure I'm not alone in programmatically triggering all editables read-only for defined view-only users - or in other cases setting selected editables view-only for certain users.

Are there any more such post-3.x surprises in 4.0.x or 4.1.x which might need the Sprezz treatment?

Since last posting I've tried "Sprezzing my combos" with 0x00CF but it doesn't seem to work with 4.0.3 or 4.1.3.

The point was raised earlier that a combo is a combination of edit line, list box and button. In my case I do various things with the edit line and more particularly the buttton. Sometimes I use the button to "zoom" text notes to a larger overlay edit window. Sometimes I call a popup to select. Sometimes I use it for a normal list. Etc.

Hence I suggest the programmatical view-only event may need each element of the combo to be handled according to circumstance. For example, one may well wish to set the text read-only but enable the button. The consequence of the button (e.g. zoomed edit) may itself need to be aware of the parent prompt's read-only status.

Hence, for example, I set a flag, say, @READONLY for the combo box. A CHAR event restores GOTFOCUS_VALUE if this flag is set. Likewise the DROPDOWN event may also look at this flag to see what to do. This sort of technique isn't as subtle as using SendMessage but it's flexible and works!

Richard,

Do you remember I suggested you use two versions of the combo - one normal and one read-only, programmatically showing one and hiding the other? You might not like the idea. (Did I hear a groan?) But here's that idea with a twist: Use a read-only list box instead of a read-only combo. Reason: A read-only combo is sort of a contradiction since the user can't enter his own values in the edit line. A read-only list box would be more "honest". (Did I hear a louder groan?)

- Oystein -

Richard,

Works for me on OI4.1.3. You sure you're using the correct window handle for sendMessage()? Remember, you have to use the handle of the EDIT control within the Combobox, not the combo box handle itself.

Check the aforementioned SENL article to see what I mean.

The Sprezzatura Group

World leaders in all things RevSoft

Yes, you're spot on. But what a business to do something as simple and commonplace as just setting something readonly programmatically!

I'm sure I'm not the only person needing to do this!

Many thanks.

But what a business to do something as simple and commonplace as just setting something readonly programmatically!

Sheesh Richard, try VB for a while . You have no idea how insulated we are from the vagaries of programming the Windows API. At CeBIT the amount of VB programmers who couldn't believe just how easy it was to interface to the API was phenomenal.

To quote another developer on another forum

I am trying to make a readonly combo box. I figured the best way to do this was to sub class a combo box, add a "readonly" property and override the OnDropDown event. However, when I do this, the control does not appear properly unless I mess around with the sizing and also I don't know how to disable the control from dropping down.

The Sprezzatura Group

World Leaders in all things RevSoft

of course you could always create a promoted create event and if the control was called CtrlEntId_RO or similar make it read only automatically. No more programming ever

The Sprezzatura Group

World Leaders in all things RevSoft

View this thread on the forum...