|
Storing things in vector sounds interesting - never thought about such approach, thanks 
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
I was talking about a vector representation of the graphics, not about storing them in a vector type container, although that could also perform well.
Just to avoid misinterpretations.
|
|
|
|
|
Oh, i see, ok. Yeah, some misunderstanding occurred. But, my misinterpretation of a part of your post gave me some new ideas! 
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
The general solution is to just invalidate the window[^] or better yet, the old ball rectangle and the new ball rectangle and then draw it again in the WM_PAINT which is called automatically when you invalidate the area.
1 minor issue with this is that it will do what is called "flickering" where it flashes.
To fix this mute the WM_ERASEBKGND message and use a memory DC. Search codeproject or google for "memory DC" or "flicker free drawing" to see how this is done in code.
|
|
|
|
|
Thanks guys
Looks like invalidating / redrawing window is the only way. This "ball" is actually a part of custom control i am writing (has its own window) - it is already double buffered.
case WM_PAINT:
{
Gdiplus::Graphics graphics(hdc);
Gdiplus::Bitmap *bmp = new Gdiplus::Bitmap(CtrlRect.right, CtrlRect.bottom);
Gdiplus::Graphics *temp = Gdiplus::Graphics::FromImage(bmp);
temp->SetSmoothingMode(Gdiplus::SmoothingMode::SmoothingModeAntiAlias);
Gdiplus::CachedBitmap *cbmp = new Gdiplus::CachedBitmap(bmp, &graphics);
delete bmp;
delete temp;
graphics.DrawCachedBitmap(cbmp, 0, 0);
}
Just thought it could be done a way smoother - without redrawing. Anyway, thanks
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
Well, I know that scrollbars work by moving the screen data, rather than redrawing, in things like ListBox's and web browser controls.
Presumably this behaviour could be implemented into your solution too, but for something so simple, it would not be worth the complexity that I imagine it might take.
|
|
|
|
|
Good point.
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
I was getting a heap corruption error merely doing a new and delete (next to one another) of a class within a dll. After some troubleshooting, I found that I could avoid the error by changing a bool to a BOOL in the base class of the guilty class, which means that specific boolean variable size was being evaluated incorrectly (there's another bool that works fine).
Anyone have any clue as to what would cause this behavior?
Here's the original question posting (see posting for details and solution):
http://www.codeproject.com/Questions/164517/Heap-corruption-detected-in-class-after-delete-but.aspx[^]
modified on Saturday, March 5, 2011 5:41 PM
|
|
|
|
|
I find it hard to believe that the size was incorrectly determined. What you could do is try to change the order of the class' instance variables, since it's more likely it has to do with member alignment, which is influenced by the size difference of bool and BOOL. The rearrangement of the members will not be a solution to your problem, but you might get new ideas for the reason of the problem. If you're lucky the error will turn up in a different way, which will add to the clues.
From what you describe, it sounds very likely that the constructor of the class is the naughty one. Check all non-trivial constructors of your instance members, and possible base class constructor code. Who knows, a 'clever' programmer might have made assumptions about the boolean flag
*(BOOL*)&m_bool = FALSE;
Well, just a few ideas...
|
|
|
|
|
I did a global solution search for the member bool and couldn't find anyone using it improperly, and yep, already tried changing the order. I also commented out the constructor and replaced it with (to make sure the constructor wasn't the one doing it):
class CBaseClass
{
public:
CBaseClass(){}
virtual ~CBaseClass(){}
};
class CClass : public CBaseClass
{
public:
CClass(){}
virtual ~CClass(){}
};
|
|
|
|
|
Is there any #pragma pack(#) or __declspec(align(#)) directive somewhere (may affect it) before your class?
If the base class' implementation is in pre-compiled form or it is an MFC class while using MFC in shared libs, default packing alingment is 4 (for x86). AS you may know, BOOL is defined as type 'int' which is 4 bytes in size while bool is 1 byte.
|
|
|
|
|
Good suggestion, I'll look at directives (and yes I know about size difference)...
|
|
|
|
|
You were right on! A #pragma pack(show) revealed the problem. Someone had a #pragma pack(1) in a header file. I have to look over the code a little closer but the header should probably have a #pragma pack(push,1) and corresponding #pragma pack(pop).
If you want to place this as a solution in the question (see link above) in the other page I'll accept it, give you some credit. THANKS! 
|
|
|
|
|
Please. I'm glad the issue is resolved without posting your class code here.
|
|
|
|
|
Funny thing is that posting the class code here would have kept everyone scratching their head, since the guilty header wasn't even part of that code. That's why it worked fine when I pulled it into another application (which is what I did for testing).
|
|
|
|
|
I suppose it's time for posting your class code here.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I might do that next... its not particularly complicated code, so this is a real pain in the butt 
|
|
|
|
|
Can you post more details?
Steve
|
|
|
|
|
We have some code which creates a 64-bit MD5 which is not used for encryption, but as an identifier. We're adding other code that has a 128-bit MD5 and I'd like to drop the 64-bit MD5 algorithm and just convert a 128-bit hash to 64-bit for this one case. It would be nice to avoid collisions, but not a big deal if they happen.
Anyone know the best way to do this?
|
|
|
|
|
Any 64 bits of the 128 (provided you pick the same ones every time!) will do what you are trying to do. The idea of a hash like MD5 is that each bit of the hash depends on (nearly) all input bits. Make it easy by picking the leftmost 64, or the rightmost.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
|
|
|
I've used MFC within DLLs a lot, those articles just talk about the different ways of doing it. I use the "C-like" function interface with MFC dynamically linked.
|
|
|
|
|
Hi . I stock on the follow problem :
I have an CListCtrlEx , derived from CListCtrl , where I have :
afx_msg void OnHdnItemclick(NMHDR* pNMHDR, LRESULT* pResult);
and implementation :
ON_NOTIFY_REFLECT(LVN_COLUMNCLICK, CListCtrlEx::OnHdnItemclick)
...
...
void CListCtrlEx::OnHdnItemclick(NMHDR* pNMHDR, LRESULT* pResult)
{
NM_LISTVIEW* phdr = reinterpret_cast<NM_LISTVIEW*>(pNMHDR);
SortOnColumn(phdr->iSubItem, TRUE);
*pResult = 0;
}
and I need to catch LVN_COLUMNCLICK in parent window :
afx_msg void OnHdnItemclickList1(NMHDR* pNMHDR, LRESULT* pResult);
and implementation :
ON_NOTIFY(LVN_COLUMNCLICK, IDC_LIST1, OnHdnItemclickList1)
...
...
void CTestList5View::OnHdnItemclickList1(NMHDR* pNMHDR, LRESULT* pResult)
{
NM_LISTVIEW* phdr = reinterpret_cast<NM_LISTVIEW*>(pNMHDR);
CString sTemp;
sTemp.Format("%d",phdr->iSubItem);
TRACE("\n column %s\n",sTemp);
*pResult = 0;
}
the problem is that program don't cross through CTestList5View::OnHdnItemclickList1
.... why ? And how can I solve the problem ?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
