|
It sounds like the .ocx file has not been properly registered. You can register it with the regsvr32.exe program.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Hello,
i have a little problem with the interpretation of CreateNamedPipe(...)
what exactly is the difference between the dwOpenMode flag FILE_FLAG_OVERLAPPED and the dwPipeMode flag PIPE_WAIT, and which of those is used if both are specified?
Thanks in advance!!
|
|
|
|
|
hph wrote:
what exactly is the difference between the dwOpenMode flag FILE_FLAG_OVERLAPPED and the dwPipeMode flag PIPE_WAIT...
One relates to the calling thread, while the other relates to the pipe itself.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
ok, thanks! and what does this mean ?
|
|
|
|
|
See if these two help:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/createnamedpipe.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/named_pipe_type_read_and_wait_modes.asp
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
yes it helped, thank you, i got it!
|
|
|
|
|
Hi All!
How to debug the system wide hooks? Any artical or material will be highly appreciated.
Regards,
Bilal Anjum
|
|
|
|
|
Hi all!
I have a question regarding the computer's virtual memory.
I am writing a program to simulate all kind's of combinations of a poker hand. To do this I wrote 5 while statements. This will give a complexity of about O(50 exp 5) = O(312 500 000) in the last while statement I will do some calculations. The problem is that when I run the program a run out of virtual memory ( I have increased the limit to 4GB ). I am confused why I run out of memory, I did't think the while statements would consume any memory (almost) . Could it be that I have a memory leak in the calculations that I make.
So I guess my question is; will these while statements use all the computer's virtual memory depending on the complexity?
Thanx!
Martin_j
|
|
|
|
|
martin_j wrote:
I have increased the limit to 4GB.
Not possible, even if you were using Windows 2000 AS or DS with the /3GB switch.
martin_j wrote:
So I guess my question is; will these while statements use all the computer's virtual memory depending on the complexity?
No, while statements do not use memory in the quantity you are asking.
It sounds like you need to open the Performance Monitor when your program starts and watch its memory consumption.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Are you allocating any memory in these while loops ???
You need to check ur system performance.
Is there any considerable amount of harddisk space left ?
MSN Messenger.
prakashnadar@msn.com
|
|
|
|
|
Thanx for your answer.
I do call a procedure in the last while statement wich is using pointers. So I'm afraid I do not delete these pointers properly.
While I check the system performance I can see that I use more and more virtual memory. It stops at about 2.1GB (all used) and then fills the RAM. Thereafter the program crashes.
I do have about 100GB frre space on the hard drive.
I talked to a friend and he proposed that I should use case statements instead. What would be the differense?
/Martin
Martin_j
|
|
|
|
|
I think... the you should delete your pointers properly! 
|
|
|
|
|
martin_j wrote:
So I'm afraid I do not delete these pointers properly.
Properly or not, are you deleting them at all? Remember that every new must have a matching delete.
martin_j wrote:
I should use case statements instead. What would be the differense?
Instead of what? The switch/case statement is synonymous with the if/else statement.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Sorry, I meant do/until.
I do delete all pointers as far as I can see.
Is there an easy way to debug the program and see if there is a memory leak?
/Martin
Martin_j
|
|
|
|
|
if you use MFC you can just run your app for a short
time with the Debuger attached, then exit it
and in the debug-output-window you should see
your mem leaks
|
|
|
|
|
Thanx
Martin_j
|
|
|
|
|
Even if you aren't using MFC, you can still debug memory leaks with functions like:
_CrtMemCheckpoint()
_CrtMemDifference()
_CrtMemDumpStatistics()
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Great thanx
Martin_j
|
|
|
|
|
Oopss, sorry i accidently clicked on 1 instead of 5.
I was looking for something like this all the time.
MSN Messenger.
prakashnadar@msn.com
|
|
|
|
|
Hi I have the following problem:
I have an executable that loads dlls (MFC extension dll´s).
All the dll´s are based on a parent class with various functions. To name a few
BOOL mfb_open_database (LPCTSTR);
CString mfx_get_module_name();
CString mfx_get_item_text (LPVOID);
The functions are called from the main application using a pointer to the dll class..
x_txt = px_dll->mfx_get_item_text((LPVOID)something);
The functions in the dll´s are all with AFX_MANAGE_STATE(..) because I´m loading things from the (DLL´s) resources
The funny thing is only the mfx_get_module_name() does not work, all the others do.
Tracing through this (I have added the debug symbols to the release mode of a dll and the exe)
It comes about when the constructors for the CString objects are called. As far as I can tell, the DLL creates a CString object to be returned. Instead of a "Deep" copy, only the reference of it´s m_pchData is copied to the CString Object in the exe, and when the destructor for the CString Object in the exe is called, the MFC crashes and says that the Object that is to be destroyed is not in the "correct" heap. I have tried adding
::LockBuffer() to the CString object that is created in the DLL as the returned object but to no avail.
I have checked all the project settings etc. and can´t find anything wrong.
This function worked perfectly well up until yesterday, until my devstudio crashed a few times. I´ve checked all the settings in Project setings but can´t find anything un toward. Has anybody any idea´s I´m at my wits end....
Thanks in advance
Phil
bum... and I thought I´d got rid of all the bugs 
|
|
|
|
|
are the dlls AND the app the same build type??
Release or Debug? I spent some days on a realy anoying bug. My App was Release Build and the DLL
was Debugbuild and it crashes all the time!!
solution-> use the same build type.
|
|
|
|
|
Yes, same build type. The really stupid thing is, that before the DevStudio crash everything worked fine
bum... and I thought I´d got rid of all the bugs
|
|
|
|
|
sure?
I also thought all the time, my DLLs and the
App are the same build, BUT somewhere deep was a silly path to the wrong directory with the wrong DLLs.
don't know other reason.. sory.
|
|
|
|
|
Yes I´ve checked.. I´ll have another look at the settings in a text editor, but in the IDE everything seems to be ok. And thanks for helping...
Phil
bum... and I thought I´d got rid of all the bugs
|
|
|
|
|
I have finally found the problem. In one of my base classes I have over written the OnDraw() and OnEraseBkgnd() to draw a custom background. Instead of using the MFC message entry macro,
ON_WM_ERASEBKGND(), ON_WM_PAINT(),
I used the API one: ON_MESSAGE(WM_PAINT, ...) etc.
This all worked fine in debug mode, but crashed in release.
Now everything works fine
bum... and I thought I´d got rid of all the bugs
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
