|
namespaceuser wrote:
using some function or class(i'm trying to retrieve C:\Windows or E:\WINNT or something like
In Continuation With Mr. Ravi,
you can also use GetWindowsDirectory and GetSystemDirectory
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
namespaceuser wrote:
i'm also trying to add a key to the registry.
How about RegCreateKeyEx()?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
I have defined the following:
_variant_t varString ;
I would like to change this value regularly.
I am using a win32 dll and would like to do something that i would do in MFC like
std::string tag;
varString.format("C:\\Myfiles\\%s.xml",tag);
Is there any way that i can achieve the above in a win 32 environment?
|
|
|
|
|
You can use _bstr_t:
varString=_bstr_t("c:\\myfiles\\")+_bstr_t(tag)+_bstr_t("s.xml");
or you can create the string using sprintf:
char bigBuffer[1000];
sprintf(bigBuffer,"C:\\Myfiles\\%s.xml",tag);
varString=_bstr_t(bigBuffer);
Hope that helps.
|
|
|
|
|
the application crashed on pTthread 0x01430140{CWinThread h=0xfeeefeee proc=0xfeeefeee}, in the C:\...\VC98\CRT\SRC\DBGHEAP.C, _ASSERTE(pHead->nBlockUse == nBlockUse);
then it will report the memory leak and stop debug, but release works fine. it should be a bad pointer somewhere?
dbName::dbName()
{
m_pdbf = NULL;
}
dbName::~dbName()
{
delete m_pdbf;
}
after delete m_pdbf, m_pdbf will still contant the address, is it what causing the problem? thanks!
|
|
|
|
|
valerie99 wrote:
after delete m_pdbf, m_pdbf will still contant the address, is it what causing the problem?
No, because the dbName object (and thus its m_pdbf member) is being destructed, anyway.
If you break in the debugger when the assertion fails, does the call stack trace back to this destructor? If so, you might be deleting an invalid dbName object, or doing so through an invalid dbName*; check the value of the this pointer in the context of the destructor.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Thanks for your reply.
the call stack couldn't trace back on any part of my code except MFC, but assertion failed is happening around destructor been called.
I just checked the this pointer in the contest of destructor "0X0012f844", the value of m_pdbf is "0X013afef0"......thank you!
|
|
|
|
|
Try setting a breakpoint in the destructor, and each time it breaks, inspect the content of the dbName object and the object pointed to by m_pdbf, and check the call stack to see from where the destructor is being called. When the program crash, try to relate it to what you observed last time the destructor was executed.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
seems like assertion failed right after clean up the local thread in c:\...\MFC\SRC\THRDCORE.CPP, in function AfxTermThread();
could it be the wrong thread been cleaned up causing the problem?
thanks.
|
|
|
|
|
make sure that each time you delete an object that you assign NULL to the pointer.
delete m_pdbf;
m_pdbf = NULL;
and that each time you declare a pointer you assign it NULL.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
This sounds like a slight twist on an old problem. Where the problem appears to be may not be where the problem is. You need to work backwards from where you first see the problem and examine every allocation and memory access. The simpilest way it to place a lot of TRACE(...) commands in your code along the path leading upto the problem, and examine the trace output. A validator like BoundsChecker will probably help solve the problem, but validators have limits to; so the TRACEs may be your best bet.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Thank you! yeah, seems like it could be anywhere now.......
I might have to try to use TRACE(...) the only thing is I haven't checked out the project yet, because the release version works, and nobody want to mess with it......oh, well.....thanks again!
|
|
|
|
|
Not absolutely positive, but have seen similar crashes before, and the cause was a double-delete. If I remember right, 0xfeeefeee is one of the fill patterns for already deleted memory. Hope that's helpful.
|
|
|
|
|
1. you are deleting the instance of dbName multiple times.
2. You have deleted m_pdbf in another method of dbName and didn't NULL it out thus the double delete.
3. You didn't initialize m_pdbf to NULL (assuming it will get a value in another location) thus when the destructor gets called, you are trying to delete trash.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Hi,
Just wondering, if it's possible, what the right way to get my 32 bit project to be compiled to 64 bit executable?
Just one restriction, it shouldbe done in VS .NET 2003 (not 2005).
Thanks.
|
|
|
|
|
Folks, I am looking for a simple way to load two bitmaps in C++ .NET All I need to do is load them, and know they are there. I have a .DLL that will then run comparison test. My expertise in this is only starting to develop, so advice is appreciated.
Sincerely,
Max Pastchenko
|
|
|
|
|
Is LoadBitmap() what you are looking for?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
You are probably, right, I am gona work on trying to figure out how to implement it. An example you would useful.
Sincerely,
Max Pastchenko
|
|
|
|
|
mpastchenko wrote:
An example you would useful.
See here.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
|
Yes, this appers useful. I will look at this example in details later today.
Sincerely,
Max Pastchenko
|
|
|
|
|
LoadImage does this, just use the LR_LOADFROMFILE flag.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04
"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05
Within you lies the power for good - Use it!
|
|
|
|
|
What does this flag indicate?
Sincerely,
Max Pastchenko
|
|
|
|
|
That you're loading an image from a file. You can use it to load from resources as well, from memory.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Read all about LoadImage in MSDN[^]
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04
"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05
Within you lies the power for good - Use it!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
