Thanks for adding DateTimeInput! I have a bit of a problem with it, though. It converts the entered time into UTC using my local timezone (decreases 2 hours from the entered time). Is there a way to make it simply save the time that's entered?
I didn't find any info about any options this component accepts.
EDIT:
Nobody has any answer to this problem? I'm sure I'm not the only one who wants to be able to store date/time values from the UI "as-is", instead of some automatic conversions.
In our case we enter certain measurement data from different locations. The location of the UI user here is irrelevant and the automatic conversion simply messes things up.
Related
I have one vb.net windows application and I want to deliver it to my client with 1 year validity.
After one year this software will automatically stop working or ask for renewal.
The client PC doesn't have internet access.
Please tell me the secure way for this.
When the program is installed, have it set a registry value with the current date. Then, on every subsequent program start, have it check that registry value against the current time. If more than a year has passed, do whatever you plan on doing to lock up your application.
This post has some excellent info on the specifics of adding, modifying, and accessing registry values in vb.net.
Check the date.
If dateToday > dateProgramSold.AddYears(1) Then
'open form that cant be close saying program is expired
End If
When the program is installed, it should ask for an registration key (they could get it by email, print it off and type it). The key should contain the last day of validity (encrypted). Store the key in the registry (or somewhere else). When the program starts, you check the date inside the key.
If they re-install the end date will stay the same.
When they want to update, just send a new key by email or mail.
The amount of security you put into just could depend on how much you trust the company. Because they could always decompile and crack your software.
I needed to do this for a program I wrote. My final solution included the resolution that you can't be 100% foolproof, so I considered my users and did the best I could with what I had.
Without access to the internet, how does the computer know what date it is? It has to rely on user input for it. So if a user can input it, then a user can change it. There is no foolproof way to get an accurate date from the PC without the the user having access to it. Whether from the OS, the BIOS, etc.
So what I ended up doing was putting an obfuscated key into the registry in an obscure place. HKCU >> Software. I made the key just some letters and numbers {L12A3C0DFF} then I named the key Z0B0 and made the value the obfuscated date. I took the year month and day and ran each one through a different calculation. I ended up with something that looked like DDE011468932.
Each time the program ran it decoded this registry setting to see if a year had passed based on the time in the BIOS. If the date in the BIOS was earlier then this date then they changed it and I would not not allow my program to run.
Also each time the program ran, I checked the date in the BIOS and stored this in the registry in the same way. So I would check to see if they changed the date in the BIOS to an earlier date.
So in order for them to abuse the date restriction of one year, they literally had to change the date in the BIOS every day which I figured was not worth it to them to do, besides, they would have had to figure out where I was getting the date from to begin with, which would take decompiling (and I wasn't selling it to a bunch of programmers). Simply changing the date in the OS wouldn't fool it.
We're using an Access application that stores and retrieves information from SharePoint, and the times and dates get viewed through the 'filter' of the Time Zone settings on SharePoint.
This has started to cause a problem when just trying to enter a date with no time. People marked as CST will see 7/1/2014 0:00, but those in PST will see 6/30/2014 22:00. Calculations that organise metrics by date would then show the same entry in June for PST users and July for CST.
Is there a way to adjust for this? I don't WANT to be capturing a time in this field, but since it's a Date/Time field on SharePoint, it's attaching a time anyway. Would changing the field in question to 'String' work or would that cause more problems than a more adaptive solution?
(I've read links that popped up in 'Questions that may already have your answer', conducted other searches on and off Stack.)
After a bit of testing after all my Users went home except for one, I found that just changing the type on SharePoint for the fields in question from 'Date/Time' to 'Text (Single Line)' worked perfectly. My Tester had no issues with the VB used to store information and bringing up the raw tables showed the 'proper' date stamps after a restart of the client database.
It seems a little too good to be true, but it appears to be a victory! I'll definitely come back here with an update if anything blows up.
I have a PDF which users can download. However, I need to have the date it was downloaded in the text on the PDF.
Is there a way to insert a "date now" stamp on a PDF so it is dynamically added on opening?
Perhaps you can add javascript to a PDF?
You can sign and timestamp the PDF on the server before giving it to the user. Signing can be performed once a day (unless you need finer granularity if timestamp time). This is the only reliable way to put a timestamp to the PDF. Also, the signature can be removed, and if you want to add a watermark which can't be easily removed, this is a different story.
JS sounds like the way to go... mostly.
You could add an empty text field where you want the date to appear. When someone opens the PDF for the first time, you could then set the field's value.
ISSUES:
Reader cannot save changed PDFs unless they have been Reader Enabled via Acrobat.
The script will run when the PDF is opened not when it is downloaded.
If you really want to mark their download time, you need to do it on the server. Fields again, only this time with some byte offset monkeying.
Set the keywords (or author, whatever... one of the Doc Info fields you're not using) to a bunch of empty spaces... enough to accommodate your largest timestamp. In script, when the form is opened, you ALWAYS write that info field to your timestamp field. No worries about reader enabling.
Now, to actually write the timestamp, you need to know the exact byte offset of that info field in your PDF, and you need to know how much empty space you have to work with so you don't accidentally overflow (that would be Very Bad). When the time comes to serve up your PDF, you suck up the bytes, change the ones for your time stamp, and server those modified bytes.
That's the most efficient (and brittle) way to do it.
If you'd rather do things The Right Way, use your favorite PDF library to change the form value and serve up the resulting PDF. No script required, but significantly more work for your server.
Note: Multiple fields can share the same name. They automagically share the same value as well. So if you want the time stamp to show up on every page, you don't need "timestamp1", "timestamp2", and so on. You can give all the fields the same name, then set the value once. "Your favorite PDF library" might not handle this terribly well. iText does, I'm sure others do also.
I used p/invoke GetSystemTime() method in my application to get the current system date time but it is giving wrong values any solution for this..
Ah, time and the CF and WinCE. What fun! Along with all the other fine answers you've received there are other things to know:
The OS stores LocalTime, not UTC so GetSystemTime ends up getting LocalTime and them adjusting that backwards based on your timezone and DST, so if the local time is right but SystemTime is not, then you have a TZ or DST setting wrong.
DST may or may not be right due to congress changing it, so a QFE may be required by the OEM
DST may be on or off in the registry
The CF caches timezone bias as startup, so any adjustment of the timezone renders DateTime.Now incorrect until you restart your app
Not all devices can persist time across a power loss (or even a reset)
Time will "float" throughout the day. how badly (milliseconds to seconds) depends on the actual hardware implementation
Why don't you use DateTime.Now ?
What is the problem?
Is your p/invoke signature correct?
Is you struct laid out correctly?
How are you dealing with the struct pointer being 'returned' ?
If the time returned is off by one hour, then you're running into a Daylight Savings Time bug (which can be fixed with a hotfix).
GetSystemTime returns the Coordinated Universal Time (UTC). You may be looking for just the local time, in which case you want to call GetLocalTime instead (or just use DateTime.Now or DateTime.UtcNow, and skip the PInvoke stuff).
What do you mean by wrong values?
Since you are asking about Windows CE, it might be that your system does not save the RTC and does not sync on boot resulting in not having the correct time at all.
This is platform specific. Is the time and date correct in the taskbar (assuming you have that in the image)?
How do I get the system time using VB.NET and copy it into the clipboard automatically?
Is there a built-in function in VB.NET for this?
I'm not sure what you mean by System Time, but if it's just the string representation of the current time then you can do the following.
ClipBoard.SetText(DateTime.Now.ToString())
This code will work in both Windows Forms and WPF.
Use DateTime.Now to get the time and Google for the code to copy to the clipboard.
Or take a look at this post.
Better use the DateTime.UtcNow method.
It returns time without local format and DST offset.
UTC will keep you out of trouble when storing data.
You can always format to local when export/display is needed.