|
|
The following code may help u..
i have Created and Debugged demo for U.
Assumming that ur using MFC Application
CString strTime="06:45:18";
CString h,m,s;
SYSTEMTIME st;
GetSystemTime(&st);
h=strTime.Mid(0,2);
m=strTime.Mid(3,2);
s=strTime.Mid(6,2);
sscanf(h.GetBuffer(2),"%d",&st.wHour);
sscanf(m.GetBuffer(2),"%d",&st.wMinute);
sscanf(s.GetBuffer(2),"%d",&st.wSecond);
CTime t(st);
//h.Format("%d:%d:%d",t.GetHour(),t.GetMinute(),t.GetSecond());
//AfxMessageBox(h);
best luck.
Thanks and Regards
Laxman
FAILURE is the first step towards SUCCESS
|
|
|
|
|
Since your example uses MFC, why not simplify things by using COleDateTime::ParseDateTime() ? For example:
COleDateTime t;
t.ParseDateTime("06:45:18", VAR_TIMEVALUEONLY);
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
One of my colleagues has got a MSVC++ Runtime error popup "R6025 - pure virtual function call". The popup is still there on his machine, so I would like to know if any crash info(address of instr that caused crash) can be obtained from this popup, may be by attaching the MSVC++ debugger or even WinDBG. Does anyone know how this situation can be debugged?
thanks!
|
|
|
|
|
What I'd do is the following:
- Attach WinDBG to it ("File->Attach to a Process...", select process then press "OK").
- In the command window (if not visible select "View->Command") type ".dump /ma dumpfile.dmp". Replace "dumpfile.dmp" with a filename of your choice.
This will create a dumpfile so you can look at the problem offline (by selecting "File->Open Crash Dump...").
Steve
|
|
|
|
|
WinDBG is not installed. Can we do something with MSVC++?
thanks!
|
|
|
|
|
Not to my knowledge. You can still attach to the process and debug it but can't create a dump file. For difficult to reproduce errors dump files are invaluable.
Steve
|
|
|
|
|
Can we attach WinDBG when MSVC++ has already got control over the crash? After attaching WinDBG, we have to click OK on the MSVC++ Runtime error popup, right? I just want to confirm because once we click OK, we loose the control.
thanks!
|
|
|
|
|
If you've already got a debugger attached you will not be able to attach another (you could try a "noninvasive" attach with WinDBG, this might work in this case). If you've already got a debugger attached just break execution and get a callstack (you may need to hunt for the right thread). Either way don't dismiss the dialog. The callstack, which will include the call that is displaying the dialog, contains the information you need. It will contain a call to "__purecall". The tricky bit will be figuring out how this happened - Probably calling a global function that calls a virtual function from the constructor of a partially constructed object.
Steve
|
|
|
|
|
Stephen Hewitt wrote: If you've already got a debugger attached you will not be able to attach another
We have not attached the MSVC++ debugger exlpicitly yet, I only thought the popup is from the debugger that automatically started, but looks like the popup is from the executable itself. Does this mean we can still attach WinDBG and take a dump?
thanks!
|
|
|
|
|
Yes. If the problem is hard to reproduce a would take a dump (no pun intended). That said a simple stack trace of the offenting thread will probably do. Look for a call to __purecall followed by a MessageBox call. The frames just before the __purecall should shine some light on your problem.
Steve
|
|
|
|
|
Thank you very much for the suggestions. The error has happened on a remote computer, and I have asked the remote user to send me the call stack. Let's see if I will be able to figure out the cause of the error.
thanks!
|
|
|
|
|
Attach a debugger and then look at the call stack. The last stack frame (not counting the stuff that is showing the message box) will be in the CRT function that uninitialized vtbl pointers point to. I forget the exact name, it's something like __purecall() . Just go up the stack and look for calls to virtual functions.
--Mike--
Visual C++ MVP
LINKS~! Ericahist | NEW!! PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
- i wrote a win32 app to get text from a combo box , it worked fine except when i tried to test it with my google toolbar combobox it returned only the first char in each row !
does that have to do anything with unicode ? , how can i fix itto get the whole string not just the first character ?
|
|
|
|
|
If you're interpreting a unicode string as an ANSI string this is exactly what will happen - How exactly are you getting the text?
Steve
|
|
|
|
|
I am getting it like this :
SendMessage(clickedWindow , CB_GETLBTEXT , i , (LPARAM)buffer[i]);
where buffer is of type TCHAR
|
|
|
|
|
Try code like this (it should return the text in ANSI):
char buffer[256];<br />
SendMessageA(clickedWindow, CB_GETLBTEXT, i, reinterpret_cast<LPARAM>(buffer));
Or if you always want it in unicode:
WCHAR buffer[256];<br />
SendMessageW(clickedWindow, CB_GETLBTEXT, i, reinterpret_cast<LPARAM>(buffer));
In short, let the system do the conversion for you.
Steve
|
|
|
|
|
ahmed_barakat wrote: (LPARAM)buffer[i]);
...(LPARAM)buffer)
Jesus Lives Forever - Amen <marquee direction="up" height="40" scrolldelay="10" step=".5" scrollamount="1" style="background:#99ccff;border-bottom:thin solid 1px #6699cc">
--Owner drawn
--An eye for an eye makes the whole world blind.
--Jesus is Lord
|
|
|
|
|
At first I thought that but the [i] bit made me think that perhaps buffer is an array of pointers to buffers.
Steve
|
|
|
|
|
Almost certainly a unicode string, seeing as the second byte would be a 0 ( which would be regarded as a null terminator ). Use USES_CONVERSION and W2A to convert it.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Hi,
I need to find out, programmatically, what is the name of the machine's OS Administrators group.
I.e. Administrators for English OS, Administrateurs for French OS and etc.
How can I achieve that ?
Thanks!
--
Thank you!
|
|
|
|
|
Call CreateWellKnownSid() to make a SID for the admin group, then call LookupAccountSid() to get the name. (CreateWellKnownSid() is on XP only)
--Mike--
Visual C++ MVP
LINKS~! Ericahist | NEW!! PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
Assuming that I know my program will not need to dynamically allocate more than 5 pages of memory(5*4096),Can I use this function for my memory allocations ?This function gets a pointer,number of bytes requested and returns the address of memory(in p).If failed returns 0.
The first time this function is called it reserves 5 pages of memory and saves its start address in "bm" variable.and commites one page of those pages."l" variable acts as a counter(accumulator) that ranges from 0 to 4096(one page size);I used this to to decide when to commite a new page.(when the size requested by the "size" parameter plus "l" exceeds 4096)and to return the next address to the caller(p=(char*)m+l)."m" variable is start address of the commited page.Memory is returned in the "p" parameter.
In short this function commites 1 page ,returns requested addresses from that page until reaches the end of the page where it commites another page.
According to my assumption can using this function cause trouble in my application or not.
I tested this function for allocating int ,double,string data types and struct and this worked.I mean I could write to the returned address and read the written values.I would have used "npr" and "npc" variables to keep the count of reserved and comitted pages respectively but accoring to my assumption I found them useless.
Please evaluate the function and tell me the probable problems that you think can occure when used.Or any suggestion ,experience you may have .Guide me
(consider my assumption)
int mem(void* &p,int size)
{
static void * m=0;
static void * bm=0;
static int l=0;
static int npr=5;
static int npc=0;
if(bm==0)
{
bm=m=VirtualAlloc(0,5*4096,MEM_RESERVE,PAGE_READWRITE);
if(m==0)
return 0;
m=VirtualAlloc(m,4096,MEM_COMMIT,PAGE_READWRITE);
}
if(size+l>=4096)
{
if((m=VirtualAlloc((char*)m+4096,4096,MEM_COMMIT,PAGE_READWRITE))!=0)
{
l=0;
l+=size;
p=m;
}
else
return 0;
}
else
{
p=(char*)m+l;
l+=size;
}
}
-- modified at 17:26 Monday 30th January, 2006
|
|
|
|
|
Why are you doing manual virtual memory management for such a small amount of memory? If having a statically-allocated buffer is the goal, just do new BYTE[5*4096] and use that.
--Mike--
Visual C++ MVP
LINKS~! Ericahist | NEW!! PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
Hi Mich
You mentioned a nice point,I wouldnt have thought of that.
Yes your right for small amount of memory its not a good way.But how about when I was to use larger blocks(for example: 100*4096).Does it work fine for that case ?
Though your right but allocating such small memory dynamically can have an advantage; Pages are not allcoated in physical memory until they are really needed.(Reserved memory is not allocated in physical memory till commited).
Thanks for your reply.
-- modified at 18:01 Tuesday 31st January, 2006
|
|
|
|