|
THAT's IT !!!
Thanks alooot Joaquín !
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
I was just wondering if anybody has worked with the CMonthCalControl. I can't seem to get the selected date back to my variables so I can deal with it in different fashions. I keep getting 12/30/1899 which seems to be an unitialized variable.
The funny thing is, I can set the date properly.
Anybody have any ideas?
I've tried it with both m_Calendar.GetCurSel() and by sending a message to the control with a SYSTEMTIME structure.
Thanks for the help,
Nick
|
|
|
|
|
I just happen to have this same problem too! I debugged down to the GetCurSel() and found that even THAT was passing an invalid value.
My cludge consisted of the following:
...<br />
SYSTEMTIME RefTime;<br />
m_CalRef.GetCurSel(&RefTime);<br />
COleDateTime dRef(RefTime);<br />
m_Calendar = dRef;<br />
...
I put this code in a method: CalendarPatch() and called it at the very end of DoDataExchange(). I think there may be some issues with date range of SYSTEMTIME (not as large as COleDateTime (?)), but it works in my application thus far. If anyone can offer an explanation about why the standard implementation fails, I'd appreciate it.
JennyP
|
|
|
|
|
Hi,
I am doing:
if( (stream = fopen( "C:\\myjunk.txt", "r+t" )) != NULL )
{
fseek(stream, 0, SEEK_END);
int nSize = ftell(stream);
fseek(stream, 0, SEEK_SET);
char* list = new char[nSize + 1];
numread = fread( list, nSize, 1, stream );
list[nSize]=0;
m_rich1.SetWindowText(list);
m_edit1.SetWindowText(list);
fclose( stream );
}
In both the richedit and the edit, after all the valid text, I get a line of garbage. What am I doing wrong? How can I fix this?
Thanks,
ns
|
|
|
|
|
My guess is it's not being 0 terminated. You should throw out C style file access and use iostreams instead.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
|
|
|
|
|
Thank you so much. I didnt know much about istream stuff. It works now!ns
|
|
|
|
|
No worries. I have a series of articles here on CP on all the ways iostreams can be extended - check it out sometime. You'll see why I say that they are far superior to C style file handling.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
|
|
|
|
|
I searched under your name and up popped a bunch of cool articles that I will be reading in in the next few days. None of the C# ones, I'm afraid, since I barely have a handle on C++. The STL will be really handy since I use them (nervously).
Thanks again,
ns
|
|
|
|
|
ns wrote:
numread = fread( list, nSize, 1, stream ); list[nSize]=0;
should that not be
numread = fread( list, nSize, 1, stream );<br />
list[numread]=0;
|
|
|
|
|
It was returning numread as 0, the way it is written:
numread = fread( list, nSize, 1, stream )
Changing it to
numread = fread( list, 1, nSize,stream )
and list[numread] =0;
whole o/p was garbage, not just extra line of garbage.
Puzzled, but worked around with istream..
Thanks,
ns
|
|
|
|
|
|
Nope. DIdnt like that either.....
Thanks for the suggestion though.
ns
|
|
|
|
|
Arg. Someone please help because this is driving my crazy!
I have several apps that when I compile them using the win32 release configuration they bomb immediately. I'm downloading SP5 now, and I'm wondering if that will fix it. I've seen this before, and so have other devlopers where I work, but they all fixed it by shipping debug code. Unfortuately, that is not acceptible for the product.
If I can't compile it as release, is there a way to use the debug version, but instead of having the ASSERTS() in the MFC stuff produce a message box, have it bomb or exit right away? (Which would make it acceptible)
Many thanks in advance!
PS. I know it's not my code because according to the stack, it hasn't even entered my code yet:
MFC42! 73ddb4ec()
KERNEL32! 77e7eb69()
|
|
|
|
|
I am pretty sure it is your code . It doesn't have to enter your code to be your mistake. Maybe you are playing with some window handles and it will crash into a mfc code, not yours.
Have a look at this article, maybe you can find why it crashes.
Also you may try to include some debug information in the release mode and step into code to see what is causing the assert. Providing some code will be very helpful.
Best regards,
Alexandru Savescu
|
|
|
|
|
Well, adding to the complexity is the fact that it's an NT service, so it has no main() to speak of. It has an init() and a run() and a stop().
I put very simple MessageBox(NULL, "Running", "NT Service", MB_OK) statements at the very beginning of those and it dies before even hitting them.
What's making it even harder is then ir crashes, that's all thr stak info I have. If it's in my code, I can look at my map file an find what function did it, but I don't have map files ofr MCF42.dll!
|
|
|
|
|
Jason Hihn wrote:
I put very simple MessageBox(NULL, "Running", "NT Service", MB_OK) statements at the very beginning of those and it dies before even hitting them.
MessageBox ? In a service ? It may not appear.
Well, try LogEvent and see the event viewer...
Concussus surgo.
When struck I rise.
|
|
|
|
|
Jason Hihn wrote:
but they all fixed it by shipping debug code
Change jobs NOW. I mean it. You work with utter fools if they ever shipped debug code as a workaround for a bug they could not find.
Jason Hihn wrote:
PS. I know it's not my code because according to the stack, it hasn't even entered my code yet:
You should create an ofstream in your instance constructor, and write out some info to see where it is crashing. It's your code, don't worry about that.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
|
|
|
|
|
Jason Hihn wrote:
PS. I know it's not my code because according to the stack, it hasn't even entered my code yet:
MFC42! 73ddb4ec()
KERNEL32! 77e7eb69()
The fact that you're not on the call stack doesn't get you off the hook. E.G. It could be accessing memory that you released, trying to access a non zero terminated string, or an unavailable resource (ID defined but the actual resource has been deleted)
Debug mode has a lot of safeguards, can have different aligment (different code/object size) and can cause eg an extra int to be available in an array without overwriting data while release build overwrites essential data
so someone should fix the code
You can turn of the debug asserts by undefing _DEBUG, remove it from the project settings c/c++ preprocessor defines (I think this will however also cause linking to the release MFC dll's)
Better yet would be to identify the asserts and prevent them from happening (check it yourself first and then bomb or grace shutdown)
Good Luck
Rutger
|
|
|
|
|
The bounds chekers help me several times in that problem....
one solution is use the dr watson...
Compiles your code with mapfile, look into the file that leave the Dr watson, and llok for in the map file generated... This can help you...
Carlos Antollini.
Sonork ID 100.10529 cantollini
|
|
|
|
|
Jason -
I wish you well my friend. You are about to embark on a painful but eventful journey. My best wishes are with you. I think u can be assured that the bug is in your code.
Sorry I sound like that, but I have been through the hard knocks of debugging a major bug in the release build. I hope you dont have complier optimizations turned on, because then even Dr Watson will confound you. Turn compiler optimizations off and see if you can reproduce the problem. You can turn it back on after finding the bug.
The book "Debugging Windows Applications" (MIke Wooding and Everett Mc Kay) was of immemse use to me. This is where tools like BoundsChecker will prove to be invaluable.
The reward : After you hunt down the bug, you can go out and have a beer. That will be the best beer u ever had.
-
Vivek
|
|
|
|
|
same thing happened to me before, it is problem of libraries used.
did you use database in your apps?
please post a little bit more info: i.e. com, dcom, etc.
includeh10
|
|
|
|
|
Well I've done some investigating...
Looks like it does actually run my code, but only the constructors run. Those are filled with bounds checked string copies and integer initializations. All contructors return ok.
Where the problem lies is when it tries to call StartService() which then goes to ServiceMain(), then to Initialize().
Somehow on it's way to calling StartService, it is bombing. The thing is I can't figure out what is begin called between the constuctors and StartService.
Arg!
PS. It's just a win32 app with sockets (NOT MFC! I'm using wrappers from W3MFC) and a MySQL library.
|
|
|
|
|
When you switch from debig to release mode, rather than inherit settings from the debug mode, (even such no brainers as /subsystem:XXXXXXX) it starts from some dumb defaults which can have nothing do to with your debug mode program.
I had to change from /subsystem:windows to /subsystem console. The really weird thing (and for this I blame Microsoft) is that I had no WinMain(), only a main().
With /subsystem:windows I should have gotten a warning at the least. Now, even so, I'd expect my program to crash (or nto even compile) because there was no WinMain, BUT SOME HOW ONE GOT SUPPLIED TO IT. I accidentaly I ran it on my PC (remember it's a service, it's supposed to be started that way, plus I'm running Win98, which doesn't have full NT-Services) and it put me into a WinMain. Where I came from, I don't know... then I remembered to check the subsystem.
Many thanks to all you who tried to help!
|
|
|
|
|
Jason Hihn wrote:
because there was no WinMain, BUT SOME HOW ONE GOT SUPPLIED TO IT
MFC supplies one. Are you using MFC ?
Concussus surgo.
When struck I rise.
|
|
|
|
|
Jason Hihn wrote:
BUT SOME HOW ONE GOT SUPPLIED TO IT. I accidentaly I ran it on my PC (remember it's a service, it's supposed to be started that way, plus I'm running Win98, which doesn't have full NT-Services) and it put me into a WinMain. Where I came from, I don't know... then I remembered to check the subsystem.
AFAIS from your original post, your app is linked against MFC42.dll. Are you sure you are not using MFC?
I only ask, because it sound quite suitable to me, that MFC42.dll contains your "mysterious WinMain()".
--
Daniel Lohmann
http://www.losoft.de
|
|
|
|