|
khan++ wrote: You must mean: SM_CXICON and SM_CYICON.
Yeah.
khan++ wrote: I am not sure what you mean by that.
If you have created a dialog based app in vs2003.net then you will know. I wanted the Icon that gets displayed for the control menu of a dialog. But it appears rather odd.
khan++ wrote: HICON hi = AfxGetApp()->LoadIcon(IDI_ICON1);
This returns a 32x32 icon.
Jesus Lives Forever - Amen ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
--Owner drawn
--An eye for an eye makes the whole world blind.
--Jesus is Lord
|
|
|
|
|
I have never loaded a multi-icon icon (not sure about the term). That is: an icon which contains multiple sized icons, like: 16x16x4, 16x16x8, 32x32x4 ... (width x height x bits/pixel) within one .ICO file. You can do a search on it.
As I said in my first reply that you can create a new 16x16 icon resource, and try loading that one.
this is this.
|
|
|
|
|
tray icons are supposed to have a resolution of 16x16 pixels. if you're loading a bigger one windows will shrink it and you'll get some odd artifacts.
so if you want it to be displayed like in your resource editor you need to make it 16x16.
saludos
|
|
|
|
|
|
did you consider that in windows 2000 and former versions, tray icons are only displayed with 16 colors ? (don't mix up with 16 bit colors - cause here you only have 4 Bit which on top of that are pretended by windows)
|
|
|
|
|
|
if you have windows xp, then yes, they have more then 16 colors.
take a closer look to them - in windows 2000 they all use the same bunch of colors, namley 16.
again, only tray icons are affected. icons in the taskbar, quick launch icons, icons in the upper left corner of your app or just the icons on your desktop - they all can use far more colors.
|
|
|
|
|
|
Hi,
I have a string have data of time format. like
strTime = 06:45:18
I want to convert it into time object or store it into time variable ,
Becuase I want to take the time difference between to time that are actualy first stored in strings
thanks
Regards.
|
|
|
|
|
Hi You can use the following function
size_t strftime(
char *strDest,
size_t maxsize,
const char *format,
const struct tm *timeptr
);
size_t wcsftime(
wchar_t *strDest,
size_t maxsize,
const wchar_t *format,
const struct tm *timeptr
);
Wishes.
Anshuman Dandekar
Dare to Dream,
Care to Achieve.............
-- modified at 3:00 Tuesday 31st January, 2006
|
|
|
|
|
|
You are right. String object to time. Do you have any idea how it will be
Regards.
|
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
