|
You have two choices:
- Subclass the edit control.
- Handle the EN_UPDATE notification in the edit control's parent.
Steve
|
|
|
|
|
will u be able to explain a little more.?
|
|
|
|
|
Chandrasekharanp wrote: will u be able to explain a little more.?
search sublass here at CP, you will get answer to yo
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
ThatsAlok wrote: search sublass here at CP, you will get answer to yo
And for more explain google is a option.;)
|
|
|
|
|
Hamid. wrote: And for more explain google is a option.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Adding to the answer already given... You can change the size with SetWindowPos(...)
Greetings.
--------
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
One way to do this is to change the size of the editbox dynamically using SetWindowPos() API.
Use this API in WM_CHAR or EN_CHANGE notification. like below.
INT Widht =0;
INT Height = 10
case WM_CHAR: ( or EN_CHAGE)
SetWindowPos(hWndEdit,0,X,Y,Height,Width++);
break;
above code will work. But you need to take care when to grow the editbox and when to shrink it. ( i.e if someone press backspace or delete the editbox should shrink. )
|
|
|
|
|
Hi Developers,
I have to write a map class in C++.I know there is one stl map class in C++ but i have to write my own which should be as good as stl map class.
So how should i get started ? Is there any example program which could be helpful to me to get on with it ?
ta
James
|
|
|
|
|
Why not just look at the stl map source code?
|
|
|
|
|
Maybe because it is almost undecypherable ? 
|
|
|
|
|
Cedric Moonen wrote: Maybe because it is almost undecypherable
sometimes i fails to understand the code of STL, though i am amid STL Lover. i feel it's is so optimized, that only compiler could understand. 
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Hi,
I have a custom class derived from MFC CListCtrl. I create one list control that uses my derived class and has two columns.
Now the problem is, I'm coloring each cell differently using NM_CUSTOMDRAW and I need the color to "save" on each cell so that when a cell is redrawn after being initially colored, its color will remain the same.
I can use SetItemData to set the color for an entire row, but I need some way to set the color for each row/column combination (i.e. each cell).
Worst case scenario I could create a struct with a color value for each cell in a row each time a new row is created and use SetItemDataPtr to point to the struct, but I really don't want to do that.
So in short, does a CListCtrl object have an unused data structure for each cell that I could use to store my COLORREF variable?
Thanks!
KR
|
|
|
|
|
KellyR wrote: but I really don't want to do that.
why not?
|
|
|
|
|
I don't want to worry about memory management with allocating and freeing memory for the structs. It's just easier to use a value that already exists on one of the cells. I think I can use the lParam of an LVITEM structure by calling SetItem with iItem = row and iSubItem = column but I'm not sure. I'm going to try that.
KR
|
|
|
|
|
Well apparently there's only one lParam variable on each row, there isn't one for each subitem. Also I can't call SetItemDataPtr from a CListCtrl, it's only for CListBox, so even the worst option is town the toilet. The only other way I can think of to do this is just create some silly external linked list or array that I can index into by row id. Isn't there any other way to do this? Can anybody help? Isn't there some way to store a variable on a specific cell in a CListCtrl?
KR
|
|
|
|
|
I was having the same problem but not with the CListCtrl but with a coloured ComboBox, I tried as you say, and my final solution was... An array declared/filled into the stdafx.cpp and use it everywhere I needed it with extern
Maybe is not so "pretty" but is efective as well and the memory... If you don't want to allocate... don't do it. Make an array of 10 different colors and loop it if you have more than 10 items. 10 COLORREF won't be any problem to the needed memory amount and you won't have to allocate/deallocate anything. BTW, I don't think you were thinking on having an unique colour or every cell, weren't you?
KellyR wrote: Isn't there some way to store a variable on a specific cell in a CListCtrl?
Why don't you save it into the object that is going to that cell insteads of in the cell itself? I mean... If you have a class/object with X datas and 2 of them are shown in the listCtrl and a particular data needs a particular colour... then add the COLORREF to the object insteads of to the cell.
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
You do realise that CListBox::SetItemDataPtr() is just a wrapper for CListBox::SetItemData() ? You can get exactly the same effect in a CListCtrl using LVM_SETITEM. Maybe you should look into using one of the many Grid controls out there. MSFlexGrid has CellBackColor and CellForeColor Properties.
|
|
|
|
|
Actually I ended up doing something similar, I used the lParam on each LVITEM to store a pointer to a struct that I created to hold the COLORREF ints on InsertItem. Everything works now.
KR
|
|
|
|
|
KellyR wrote: Well apparently there's only one lParam variable on each row, there isn't one for each subitem.
Sorry I went home for the day or I could have told you that.
KellyR wrote: Also I can't call SetItemDataPtr from a CListCtrl, it's only for CListBox, so even the worst option is town the toilet.
There is a SetItemData for CListCtrl, I use it all the time. I think Roger Broomfield is correct.
KellyR wrote: I don't want to worry about memory management with allocating and freeing memory for the structs.
Sounds like you require a simple design to account for memory management. Perhaps this is a pattern in C++ development? 
|
|
|
|
|
Hi all =)
An easy one. I'm just not sure the compiler does this the way I think it does...
The following expression would be evaluted to a constant, right?
(tOC(1) << (sizeof(T) << 3)) - 1
Lets say that, when compiled, the code will no longer be an expression, but a constant value. But what about this?
oc & ((tOC(1) << (sizeof(T) << 3)) - 1)
Evaluates to:
oc & const
Is this right?
Best regards
|
|
|
|
|
hint_54 wrote: tOC(1)
hint_54 wrote: oc
????
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
There's a line before that :P
tOC oc;
tOC is the datatype, I'm just casting
regards
|
|
|
|
|
Take a look into the last sentence in my signature
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
I totally disagree =)
Otherwise, how would I learn?
best regards
|
|
|
|
|
I have a memory backed DC that I've drawn to.
I was trying to use InvertRgn on it and it dawned on me that Raster operations will only work on a physical device or at least that's what seems correct at the moment. Is there a way to invert a region on a memory backed DC before it's blitted onto the screen?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
