|
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)
|
|
|
|
|
Mark Salsbery wrote: "Do not call any methods of the Graphics object between the calls to GetHDC and ReleaseHDC."
This I've seen and try to protect against.
Mark Salsbery wrote: 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.
This would make sense as to why the original warning above even exists if I'm understanding you correctly. Are you saying the warning would revolve around the possibility that the HDC did not exist before the Graphics object came to life? I'm taking it to mean that if I provide the HDC to the constructor for a graphics object, I need not bother with Graphics::GetHDC() ?
|
|
|
|
|
bob16972 wrote: I'm taking it to mean that if I provide the HDC to the constructor for a graphics object, I need not bother with Graphics::GetHDC() ?
Definitely! GetHDC() may pass you back the same HDC, it may give you a temporary one.
I'd like to see the GDI+ source code to see what it does with HDCs.
I'd say it's much more flexible to start with your own HDC and wrap it with a Graphics object when you
need to do some GDI+ stuff on it. Of course, if you're just using GDI+, this doesn't apply. 
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Cool. Thanks for the help.
I'd email you an egg McMuffin if I could. 
|
|
|
|
|
bob16972 wrote: I'd email you an egg McMuffin if I could.
Heh. I'd eat it if you could!
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
