Owner Draw of ComboBox Text & Items
AlanGLLoyd
some other text, in its Text display.
But I would like to colour the items in the list (and the Text if it is one of
those items) a certain colour, and any non-list text some other colour.
I have attempted to use OwnerDrawFixed, but find that the OnDrawItem event
handler is not called for drawing the Text unless it is one of the items in the
list, and so the contents of Text are never shown. So also attempting to draw a
different colour on the basis of the event handler Index parameter being -1 or
<> -1 does not work.
Any suggestions appreciated for how I might accomplish what I want to do.
Alan Lloyd
alang...@aol.com
Bjørge Sæther
news:20031121060149...@mb-m01.aol.com...
Set ComboBox.Font.Color to correspond to the current text of the combo
(OnChange event), and let the other items be drawn in OnDrawItem
--
Regards,
Bjørge Sæther
bjorge@haha_itte.no
-------------------------------------
I'll not spend any money on American Software products
until armed forces are out of Iraq.
AlanGLLoyd
<bjorge@hahaha_itte.no> writes:
>Set ComboBox.Font.Color to correspond to the current text of the combo
>(OnChange event), and let the other items be drawn in OnDrawItem
>
But the ComboBox.Text is never called to be drawn by the OnDraw event, nor is
the Text displayed with a Style of csOwnerDraw?????. That's the point of my
posting <g>.
Alan Lloyd
alang...@aol.com
Jeremy Collins
AFAICT once you set the style to csOwnerDraw, you are forced into having
a drop-down list, without the free-text portion like a drop-down combo.
You can't even set the Text programmatically.
The only answer I can think of is a custom control that combines a
TEdit and an owner draw list, (basically a faked combobox). This would
allow you to do something like:
procedure TMyCombo.OnDrawItem(Control: TWinControl; Index: Integer;
Rect: TRect; State: TOwnerDrawState);
begin
Canvas.FillRect(Rect);
if Items.IndexOf(FEdit.Text) = Index then begin
Canvas.Font.Color := clRed;
FEdit.Font.Color := clRed;
end
else begin
Canvas.Font.Color := clWindowText;
FEdit.Font.Color := clWindowText;
end;
Canvas.TextOut(Rect.Left, Rect.Top, Items[Index]);
end;
and something similar to set the TEdit's font colour in the
OnChange event, if the user-entered text exists in the list.
You could do it quick 'n' dirty by placing a borderless TEdit on top of
the combobox...
--
jc
Remove the -not from email
J French
Or roughly translated
There seems to be no event for drawing the Edit control that is 'part
of' the Combobox
Nasty little hybrids ...
Bruce Roberts
"AlanGLLoyd" <alang...@aol.com> wrote in message
news:20031121060149...@mb-m01.aol.com...
> I have a combobox which can display either one of the contents of its
list, or
> some other text, in its Text display.
>
> But I would like to colour the items in the list (and the Text if it is
one of
> those items) a certain colour, and any non-list text some other colour.
>
> I have attempted to use OwnerDrawFixed, but find that the OnDrawItem event
> handler is not called for drawing the Text unless it is one of the items
in the
> list, and so the contents of Text are never shown. So also attempting to
draw a
> different colour on the basis of the event handler Index parameter
being -1 or
> <> -1 does not work.
In D5 odComboBoxEdit will be in State when a list item is drawn in the text
area. When OwnerDrawFixed is set the only thing that can appear in Text is
an item taken from the list. So I'm slightly confused by what you are
saying.
AlanGLLoyd
<b...@bounceitattcanada.xnet> writes:
>When OwnerDrawFixed is set the only thing that can appear in Text is
>an item taken from the list.
That's the problem, I want text to appear which is _not_ in the list (as with
non-owner-drawn combobox), but I want it in a different colour from the list
colour.
Your statement does not appear anywhere I have read.
It appears to be not possible - at least it's something to know that <g>. While
it would be a usefully consistent GUI, it is not essential.
Thanks, everyone.
Alan Lloyd
alang...@aol.com
J French
I would ... cautiously say ... simulate
Put differently, I have never used a MS Combobox in my life
- but made things that look like them
Nasty little hybrids .....
Bruce Roberts
"J French" <ere...@nowhere.com> wrote in message
news:3fbe4d64...@news.btclick.com...
> Put differently, I have never used a MS Combobox in my life
> - but made things that look like them
Given that combo boxes use two handles, a number of more miserly combo type
controls are around. Perhaps torrys or dsp have something that could be
altered to suit. There is also the open source TurboPower Orpheus collection
(see source forge) which may something useable. (Although IIRC their combo
descends from tCustomComboBox. But they do have, IIRC, a button control that
can be associated with an edit.)
AlanGLLoyd
writes:
>I would ... cautiously say ... simulate
>
>Put differently, I have never used a MS Combobox in my life
>- but made things that look like them
>
As an exercise to see "what if" I have combined a TEdit, TBitBtn and a
TListBox. A bit tedious (lot of get/set methods to make available the
properties and methods of the elements), a bit kludgy I'm (not sure I'm really
encapsulating properly), but it does work as I want, except for a nasty focus
rectangle on the bit-button when the listbox is visible (anyone know how to get
rid of it ?).
>Nasty little hybrids .....
>
Do you mean the combination of edit and list - in which case that is what is
wanted for a nice GUI at times (like now for me). Or do you mean the way MS or
Delphi has implemented it ?
Alan Lloyd
alang...@aol.com
AlanGLLoyd
show only within the boundaries of the parent, any more is clipped. Yet a
TComboBox will show outside those boundaries, showing even outside the boundary
of the form.
Any suggestions for solving this ? I would be satisfied to show outside the
parent boundary but within the form (ie if the TCombinatonBox is on a TGroupBox
well inside a form).
Alan Lloyd
alang...@aol.com
J French
>In article <3fbe4d64...@news.btclick.com>, ere...@nowhere.com (J French)
>writes:
>
>>I would ... cautiously say ... simulate
>>
>>Put differently, I have never used a MS Combobox in my life
>>- but made things that look like them
>>
>As an exercise to see "what if" I have combined a TEdit, TBitBtn and a
>TListBox. A bit tedious (lot of get/set methods to make available the
>properties and methods of the elements), a bit kludgy I'm (not sure I'm really
>encapsulating properly), but it does work as I want, except for a nasty focus
>rectangle on the bit-button when the listbox is visible (anyone know how to get
>rid of it ?).
Try WM_KILLFOCUS
>
>>Nasty little hybrids .....
>>
>
>Do you mean the combination of edit and list - in which case that is what is
>wanted for a nice GUI at times (like now for me). Or do you mean the way MS or
>Delphi has implemented it ?
The way it is implemented
I too have had to resort to rolling my own alternatives
You might find the DrawFrameControl API rather interesting
DFCS_SCROLLDOWN Down arrow of scroll bar
>
>Alan Lloyd
>alang...@aol.com
J French
That is something I've never thought of
- in the past I've spent effort keeping Listboxes (neatly) within the
bounds of the container
Having just sniffed through things in TCustomCombobox and the Win32
Programmer's Refernce
- I've only one simple suggestion
- and you are not going to like it ...
Use a Combobox instead of a Listbox, but position it so that its Edit
bit is firmly covered by your own Edit control and 'drop button'
AlanGLLoyd
writes:
>Try WM_KILLFOCUS
>
Thanks, that does the trick.
>You might find the DrawFrameControl API rather interesting
>DFCS_SCROLLDOWN Down arrow of scroll bar
>
I presume one then has to catch the click of the TEdit to activate drop-down
and up ? Would this approach be advantageous.
At the moment I use a TBitBtn with Marlett font characters '6' and '5' for down
and up triangles.
Alan Lloyd
alang...@aol.com
J French
>In article <3fbf4ea9...@news.btclick.com>, ere...@nowhere.com (J French)
>writes:
>
>>Try WM_KILLFOCUS
>>
>Thanks, that does the trick.
>
>>You might find the DrawFrameControl API rather interesting
>>DFCS_SCROLLDOWN Down arrow of scroll bar
>>
>I presume one then has to catch the click of the TEdit to activate drop-down
>and up ? Would this approach be advantageous.
Well ... it is interesting to see that one can draw 'standard' bits of
complex Windows controls
- a long time ago I simulated them with Bitmaps
- the memory is ghastly
- when I saw the finished product on another colour scheme, I was so
embarrassed
>
>At the moment I use a TBitBtn with Marlett font characters '6' and '5' for down
>and up triangles.
It is probably worth looking at the Windows standard drawing stuff
- if nothing else for the future
- I once wrote a system where every control was simulated
... Windows is just a 'simulation' anyway
>
>Alan Lloyd
>alang...@aol.com
>
>
AlanGLLoyd
French) writes:
>Having just sniffed through things in TCustomCombobox and the Win32
>Programmer's Refernce
>
>- I've only one simple suggestion
>- and you are not going to like it ...
>
>Use a Combobox instead of a Listbox, but position it so that its Edit
>bit is firmly covered by your own Edit control and 'drop button'
>
I think I'd rather put the new combobox on the form but above the TGroupBox.
<g> I don't need it to go outside the form.
I just wonder how MS do it - fudge the ClipRect with an internal to MS call, or
change the window regn for the parent (and Parent.Parent etc).
Alan Lloyd
alang...@aol.com
AlanGLLoyd
French) writes:
>It is probably worth looking at the Windows standard drawing stuff
>
I thought that Marlett was the font that MS used to draw all those standard
bits and pieces. That's all the font has in it anyway.
Alan Lloyd
alang...@aol.com
J French
If MS use Marlett then ... I am a Pekin Duck
- not a chance - that stuff *has* to be embedded
J French
I suspect the dropdown Listbox is actually an independant window
Maarten Wiltink
I offer you as a data point that I don't seem to have Marlett at all...
But while it doesn't seem likely that it was supplied as the source
of all standard UI bits & bobs, it sounds quite plausible that it was
meant as _a_ source of standard UI bits & bobs, and that could come in
mighty handy in certain circumstances.
Groetjes,
Maarten Wiltink
AlanGLLoyd
<maa...@kittensandcats.net> writes:
>I offer you as a data point that I don't seem to have Marlett at all...
>
What MS OS are you using ? I'm using Win 98SE (upgraded from Win 95). It is a
long ago memory that I saw the statement that Marlett _was_ used as the source
- possibly with Win 95 (it has a MS copyright 1995 entry in the font file). It
would however make sense to change that to a bitmap resource or a drawn item as
MS moved on.
Alan Lloyd
alang...@aol.com
AlanGLLoyd
compiles and runs fine as a separate unit in an application which uses it. I
then attemptd to add it to the component palette, and it appeared to compile OK
into DCLUser30. And it appeared OK on a page of the component.
When I tried to use it, not only did the TEditListBox appear on the form, but
also the default component icon in a panel as though the component was a
non-visual component. Then when I tried to compile the form it had error
messages saying that it could not find the TEdit, the TBitBtn, and the TListBox
classes. Until I added one of each of these components from the default
component palette pages, it would not compile. The Object inspector also showed
one of these components but un-named, as well as a page for the TEditListBox.
Class declaration of the TEditListBox class is as follows :
TEditListBox = class(TComponent)
Edit: TEdit;
BitBtn: TBitBtn;
ListBox: TListBox;
private
{ Private declarations }
FLeft : integer;
FTop : integer;
FEditFontColor : TColor;
FListFontColor : TColor;
FParent : TWinControl;
procedure BitBtnClick(Sender: TObject);
procedure EditChange(Sender: TObject);
function GetItem(Index : Integer) : string;
function GetItems : TStrings;
function GetParent : TWinControl;
procedure ListBoxClick(Sender: TObject);
procedure SetEditFontColor(AValue : TColor);
procedure SetItem(Index : integer; AValue : string);
procedure SetItems(AValue : TStrings);
procedure SetLeft(AValue : integer);
procedure SetListFontColor(AValue : TColor);
procedure SetParent(AValue : TWinControl);
procedure SetTop(AValue : integer);
public
{ Public declarations }
constructor Create(AOwner : TComponent); override;
destructor Destroy; override;
property EditFontColor : TColor read FEditFontColor write SetEditFontColor;
property Item[Index : integer] : string read GetItem write SetItem;
property ListFontColor : TColor write SetListFontColor;
property Parent : TWinControl read GetParent write SetParent;
published
property Items : TStrings read GetItems write SetItems;
property Left : integer read FLeft write SetLeft;
property Top : integer read FTop write SetTop;
end;
All units for the TEdit, TBitBtn and TListBox objects are in the interface uses
clause.
Any suggestions please.
Alan Lloyd
alang...@aol.com
Maarten Wiltink
NT 5.0 Standard; with two versions of Word even.
The old Windows 98 directory has a Marlett dated 1998-05-11/19:01;
the other machine has NT 4 with one dated 1996-10-14/03:38. Both are
18 KB.
Both are also TrueType. I can imagine that this is a bit overkill
for drawing simple shapes on a canvas; on the other hand it's a nice
way of precomputing all the optimisations.
Groetjes,
Maarten Wiltink
AlanGLLoyd
French) writes:
>Use a Combobox instead of a Listbox, but position it so that its Edit
>bit is firmly covered by your own Edit control and 'drop button'
>
I've given up buggering about with a new TEditListBox component and I am using
a TEdit to cover the text part of a TComboBox (leaving the drop-down button of
the TComboBox visible and usable).
Works fine with minimal additional coding and complete control over the edit
box colours <g>.
Alan Lloyd
alang...@aol.com
J French
Probably the most pragmatic solution
I wondered about covering the 'drop button' and did a few tests
yesterday - not entirely satisfactory - if one squinted at it.
Bruce Roberts
> Any suggestions for solving this ? I would be satisfied to show outside
the
> parent boundary but within the form (ie if the TCombinatonBox is on a
TGroupBox
> well inside a form).
You need to override the CreateParams method. IIRC what you need is
something like
Params.Style := (Params.Style or ws_PopUp) and (not ws_Child);
Its been awhile, but my recollection is that this will allow for showing
outside the parent and form.
Bruce Roberts
> When I tried to use it, not only did the TEditListBox appear on the form,
but
> also the default component icon in a panel as though the component was a
> non-visual component. Then when I tried to compile the form it had error
> messages saying that it could not find the TEdit, the TBitBtn, and the
TListBox
> classes. Until I added one of each of these components from the default
> component palette pages, it would not compile. The Object inspector also
showed
> one of these components but un-named, as well as a page for the
TEditListBox.
>
> Class declaration of the TEditListBox class is as follows :
>
> TEditListBox = class(TComponent)
> Edit: TEdit;
> BitBtn: TBitBtn;
> ListBox: TListBox;
The sub-components shouldn't be published. You haven't said who is the Owner
of these, nor their Parent. In my experience streaming sub-components Owned
by the control is problematic. I typically either give up ownership to the
form, and hence only ever create them once (when the control is first
created) or hide the sub-components entirely from the streaming system. I
tend to prefer this later case, but it means keeping all of the properties
in the main control.
I think also that you will have to descend from at least tWinControl. IIRC
nothing higher will get focus or can group window controls.
I'd be tempted to descend from tPanel. And instead of a tBitBtn use a
tSpeedButton so that I don't have to worry about the button getting the
focus.
Nicolai Hansen
> Any suggestions please.
>
> Alan Lloyd
> alang...@aol.com
Isn't this where you are supposed to use frames?
/Nic
AlanGLLoyd
not did not make any difference).
After a while irritation with one's inability to do what one wants, overrides
one's desire for an elegant solution. And one does what works, as I did <g>.
Alan Lloyd
alang...@aol.com
AlanGLLoyd
(Nicolai Hansen) writes:
>Isn't this where you are supposed to use frames?
>
Maybe - if one has D5+ which I have not <g>.
Alan Lloyd
alang...@aol.com
J French
>In article <d96764ff.03112...@posting.google.com>, n...@aub.dk
>(Nicolai Hansen) writes:
>
>>Isn't this where you are supposed to use frames?
>>
>
>Maybe - if one has D5+ which I have not <g>.
Ah, so Frames came with D5
Does anyone know of a reference for them
- they would certainly tempt me to upgrade from D4
- if they do what I think they do
Nicolai Hansen
Then this is where one says, "oh, damn!" ;)
Bjørge Sæther
news:3fc5dfa0....@news.btclick.com...
> On 26 Nov 2003 17:24:21 GMT, alang...@aol.com (AlanGLLoyd) wrote:
>
> >In article <d96764ff.03112...@posting.google.com>, n...@aub.dk
> >(Nicolai Hansen) writes:
> >
> >>Isn't this where you are supposed to use frames?
> >>
> >
>
> Ah, so Frames came with D5
>
> Does anyone know of a reference for them
> - they would certainly tempt me to upgrade from D4
> - if they do what I think they do
They're "forms without forms", that is, you design like when creating a
form, only that the result is a component-like unit that needs to be
instantiated by placing it on a form. I guess it would be the ideal concept
for object editors, property editors, etc., when you want to make it part of
a form. IMHO it works better if you don't need to modify frames individually
after they're placed on the form.
They may also be converted into components. Never tried this myself, though.
I fell for this concept...but I've rarely used frames. Somewhat like form
inheritance, there is a problem with planning.
To utilize frames, you need to plan for this structure in advance.
It would be interesting to hear if other programmers have different
experience with this.
--
Regards,
Bjørge Sæther
bjorge@haha_itte.no
-------------------------------------
I'll not spend any money on American Software products
until armed forces are out of Iraq.
J French
I see, so in effect they are like VB UserControls
Do they have to go in the Component Pallette ?
One thing that really hacks me off with Delphi4 is that if I design a
visual component I cannot use it from the Pallette without adding it
to the Pallette for ALL programs.
IMO one should have a Pallette for the App
- perhaps there is some method, but I've not found it
To me, there should be a firm dividing line between Generic Library
routines, those that one has decided to make Generic, and those that
are App specific.
Thanks for the info
AlanGLLoyd
<bjorge@hahaha_itte.no> writes:
>They're "forms without forms", that is, you design like when creating a
>form, only that the result is a component-like unit that needs to be
>instantiated by placing it on a form. I guess it would be the ideal concept
>for object editors, property editors, etc., when you want to make it part of
>a form. IMHO it works better if you don't need to modify frames individually
>after they're placed on the form.
>
>They may also be converted into components. Never tried this myself, though.
>
>I fell for this concept...but I've rarely used frames. Somewhat like form
>inheritance, there is a problem with planning.
>To utilize frames, you need to plan for this structure in advance.
>
>It would be interesting to hear if other programmers have different
>experience with this.
>
Thanks, Bjorge, I've seen references to them but have not understood the
concept. They sound useful where (as I have recently) I have a certain
functionality for visual objects (like treeview, listview) but without the
objects themselves. This functionality is encapsulated in a TObject descendant
and can be used in more than one place. I then pass references to the visual
objects to the "functionality object" when or immediately after I instantiate
it.
It would seem I could use a frame for this.
Alan Lloyd
alang...@aol.com
Bjørge Sæther
news:20031127115336...@mb-m21.aol.com...
I've been thinking about using them for Object editors.
But there is something about developing a technique based on frames. They
may be seen as "RAD components", as they are much easier to build than
compound controls. OTOH, they don't encapsulate anything, they're more like
"visual macros".
Some of the same issues with form inheritance - it just won't do much good
if you don't *know* how to use it. It introduces OOP into form creation
again, but having get used to Delphi IDE design, this is not straightforward
at all. Especially events usage is critical: Scattering event handlers all
over the place creates a real spaghetti, this is bad enough with standard
forms. Some questions to answer before one starts:
- What would be standard functionality in all forms of this project ?
- Would it be convenient to have a common ancestor for all of them ?
Bjørge Sæther
> On Thu, 27 Nov 2003 13:01:26 ?, "Bjørge Sæther"
Yes and no. There is one common 'Frame' button in the component palette,
clicking this one opens a picker dialog containing all frame classes of the
project.
> One thing that really hacks me off with Delphi4 is that if I design a
> visual component I cannot use it from the Pallette without adding it
> to the Pallette for ALL programs.
Frames are project-specific.
> IMO one should have a Pallette for the App
> - perhaps there is some method, but I've not found it
Yes, one should be able to install e.g. two versions of a component in two
different projects.
- and there should be an option for "exporting" project with necessary
components.
> To me, there should be a firm dividing line between Generic Library
> routines, those that one has decided to make Generic, and those that
> are App specific.
Couldn't agree more.