|
I bet you're on 9x, right? That usually means you've exhausted your process's GDI resources or filled the GDI heap (which is limited to 64K on 9x, due to 16-bit limitations). Are you making new GDI objects (pens, brushes, etc.) every time you paint your control? And if so, are you deleting those objects?
--Mike--
"COM didn't solve the old version of DLL hell - it just provided us with a new and improved version of hell."
-- John Simmons, 1/22/2002
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan.
|
|
|
|
|
You're right, I am on Windows 98.
I have been using SaveDC() and RestoreDC(). I also declare all of my GDI objects that I will need in my OnPaint method at the beginning, so that they are all on the same scope. So, everytime the OnPaint() method is called I SaveDC() and create new GDI objects, use them, and when I'm done call RestoreDC() and the objects should be deleted when they go out of scope.
Am I doing this wrong?
Thanks.
Mark Lenz
|
|
|
|
|
As Mr. Dunn mentioned above, Windows 98 is very sensitive to resource leaks. However, you can usually detect when this is happening on Windows 2000 by using the task manager. Display the processes page, use the View->Select Columns menu to display the GDI Objects column, and watch the number for your application. If there is a constant increase while it is running, then you've detected the resource leak (this is safer than running the app in Win95/Win98, since resource leaks can cause those OSs to become unstable).
Once you can quickly identify the resource leak, modify your code by commenting out lines that create and use GDI resources, one at a time. In this way you should be able to identify which resources are not being released.
The method you're describing sounds like it should be working; however, because you're relying on automatic deletion of the objects there is no easy way to verify that it is successful. Inserting temporary DeleteObject() calls before the objects go out of scope might also be a good way to narrow down the search:
VERIFY(gdiObj.DeleteObject());
If this line ASSERT()s, then you've found a problem.
And if you can reduce your problem to a few lines of code (i.e.
<br />
CPen pen(PS_SOLID, 1, RGB(0,255,0));<br />
int nSave = dc.SaveDC();<br />
dc.SelectObject(&pen);<br />
VERIFY(dc.RestoreDC(nSave));<br />
VERIFY(pen.DeleteObject());<br /> ) then post it here, & someone will prolly figure it out.
farewell goodnight last one out turn out the lightsSmashing Pumpkins, Tales of a Scorched Earth
|
|
|
|
|
So, you're still making a lot of GDI objects, since you repaint the controls often. First thing I'd suggest is to move the GDI objects so they're memeber variables of the control classes, so that you only create the objects once.
And btw, the problem doesn't appear on 2000 because NT doesn't have the 16-bit limitations that 9x does.
--Mike--
"COM didn't solve the old version of DLL hell - it just provided us with a new and improved version of hell."
-- John Simmons, 1/22/2002
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan.
|
|
|
|
|
I see the problem in Windows 98, but I can't duplicate it in Windows 2000.
Mark Lenz
|
|
|
|
|
Hi,
Does anybody know how to find out from the windows api's if a cdrom drive is a CDR/CDRW drive.
I have used GetDriveType( "D:" ) but this only shows that the drive is a CDROM.
Any ideas ??
Adrian
|
|
|
|
|
I don't know if this works, but perhaps you could try GetFileAttributes on the drive root and see if the directory is read-only?
/moliate
|
|
|
|
|
Hello,
I want export a class in a MFC dll...
class AFX_EXT_CLASS CMyClass : public CMyOtherClass // in other dll linked
{
...
};
and after build:
CMyClass.cpp(19) : warning C4273: CMyClass::CMyClass': inconsistent dll linkage. dllexport assumed.
CMyClass_MSA.cpp(28) : warning C4273: CMyClass::~CMyClass': inconsistent dll linkage. dllexport assumed.
Linking...
Creating library ...
MyClass.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) const CMyClass::`vftable'" (__imp_??_7CMyClass@@6B@)
I don't understand. Please, help me!
Thank you.
Friendly.
|
|
|
|
|
|
|
De poco sirve este enlace tronco.
Pure garbage!
Anybody fixed???
|
|
|
|
|
Hi Guys,
did somebody know how to list HTTP Directory.
Please Help its URGENT....
Thanx in advance
Best Regards
Sonu
|
|
|
|
|
How do I make a display window using visual C++ which shows OpenGL as a child to the application??
|
|
|
|
|
1.) Is MFC thread-safe by itself?
I played aruond with Joseph Newcomers (veryvery good) Queue-class and dicoverd, that it works fine without any syncs! So I used CLists directly in an MT-App and it works fine!
2.) Can I build a CDialogBAR from an in memory resource, a DLGTEMPLATE?
I prefer memorybased Dialogs then .rc-based one for several reasons and I wanna do so with DialogBars, too. Is it possible?
What do you think about DLGTEMPLATE-Dialogs at all, any pros or contras?
mfg HintiFlo
|
|
|
|
|
I've inherited a class CMyPrintDialog from CPrintDialog, and it's initialisation happens in OnInitDialog(). OnInitDialog is only called in the release version. In the debug version, the dialog remains uninitialised!
Does anyone know why?
Thanks
Jonnie
|
|
|
|
|
Woah, you mean that if you put a breakpoint inside the OnInitDialog function, it never stops there? The only possible explanation is that it's using another class. Check and make sure you don't already have a class with the same name defined somewhere else. I got bitten by this problem a long time ago -- redefining a class somewhere else with the same name. I don't remember why the compiler or linker never caught it, but it drove me nuts for a long time before I discovered it.
Regards,
Alvaro
|
|
|
|
|
I've run into this problem in the past; it appears to be either a bug in some versions of MFC, or small version differences: debug EXEs compiled (and working) on one developer's machine would fail to work on another. Installing the latest service pack fixed it for me. You might also try just re-installing the version you have (if you don't have access to the latest service pack, or have a slow internet connection for instance), but i can't say whether this will have any effect or not.
farewell goodnight last one out turn out the lightsSmashing Pumpkins, Tales of a Scorched Earth
|
|
|
|
|
Thanks for your help. It was an MFC bug fixed in the Visual Studio 6.0 Service Pack 1. Works like a dream now.
Jonnie
|
|
|
|
|
Hi,
I have the following code
WNDCLASS wc;
// Source window
wc.style = CS_HREDRAW | CS_VREDRAW;
wc.lpfnWndProc = NULL;//(WNDPROC)SourceWndProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;//UD_MAIN_WINDOW_EXTRA_BYTE;
wc.hInstance = A_hInst;
wc.hIcon = LoadIcon( A_hInst, MAKEINTRESOURCE(ICO_UMAXLOGO) );
wc.hCursor = LoadCursor( NULL, IDC_ARROW );
wc.hbrBackground = (HBRUSH) GetStockObject( LTGRAY_BRUSH );
wc.lpszMenuName = NULL;
wc.lpszClassName = kMAIN_WINDOW_CLASS; // define in TW_LAYOT.H
if( !RegisterClass( &wc ) )
return FALSE;
But RegisterClass() fails in windows 98.
Can anyone pl help me.
Neha
|
|
|
|
|
Apart from RegisterClassEx being a better function to use, what is the error returned from GetLastError when RegisterClass fails?
Michael 
|
|
|
|
|
I have downloaded & unzipped the STLport library. There are several make files found.What needs to be done , so that I can start using it.
Thanks very much
|
|
|
|
|
The procedure differs depending on your compiler. There are several good .html docs in the /doc subdirectory of your STLPort directory. For example to build the STLPort for Visual C++ 6, you would go to a command prompt, run VCVARS32.bat to register the build evnironment variables, then run
nmake /f vc6.mak clean all
and watch it compile (takes a few minutes)
In order to use it, you would need to set it in your include search path BEFORE any other paths which would contain another STL implementation.
|
|
|
|
|
Hi,
Can Any one tell me how can i close one application from other one as i have the path of first application in the second application while sing registry....
Neo.
|
|
|
|
|
CWnd pwnd = FindWindow(LPCTSTR lpszClassName, LPCTSTR lpszWindowName );
PostMessage(pwnd->m_hWnd, WM_CLOSE, 0, 0);
You can find lpszClassName and lpszWindowName parameters of FindWindow() with the Spy++ utility from Visual Studio Tools
"Needless redundancy is the hobgoblin of software engineering." - Peter Darnell
|
|
|
|
|
... or WM_QUIT
Normski. - Professional Windows Programmer
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
The link didn't show up on reply 
