Using TZEdit on Windows SP, SP2, SP3 for Daylight Saving Time (DST)
If you’ve got some older systems or a new netbook that can’t quite handle Vista , you might be hanging onto Windows XP longer than you thought. Out of the box, XP and the new DST changes don’t get along. As a result of The U.S. Energy Policy Act of 2005, the United States (that’s where I am) has an extended daylight saving period that lasts 3-4 weeks longer than in years prior to 2007. But there’s a fix!
There’s a handful of ways to update your computer so that it supports the new DST dates: downloading an EXE update, manual registry changes, TZEdit, and some others. For a single machine, I found the most straight-forward way to update your machine is through TZEdit.
- Download TZEdit.
- Run TZEdit.exe to extract it to the default directory (C:\Program Files\TZEDIT).
- Run C:\Program Files\TZEDIT\TZEdit.exe.
- The timezone configured on your machine should be automatically selected.
- Click the Edit button.
- Change the Start Day to the Second Sunday of March at 2:00am.
- Change the Last Day to the First Sunday of November at 2:00am.
- Click OK.
- I found to get the settings to stick I had to change time zones in the Date and Time Properties window (the window that pops up when you double-click the time in the tray). Change to some other time zone, and then change back to your original time zone.
- Now reboot.
- To test, change your date/time to the second Sunday of March at 1:59:59am. If all went well, you should “spring” forward to 3:00am.
If you’d like more technical information on more advanced configuration, jump over to Microsoft’s Help Page.
To receive updates on new articles, subscribe to CRF Design today!
Similar Posts:
- Remap keys, map caps lock to control button
- Hibernate is missing in Windows XP
- MySQL increasing ID manually
- Benefits of form versioning
- Dealing with mid-study changes (data model)
Remap keys, map caps lock to control button
The caps locks key is one of the least commonly used keys on my keyboard… until I mapped it to a control key! I’m posting this here mostly for selfish reasons. Every time I redo a Windows installation, I end up googling around for the registry hack to make this happen. Putting it here, just makes it more convenient while saving time for anyone else looking to do the same.
A lot of the registry hacks available online for remapping the caps lock and control button involve swapping their functionality or swapping other keys. I have absolutely no use for a caps lock button, so I just map the caps lock button to a control button and leave the control button in the bottom-left corner alone.
- Fire up the Registry Editor by clicking Start Menu > Run.
- Type in regedit, and hit enter.
- Browse to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout. - Click on Keyboard Layout.
- Right-click in the table on the right, and click New > Binary Value.
- A new value will be added in the table. Name it “Scancode Map” without the quotes.
- Double-click on the new “Scancode Map” value.
- A window titled “Edit Binary Value” will pop-up.
- Enter:
00 00 00 00 00 00 00 00
02 00 00 00 1D 00 3A 00
00 00 00 00 - No need to enter the spaces. They will be automatically inserted as the numbers are entered.
- Click OK to save your changes.
- Now reboot.
- After rebooting, your caps lock will now act as a control button!
Check out the Microsoft Documentation if you’re looking for a more complete technical description of what all the HEX values mean.
To receive updates on new articles, subscribe to CRF Design today!
Similar Posts:
- Using TZEdit on Windows SP, SP2, SP3 for Daylight Saving Time (DST)
- Future of notebooks, Dell Latitude XT Tablet PC
- MySQL increasing ID manually
- Hibernate is missing in Windows XP
- 5 Common Mistakes for Tablet PC Development
5 Common Mistakes for Tablet PC Development
Okay, so you’re sold on a Tablet PC, but what should you watch out for when developing a Tablet PC application in healthcare?
Below is a list of common mistakes for developing a Tablet PC application. All are avoidable early in the project’s life-cycle. Some of these mistakes I own, and others I’ve seen from other project managers and developers. Hopefully, this list helps others avoid these common mistakes.
There are already plenty of re-hashed lists on the Internet describing how to address goal setting, client and stakeholder buy-in, or various software and management anti-patterns. This is not one of those lists.
Mistake 1 - I need to learn another operating system
Mistake 2 - It looks fine on my machine, so it’ll look fine on the tablet
Mistake 3 - It’s just Windows, so I don’t need to worry about fonts
Mistake 4 - It works in notebook mode, I don’t need to worry about slate mode
Mistake 5 - 3-hour battery life is more than enough
Bonus - I’ll think about security when it’s up and running
Mistake 1. I need to learn another operating system. Some programmers (and some clients) still think Tablet PCs use a special mobile operating system with its own set of SDKs and APIs. Currently, the majority of Tablet PCs run Windows XP (with Tablet PC enhancements) or Vista (which has the core Tablet PC functionality built-in). Although development tools specific to the Tablet PC such as Digital Ink and the Text Input Panel are available, no one says you have to use them. Most applications you use on your desktop or notebook will work just as well on a Tablet PC.
Bottomline: No new OS, just some added libraries for Windows.
Mistake 2. It looks fine on my machine, so it’ll look fine on the tablet. Okay, great! It’s just a vanilla Windows machine with some extra bells and whistles. I can just develop my application on my workstation, and then deploy it when I’m done.
Almost — like any kind of development, it’s important to test in the environment where it will be used. Some times this isn’t possible, but hey, you’re developing for a tablet, it only makes sense to at least test it on a tablet. Microsoft does offer some emulation software (with limitations) that tries to duplicate a tablet environment, but nothing can replace testing it directly on your target system.
Probably the biggest time-saver is having a development environment that mirrors the screen resolution of the Tablet PC. If the monitor is the right size and it can rotate, you’ve got a winner! Tablet PCs often have an extra wide or extra tall screen, and they can change between notebook and slate mode. With the right monitor, you won’t need to deploy to a tablet every time you tweak something just to see if your application looks okay.
Bottomline: Make sure to test on your target system, and shell out the money for the right monitor. The development time you save will be well worth the cost.
Mistake 3. It’s just Windows, so I don’t need to worry about fonts. This one is a killer. Font size is probably the last thing I would worry about. Unfortunately, I’ve seen some good applications completely tank in front of the customers just because of font size.
Windows should keep the font size consistent whether it’s on a desktop, notebook, or Tablet PC. And… it does. Tablet PCs, just like desktops and notebooks, come in a variety of resolutions. Imagine squeezing everything on your monitor into an 10-12″ screen at the same resolution. Changing the resolution fixes the situation in a way, but then those magnified resolutions don’t take advantage of the added width or height of a tablet PC. And the accessibility settings? …the “Extra Large Fonts?” Another no-go. Because you’re starting out with a smaller screen, the font size difference isn’t substantial enough to make much of an improvement to the user. Try it, and you’ll see.
It really doesn’t seem like much of an issue, except when you’re working with an older user. If they can’t read the text, forget all the Ink widgets and latest technology you implemented, because your application is now considered completely useless by the people who should be using it. Make sure to use larger fonts (18pt worked for me!) in your application, or better yet, allow the user to adjust the fonts within your application.
Bottomline: If they can’t read the application text, don’t let the door hit you on the way out. Use larger fonts or let the user decide what font to use.
Mistake 4. It works in notebook mode, I don’t need to worry about slate mode. Most developers work on monitors that are wider than it is tall. So naturally, you’ll find yourself developing your Tablet PC applications in that environment. You’ll also find that you tend to work with the tablet in the notebook mode as well.
Not much harm in that, until you switch to slate mode. If your application GUI objects took advantage of the extra screen width, those objects will now either be off the screen or squeezed into about half the space. A number of techniques exist to leverage the added width or the added height, but I’ll leave that for another post.
Bottomline: Make sure your layout works in both notebook mode and slate mode.
Mistake 5. 3-hour battery life is more than enough. The battery is not so much a software development issue. However, if you’re taking ownership of developing a Tablet PC application, understanding whether the customer’s needs are met by the selected hardware is at the the top of your list. If the hardware doesn’t fit the customer’s needs, your application will never get used by anyone but you.
Learning how the customer uses the tablet is essential. Will they be running around all day in the wards? Are they traveling from site to site? Will they require Wi-Fi (battery drainer!)? If any of these are true, you’ll need to get extra battery packs. After getting the extra packs, either detail an SOP for swapping out the battery after hibernating the tablet, or better yet, start the project with tablets that have hot swappable batteries!
Bottomline: Understand in detail how the tablets will be used with regard to battery life. If 3 hours is not enough, make sure the users understand how to swap in a fresh battery.
Bonus: I’ll think about security when it’s up and running. I know, I know… I said 5, but I thought I’d throw in this one, since it’s a show-stopper. A tablet, just like a notebook, is meant to be portable. The price we pay for this convenience is it’s also a very good target for theft.
If a tablet containing patient data is lost or stolen, the law requires those patients be notified. The healthcare professionals responsible for the loss will be in a world of hurt and paperwork, but it doesn’t stop there. Your application will also come under scrutiny. How do you secure the protected health information? Is the patient data de-identified? How? What data was lost? Who else has seen that data? And that’s just for starters! As a first step, I recommend full disk encryption. TrueCrypt has worked well for me, and here’s list of full disk encryption providers.
Bottomline: Security, especially for tablets in a healthcare environment, cannot be an afterthought, it must be integrated into the design process.
So, there’s my 5. Hopefully it’ll save you guys the need to find them out on your own. Happy tablet hacking!
To receive updates on new articles, subscribe to CRF Design today!
Similar Posts:
- Portrait vs Landscape, CRF Design for a Tablet PC
- Future of notebooks, Dell Latitude XT Tablet PC
- OpenClinica takes open-source community by storm
- Dealing with mid-study changes (data model)
- Hibernate is missing in Windows XP
Free iPHR Market Report from Chilmark
Chilmark Research is offering a FREE 20-page iPHR Market Report (Executive Summary). You’ll need to enter your email address and address info, but that’s it!
The full report is a 200+ page report going for just a little under $2,500. The full report consists of 3 chapters and an appendices. The free report only includes chapter 1 (Executive Summary). Nothing wrong with that, because that’s exactly what they advertised. Chapter 2 (Market Trends) and chapter 3 (iPHR Vendor Profiles) are not included. Too bad…
To receive updates on new articles, subscribe to CRF Design today!