|
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
|
|
|
|
|
try: http://www.codeproject.com/gdi/coolrgn.asp[^]
It allows you to create a region to use with SetWindowRgn (as Michael Dunn suggestion below) from a bitmap file.
I use something similar for my funky non-rectangle app.
That's why I ramble so much. If you're short and quotable, there's a much greater danger of ending up in a sig.
[Christopher Duncan on how to prevent yourself from ending up in a sig]
|
|
|
|
|
As an example, there is a project posted here on codeproject (by John Roark) that displays a "skinned" dialog (sorry I don't have the link at this time). If I try to add a CStatic derived class to it, I keep getting link errors (see below). I am using the "Use MFC in a static library" option. Using a shared dll option does not produce the error, but I need to have the static library option.
Every search I do keeps telling me that I can solve this error by selecting one of the Multi-Threaded options in the "Code Generation" tab of VC6. The thing is - I already have the Multi-Threaded option picked.
I'm really hoping that this is a very simple problem to solve, but I'm stumped.
Any ideas?
Thanks,
David
Link errors:
nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already defined in LIBCMTD.lib(new.obj)
nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in LIBCMTD.lib(dbgdel.obj)
Debug/SkinTrial.exe : fatal error LNK1169: one or more multiply defined symbols found
Error executing link.exe.
|
|
|
|
|
Are you linking to any other static libraries? They will also need the same settings.
One other thing - sometimes it is easer not to fight these types of errors and create a clean project from scratch. In other words, create a new project (DSP), making sure to select that you are using MFC statically. Then add your files, making sure things still compile. Chances are this will work, or at least help you narrow down the culprit.
Even a broken clock is right twice a day.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
