|
|
Does anyone has an idea why the diff = difftime(my2, my1); fragment in the following code returns always zero?
char date1[60], date2[60];
struct tm mytime, mytime2;
time_t my1, my2;
mytime.tm_isdst = -1;
mytime.tm_year = 2006;
mytime.tm_mon = 1;
mytime.tm_mday = 1;
mytime.tm_hour = 0;
mytime.tm_min = 0;
mytime.tm_sec = 0;
my1 = mktime(&mytime);
strftime(date1 ,60 , "%x", &mytime2);
mytime2.tm_isdst = -1;
mytime2.tm_year = 2006;
mytime2.tm_mon = 1;
mytime2.tm_mday = 3;
mytime2.tm_hour = 0;
mytime2.tm_min = 0;
mytime2.tm_sec = 0;
my2 = mktime(&mytime2);
strftime(date2 ,60 , "%x", &mytime2);
diff = difftime(my2, my1);
printf(date1);
printf(date2);
printf("Difference in seconds: %f\n", diff);
Regards,
Deian
|
|
|
|
|
Deian wrote: strftime(date1 ,60 , "%x", &mytime2);
Should probably be:
strftime(date1 ,60 , "%x", &mytime1);
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Hello David,
the problem line is diff = difftime(my2, my1);
no matter what date I construct, it always returns 0.
strftime(date1 ,60 , "%x", &mytime1); just put's the date in the date1 variable for display, ignore this typo.
|
|
|
|
|
Deian wrote: the problem line is diff = difftime(my2, my1);
No, the problem is with both calls to mktime(). Notice that my1 and my2 will both be -1 because you are using an invalid year. It's always handy to check the return value of a function. 
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Thanks for the help David,
1) The actual problem was me overlooking the struct tm structure
2) Under Dev-C++ IDE, the program compiles, but the mktime/difftime functions are not working correctly. Pasting the same code over VC++ 6 IDE results in working app, with correct calculation of the period passed to both functions.
Regards,
Deian
|
|
|
|
|
You haven't properly initialised the tm structs.
In details:
(1) you missed the initialization of the following members:
tm_wday
tm_yday
i.e. the day of the week and the day of the year. [MODIFIED: seems this step is not required].
(2) If you intend to indicate the year 2006 then you have to set tm_year=106.
(3) the month is (like the day of the week and the day of the year) 0-based. So tm_mon = 1; indicates february (not january) .
(4) About tm_isdst, I don't know, maybe correct.
Please note also the error found by David.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CPallini wrote: (1) you missed the initialization of the following members:
tm_wday tm_yday
(3) the month is (like the day of the week and the day of the year) 0-based. So tm_mon = 1; indicates february (not january) .
(4) About tm_isdst, I don't know, maybe correct.
These have nothing to do with mktime() failing, however. It all had to with mtime() interpreting the year as 3906.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: These have nothing to do with mktime() failing, however. It all had to with mtime() interpreting the year as 3906.
Yes, as well as
DavidCrow wrote: strftime(date1 ,60 , "%x", &mytime2);
the OP was a bit confused, I though opportune to point out all the mistakes (related and unrelated) as well the possible mistakes, to help him to have a better understanding of the matter.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Hi,
I have a CDialogBar derived dialog which is automatically resized by the OS when the user switches from standard size (96dpi) to 120dpi. The problem is, that only the CDialogbar is dependend from the font sizes, and all the other CToolbars have the standard size.
Is is possible to prevent the dialog from being resized by the OS? Maybe by setting the fontsize permanently for the dialog to -11 ?
Thanks
|
|
|
|
|
madmax0001 wrote: Is is possible to prevent the dialog from being resized by the OS? Maybe by setting the fontsize permanently for the dialog to -11 ?
you have to associate the CFont class of Font Size 11 with all member of Dialog Text
"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
Support CRY- Child Relief and you
|
|
|
|
|
I use ::ShellExecute() function for run some application
but I don't know when I want to close it how I write the code.
What's function use for this issue?
|
|
|
|
|
You can use TerminateProcess() but the spawned process should terminate itself.
You don't have any way to know what state the other process is in when you use TerminateProcess().
Mark
|
|
|
|
|
As you say, "you don't have any way to know what state the other process is in when you use TerminateProcess()." In particular, you don't know if it's in a safe state to terminate. For example, it could have half written out a file and when killed the file is corrupted. Way too many people use TerminateProcess as if it's an acceptable way to close a process; it's not - only when all else fails.
Here's what MSDN has too say on this issue:
"The TerminateProcess function is used to unconditionally cause a process to exit. The state of global data maintained by dynamic-link libraries (DLLs) may be compromised if TerminateProcess is used rather than ExitProcess.
TerminateProcess initiates termination and returns immediately. This stops execution of all threads within the process and requests cancellation of all pending I/O. The terminated process cannot exit until all pending I/O has been completed or canceled.
A process cannot prevent itself from being terminated."
Don't get me wrong, I know you did allude to this in your post. I like to point this out explicitly however as not to accidentally encourage bad practice.
Steve
|
|
|
|
|
Thanks man! I knew and when I reread my post I thought the point got lost in the first
sentence.
Apparently I'm not the only one who thought so
Hopefully the OP will read this too!
Cheers,
Mark
|
|
|
|
|
Max++ wrote: I use ::ShellExecute() function for run some application
but I don't know when I want to close it how I write the code
You can post to the application the WM_CLOSE message (to close it gently), provided you can obtain the application main window handle.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
if the application handles that message and decides not to close, the OP won't be able to enforce with this...
|
|
|
|
|
Actually you should first try to close gently the application and then, if the application doesn't close itself, force it to close abruptly using TerminateProcess(). Even Windows conforms to this behaviour when needs to close applications (for instance when a shutdown is issued).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
but how to know that a "gentle close" failed ?
|
|
|
|
|
In fact there are a lot of ways. If you created the process then you can use GetExitCodeProcess (because you have the process handle).
On the other hand, if you haven't the process handle, you can use the window handle to discover if the window is already alive, if the application is hung, etc.. (for instance using SendMessageTimeout().
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
The best way is to use WaitForSingleObject on the process HANDLE. Process HANDLEs are waitable objects which become signalled when the process they represent no longer exists.
Steve
|
|
|
|
|
Yeah, provided you need to wait for.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Use WaitForSingleObject on the process HANDLE. Process HANDLEs are waitable objects and they become signalled when the process no longer exists.
Steve
|
|
|
|
|
|
Max++ wrote: What's function use for this issue?
What about sending WM_QUIT message to particular application
"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
Support CRY- Child Relief and you
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
