|
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?
|
|
|
|
|
I would expect InvertRgn to work on a memory DC.
Have you tried it? If so, is it not working?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Maybe I'm doing something wrong. I'll give it another go. I may have given up too easily...
|
|
|
|
|
It works fine...here's a little test, a strange mix of MFC and native code...
CImage img;
img.Create(320,240,24); <font color="Green">
HDC hmemdc = img.GetDC(); <font color="Green">
HRGN rgn = ::CreateRectRgn(20,20,100,100);
::InvertRgn(hmemdc, rgn);
::DeleteObject(rgn);
CClientDC windowdc(this); <font color="Green">
::BitBlt(windowdc, 10, 10, 320, 240, hmemdc, 0, 0, SRCCOPY); <font color="Green">
img.ReleaseDC(); Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
That worked so I'm just fudging something up in my mess here.
I'm mixing GDI mappping modes, memory backed DC's, GDI+ graphics objects, and somewhere in the midst of the drawing I'm plopping a quick detour...
HDC hdc=graphics.GetHDC();
// detour to use ::InvertRgn
graphics.ReleaseHDC(hdc);
I'm using a region handle form a GDI+ region so I'll dig through it and I'm sure the culprit is in there somewhere.
Thanks for your help and guidance and quick proof of concept. It is much appreciated.
|
|
|
|
|
Turns out when I called...
HDC hdc=graphics.GetHDC();
my metrics got all messed up and my region was showing up teeny tiny. If I used the original handle to the DC that I created the graphics object off of, everything is just fine. 
(Just gotta be careful about mixing my calls between the two)
I think I'm doing something unorthodox mixing GDI and GDI+ in the first place so it serves me right.
Anyway thanks again for taking the time to set me straight.
|
|
|
|
|
bob16972 wrote: I think I'm doing something unorthodox mixing GDI and GDI+
Calling a GDI+ method on a Graphics object you've obtained an HDC for is bad.
Also, as you've seen, make no assumptions about DC settings - save/set/restore
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
<blockquote class="FQ"><div class="FQA">Mark Salsbery wrote:</div>Calling a GDI+ method on a Graphics object you've obtained an HDC for is bad.</blockquote>
Yeah, I know. I've been careful not to cross the two. I'm just mainly using the GDI mapping mode stuff and MFC behind my Graphics objects. I still need to work on the approach a bit but you helped me identify what was going awry.
However, just for kicks, this sample is directly from MSDN (Visual Studio 2003) for GDI+ Region::GetHRGN. It uses the HDC before the graphics object goes out of scope. (Shame on them);)
VOID Example_GetHRGN(HDC hdc)
{
Graphics graphics(hdc);
Point points[] = {
Point(110, 20),
Point(120, 30),
Point(100, 60),
Point(120, 70),
Point(150, 60),
Point(140, 10)};
GraphicsPath path;
path.AddClosedCurve(points, 6);
// Create a region from a path.
Region pathRegion(&path);
// Get a handle to a GDI region.
HRGN hRegion;
hRegion = pathRegion.GetHRGN(&graphics);
// Use GDI to display the region.
HBRUSH hBrush = CreateSolidBrush(RGB(255, 0, 0));
FillRgn(hdc, hRegion, hBrush);
DeleteObject(hBrush);
DeleteObject(hRegion);
}
|
|
|
|
|
bob16972 wrote: It uses the HDC before the graphics object goes out of scope. (Shame on them);)
That MAY actually be OK, since the Graphics object is wrapping an already-existing
HDC. The only thing the docs state about that situation is:
"When you use this constructor to create a Graphics object, make sure that the Graphics
object is deleted or goes out of scope before the device context is released."
The other situation, getting an HDC from a Graphics object with Graphics::GetHDC() is more
restrictive:
"Do not call any methods of the Graphics object between the calls to GetHDC and ReleaseHDC."
I'm not sure how the Graphics class deals with HDCs internally, but I imagine when you pass an
already-created HDC into the Graphics class constructor, it just uses the DC you pass in - the
creator still "owns" the DC.
If you let the Graphics class create its own DC, however, it "owns" the DC, and the DC it gives
you through GetHDC may be a temporary copy.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
