|
I have an app, that receives data on multiple sockets on a thread pool and updates certain data objects. These data objects are accessed by MFC CFrameWnd derived windows to display them. I have seen that using critical sections in the data classes lead to many unfavourable inetractions causing deadlocks in MFC.
Is there an article/discussion on the procedures/guidelines that need to be followed in the design to prevent deadlocks in MFC apps when the data is mdified from another thread and the access to the data objects are protected using critical section or mutex?
Also, is it advisable to use a timer for periodic refresh of the windows OR send a message from the other thread to the window, asking it to refresh because of a data change? What are the procedures that can be used to prevent excessive re-painting due to large amounts of data arriving in a short period?
Any inputs are welcome.
Thomas
My article on a reference-counted smart pointer that supports polymorphic objects and raw pointers
modified 29-Aug-18 21:01pm.
|
|
|
|
|
Thomas George wrote:
Also, is it advisable to use a timer for periodic refresh of the windows OR send a message from the other thread to the window, asking it to refresh because of a data change? What are the procedures that can be used to prevent excessive re-painting due to large amounts of data arriving in a short period?
Funny you should ask that question. I'm working on an app right now with this very problem. I've tried both approaches. Using the timer works, in that it updates the screen regularly. Using the timer doesn't work when you've got a lot of data coming in, because WM_TIMER messages are low priority. As a result, the WM_TIMER doesn't happen in a timely fashion, so the display doesn't update as often as you'd like. Sending a message every 'N' data items has similar problems, in that it updates the display too much under high data rates. Fortunately, I can set this part of the problem aside for awhile, and let the back part of my brain figure out a solution.
Good luck. Sorry I couldn't be of any real help.
Software Zen: delete this;
|
|
|
|
|
I had no problems with updating my GUI regulary depending on WM_TIMER message, but I believe you have if you say so.
In another project I created a thread that posted a custom message (not WM_TIMER) in regular distance to my GUI message queue... my GUI then updates the display regular.
|
|
|
|
|
I am getting the warning that the performance counter DLL is not aligned on an 8-byte boundary. I originally thought the warning was being caused by our code, but even the Microsoft sample codes, ScribbleMouse and HWInputMon written by Jeffrey Richter (MSJ Aug 1998), are giving the same warnings.
I checked the allocation size in the case of the ScribbleMouse, and at 160 bytes, seems to be properly aligned.
Does anyone know of a solution to this, or how to resolve the problem.
I have looked at the KB Q262335 referred to below, and have tried various options without luck.
HOWTO: Align Performance Data of a Performance Extension DLL on an 8-Byte Boundary
SUMMARY
When the performance data buffer returned by a performance extension DLL is not aligned on an 8-byte boundary, the performance library (PERFLIB) part of ADVAPI32.dll will report a warning 1016 to the Application Log in Event Viewer. This article explains how the developer of a performance extension DLL can align the performance data on an 8-byte boundary.
Gaul
http://www.gaulles.com
|
|
|
|
|
Hi. Im working on a project that has a print preview class that prints a lot of small text boxes. The problem is that using CDC::DrawText(...), the charaters size do not change linearly with zoom, but in small discrete "jumps", making the word wrap change the word disposition between lines. This is terrible, because what you see is not what you get(WUSI(N!!!!)WUG)!
Im zooming using MM_ISOTROPIC map mode.
Ive tried using a CRichEditCtrl to display text and the zoom works great, which makes me think i can make the text boxes work the same.
How do i crack this one?!?!
Thanks in advanced!
|
|
|
|
|
When making custom draw controls, what “errors” would make the actual drawing take up system resources.
I have a custom graph that updates every second,, and it uses 2-4 % of the system, I think this is an error of some kind. I restore all of my GUI objects pens/brushes/etc.
Any help would be good.
"Best file compression around: DEL *.* = 100% compression."
<><><><><><><><><><><><><>
Matthew R. Miller
mattrmiller@computersmarts.net
www.computersmarts.net
|
|
|
|
|
If the amount used does not grow, then there is no leak, and I dunno without seeing the code if there's anything that is being done that is wasteful.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
I derived a class from CTreeView in order to implement drag and drop between trees. I also made it so I can add/delete/edit items in the tree. I need a way of saving the edited tree so I can load it up the next time I run my app.
Any suggestions? I don't want to have to parse through the tree and save/load that way.
|
|
|
|
|
|
Hi,
I posted this message before, but maybe this time I can give a little more information.
I wrote a DirectX program using Marcio Ritter's tutorial. Sadly, it crashes everytime I run it. I have, however, narrowed it down to a line of code that is causing the problem. Here is the function, ProcessIdle()
void ProcessIdle()
{
HRESULT hRet;
BOOL bOK;
bOK = g_Brick.Draw(g_pDDSBack, 10, 10, 2, 2, 10,10);
while( 1 )
{
hRet = g_pDDSFront->Flip(NULL, 0 );
if( hRet == DD_OK )
{
break;
}
if( hRet == DDERR_SURFACELOST )
{
g_pDDSFront->Restore();
}
if( hRet != DDERR_WASSTILLDRAWING )
{
break;
}
}
}</code>
The while loop also causes problems if I remove the first problem line. I think that may be because I can only test that line when I remove the first problem line, and it needs that line to run.
Here is the function that the problem line calls:
BOOL CSurface::Draw(LPDIRECTDRAWSURFACE7 lpDest, int iDestX, int iDestY, int iSrcX, int iSrcY, int nWidth, int nHeight)
{
RECT rcRect;
HRESULT hRet;
if(nWidth == 0)
nWidth = m_Width;
if(nHeight == 0)
nHeight = m_Height;
rcRect.left = iSrcX;
rcRect.top = iSrcY;
rcRect.right = nWidth + iSrcX;
rcRect.bottom = nHeight + iSrcY;
while(1)
{
if((int)m_ColorKey < 0)
{
hRet = lpDest->BltFast(iDestX, iDestY, m_pSurface,
&rcRect, DDBLTFAST_NOCOLORKEY);
}
else
{
hRet = lpDest->BltFast(iDestX, iDestY, m_pSurface,
&rcRect, DDBLTFAST_SRCCOLORKEY);
}
if(hRet == DD_OK)
break;
if(hRet == DDERR_SURFACELOST)
{
Restore();
}
else
{
if(hRet != DDERR_WASSTILLDRAWING)
return FALSE;
}
}
return TRUE;
}</code>
Thanks for your help! If you need to see the source code, PLEASE e-mail me for it! (nreveles@austin.rr.com)
If you have a problem with my spelling, just remember that's not my fault. I [as well as everyone
else who learned to spell after 1976] blame it on
Robert A. Kolpek for U.S. Patent 4,136,395.
|
|
|
|
|
From looking at the code, the g_Brick object may not be initialized properly, or the g_pDDSBack surface. The g_Brick variable is an object that has been created, but have you actually created a surface to initialize this object.
The while loop may have problems because either the g_pDDSFront variable is not initialized and you are calling from it, or the g_pDDSBack variable is somehow used in the Flip function.
If you want to send me your code, zip up the source files and the project and send it to kilowatt@prodigy.net and I will be happy to look at it.
Good Luck
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
I think I have a very subtle bug here...
Here's the jist of it:
class First {
...
static int i;
...
};
int First::i = 7;
class Second {
...
static int q;
...
};
int Second::q = First::i;
I have a feeling that the order in which those statics get initialized is undefined (or at least compiler-specific), so Second::q might get 7 and might not.
Is this correct?
J
May the bear never have cause to eat you.
|
|
|
|
|
I dunno, but I would tend to do this instead:
const int STATICVALUE = 7;
int First::i = STATICVALUE;
int Second::q = STATICVALUE;
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Perhaps my example was poor. 
Yes, that would solve the problem I posted. What I actually want to do is this:
class First {
static char *szName;
};
char *First::szName = "First";
class Second {
static char *szName;
};
char *Second::szName = "Second";
class User {
static char *aszNames[];
};
char *User::aszNames[] = {First::szName, Second::szName};
The names are essentially constants, but the initialization order is still undefined. 
J
May the bear never have cause to eat you.
|
|
|
|
|
The newsletter must be going out, I just got this. Got a ton of notifications inbetween tho 
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Once again, I found the answer to my own question. Unfortunarly, I was right. Thankfully I found it before it posed any major problems...
Here's a nice link[^] to an explanation and potential solutions.
J
May the bear never have cause to eat you.
|
|
|
|
|
This is absolutely correct (I mean, it is pontentially broken as you suspected). In your particular case, chances are that you don't notice anything strange, as initialization of First::i can be done in compile time (i.e. the value 7 is directly stored in the executable). Try this for some more fun:
class First {
...
static int i;
static int j;
...
};
int First::i = 7;
int First::j = Second::q;
class Second {
...
static int q;
static int r;
...
};
int Second::q = First::i;
int Second::r = First::j;
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Weeee! 
J
May the bear never have cause to eat you.
|
|
|
|
|
There's a way out of this dilemma in the case of two or more compilation units whose initialization depends on one another (though the best soluttion is probably to rethink the design): wrap the static data into accessors, just like this:
class First
{
...
static int i();
static int j();
...
};
int First::i()
{
static int i_ = 7;
return i_;
}
int First::j()
{
static int j_ = Second::q();
return j_;
}
class Second
{
...
static int q();
static int r();
...
};
int Second::q()
{
static int q_ = First::i();
return q_;
}
int Second::r()
{
static int r_ = First::j();
return r_;
}
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
When I use the MessageBox function and a Manifest file under XP, the MessageBox isn't displayed. Without Manifest file it does work. What's wrong?
Sjoerd van Leent
LPCTSTR Dutch = TEXT("Double Dutch ");
|
|
|
|
|
This thread is DAMN old, i know.
But for people who actually wanna find the solution (like myself the half of day), here is the answer:
XP Manifest indicates that application will use Microsoft.Windows.Common-Controls ver. 6.0.0.0 theme extensions.
But it DOES NOT ensure that that the common control dynamic-link library (DLL) is loaded.
So before calling something even as simple as "MessageBoxA" in the application with such embedded manifest, you should call "InitCommonControls" from "comctl32.dll".
|
|
|
|
|
I want to learn how to make my own custom shaped dialogs, much like Windows Media Player[^] does, with it's own user-defined edge.
I'd search for topics here at CP, but I do not even know what the technique is called, making it hard. I figured it had something to do with transparency, so I search for that keyword, but nothing obvious surfaced. Anyone know a good article I ought to read? I'm just looking for some direction.
Edit: I'd like something in MFC, if at all possible... and if not possible I'd like to know why?
: Dean 'Karnatos' Michaud
|
|
|
|
|
Check out this article for a way to get started:
http://www.codeproject.com/dialog/message_balloons.asp[^]
Remember that MFC is a class library wrapped around the Windows API. AFAIK, Windows doens't natively support dialogs that aren't square, so you have to write custom code to do it, so it is unlikely that this will get into MFC anytime soon.
Even a broken clock is right twice a day.
|
|
|
|
|
Beautiful... Most appreciated!
: Dean 'Karnatos' Michaud
|
|
|
|
|
Navin wrote:
doens't natively support dialogs that aren't square,
It certainly does, check out SetWindowRgn().
--Mike--
"alyson hannigan is so cute it's crazy" -- Googlism
Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
