-
October 6th, 2015, 05:28 AM
#1
Problem with COleDateTime in some of the 64-bit PCs
I am facing this issue of COleDateTime in one of the client PCs that is 64-bit. Where I tried to use this section of the code to see what dates are stored in the string.
Code:
strDate = _T("Date Now: ") + dtNow.Format(_T("%d-%b-%y")) + _T(" Date Installed: ") + dtInstalled.Format(_T("%d-%b-%y"));
MessageBox(0, strDate, L"Error 1", MB_ICONEXCLAMATION);
It simply showed me messageBox Invalid date time. for both dtNow and dtInstalled. Despite the fact that dtNow has been initialized with current date and time whoiole dtInstalled takes a value. In my local PC it works but in one of the client's PC which too is 64-bit it showed that message.
can someone help me in troublshooting this issue?
-
October 6th, 2015, 09:00 AM
#2
Re: Problem with COleDateTime in some of the 64-bit PCs
How do you assign the current date/time?
I'm thinking that your problem might be caused by language settings on the PC, or different versions of the MFC dll files.
Try static link your app with MFC, and ensure you have same regional settings everywhere.
Nobody cares how it works as long as it works
-
October 6th, 2015, 11:38 PM
#3
Re: Problem with COleDateTime in some of the 64-bit PCs
Originally Posted by zerver
How do you assign the current date/time?
I'm thinking that your problem might be caused by language settings on the PC, or different versions of the MFC dll files.
Try static link your app with MFC, and ensure you have same regional settings everywhere.
Code:
COleDateTime dtNow(COleDateTime::GetCurrentTime());
Code:
COleDateTime dtInstalled = COleDateTime::GetCurrentTime();
CopyMemory(&dtInstalled.m_dt, szUnpacked + 16, 8);
Every end user will have different time settings, I can'nt ask everyone to change the regional settings. Its an ATL COM Application, not MFC, how can I static link it with MFC?
-
October 7th, 2015, 02:52 AM
#4
Re: Problem with COleDateTime in some of the 64-bit PCs
Originally Posted by maverick786us
Code:
COleDateTime dtInstalled = COleDateTime::GetCurrentTime();
CopyMemory(&dtInstalled.m_dt, szUnpacked + 16, 8);
What are you trying to achieve with this CopyMemory call?
Victor Nijegorodov
-
October 7th, 2015, 05:25 AM
#5
Re: Problem with COleDateTime in some of the 64-bit PCs
Originally Posted by VictorN
What are you trying to achieve with this CopyMemory call?
Somewhere in the registry a date is stored inside the registry. That date is extracted inside a string named szUnPacked and then using copy memory I assing that date value into the COleDateTime variable. In my development PC this whole thing works, but in one of the test PC It doesn't I can't debug it there because VC++ is not installed only through messageBoxes I can find out where things get wrong.
Even before copy memory, when I tried to initialize the it with current date, it worked fine in my development PC but in the customer's PC it showed invalid date. This is the source code.
Code:
SYSTEMTIME sysTime;
GetSystemTime(&sysTime);
COleDateTime dtNow(sysTime);
//COleDateTimeSpan ts(1,0,0,0); //in case if you want to add some additional day as you did in your case which is 120
dtNow = dtNow; //Currenttime+ ts;in case if you are adding some
//if you want to specify your format
dtNow.Format(_T("%A,%d-%B-%Y")); // _T("Sat,23-Sep-2015 00:00:01 GMT");//
-
October 7th, 2015, 05:34 AM
#6
Re: Problem with COleDateTime in some of the 64-bit PCs
Originally Posted by maverick786us
Somewhere in the registry a date is stored inside the registry. That date is extracted inside a string named szUnPacked and then using copy memory I assing that date value into the COleDateTime variable. In my development PC this whole thing works, but in one of the test PC It doesn't
You should not use CopyMemory here!
Instead use COleDateTime ctors and/or other COleDateTime methods!
Victor Nijegorodov
-
October 7th, 2015, 05:43 AM
#7
Re: Problem with COleDateTime in some of the 64-bit PCs
Originally Posted by VictorN
You should not use CopyMemory here!
Instead use COleDateTime ctors and/or other COleDateTime methods!
OK I will change that. But why does it find it invalid evein while initializing a COleDateTime with the current time?
-
October 7th, 2015, 06:35 AM
#8
Re: Problem with COleDateTime in some of the 64-bit PCs
Hard to say, but maybe you are corrupting the memory with that CopyMemory stuff. After doing so, anything can happen.
The "8" last in CopyMemory also means you assume a specific size of the object, which is bad practice and could fail.
I recommend you get rid of CopyMemory entirely.
Nobody cares how it works as long as it works
-
October 7th, 2015, 06:40 AM
#9
Re: Problem with COleDateTime in some of the 64-bit PCs
You'd better not mess with COleDateTime internals. In case you need it be saved in registry, save it as string.
Code:
#include <windows.h>
#include <atlcomtime.h>
#include <stdio.h>
#define DTFMT "%B %d, %Y %H:%M:%S"
int main()
{
COleDateTime dt;
COleDateTime dtNow = COleDateTime::GetCurrentTime();
printf("%s\n", dt.Format(DTFMT));
printf("%s\n", dtNow.Format(DTFMT));
dt.ParseDateTime(dtNow.Format(DTFMT));
printf("%s\n", dt.Format(DTFMT));
return 0;
}
Code:
J:\Temp\99>99.exe
December 30, 1899 00:00:00
October 07, 2015 14:39:16
October 07, 2015 14:39:16
Last edited by Igor Vartanov; October 7th, 2015 at 06:42 AM.
Best regards,
Igor
-
October 7th, 2015, 07:27 AM
#10
Re: Problem with COleDateTime in some of the 64-bit PCs
Originally Posted by zerver
Hard to say, but maybe you are corrupting the memory with that CopyMemory stuff. After doing so, anything can happen.
The "8" last in CopyMemory also means you assume a specific size of the object, which is bad practice and could fail.
I recommend you get rid of CopyMemory entirely.
even if u comment the copy memory section the basic initialization with current time is making it look invalid on that particular PC
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|