Having to work in the dark ages is never fun. My new .exe in Microsoft eMbedded Visual C++ 4.00.1610.0 was providing that experience when I couldn’t get to the Version tab when I invoked the file properties of my .exe in Windows Explorer. The Version tab just wasn’t there. Looking at working projects provided no clue. Turns out in my very thin .exe, when the resources were being compiled, it wasn’t picking up the define for VS_VERSION_INFO. Instead of complaining it happy converted it to a string: “VS_VERSION_INFO”. To get this to work I had to add “#include <windows.h>” to the resource.h file. After a full recompile the Version tab now shows up.
Occasionally you’ll have a technical problem and a Google search fails to provide you a fix. In this case a lot of the information was too old.
I was forwarded a voice mail from a Driod Incredible (a .qcp file). I needed to play it in Mac OS X. My google search offered:
- Windows Media Player will play it natively (No in 9 and No in 11)
- Quicktime (No)
- Qualcomm has a player (it has been pulled from their site for legal reasons)
- Various downloads to try on my PC but none panned out (should have done this testing in a VM so I could have easily rolled back the changes).
In the end, I tried it in VLC (Version 1.0.5 Goldeneye (Intel 32bit)) on the Mac and it worked. I wasn’t able to drag and drop the file but was able to use the Open dialog. Worked in VLC on the PC too. Is this a harbinger of things to come? Having to work with qcp files?
Your mission? Download the latest drivers from Linksys for the WPC11. Good luck with that. It’s like playing driver roulette. Also, what’s up with the ever increasing font size?
You’re in the middle of copying a large directory between drives. You are then presented with this “Destination Path Too Long” dialog:
Thoughts that come to mind:
- Can’t I rename it now?
- Can’t Windows rename it now?
- Can’t Windows show me a list of all the files that fall into this category?
- Can’t Windows present the offending files in a dialog where I can copy the filenames and paths for easier resolution?
- Does Windows really have to bring the copy to halt because of this? It’s already copied a lot of data – what’s the harm if it continues the copy? If I cancel later what’s the harm? Instead the machine is left waiting for me.
Let’s say the user really does want to continue the copy. Here’s the scenario they’re confronting:
- Write down the filename(s!)
- Press Skip and continue to babysit the long copy for other offending filenames.
Once the copy operation is “complete”, here’s the next steps:
- Search for offending file on the source drive
- Rename offending file
- Find the location on the destination drive
- Copy file to new destination
- Repeat this process for every offending file.
Ugh, no thanks.
In Microsoft Windows (all versions), I always found it annoying and disconcerting to see generic icons in Windows Explorer one moment replaced by official/pretty icons the next when starting up or first opening an Explorer window. It just enforced the “lipstick on a pig” feeling you sometimes got in Windows.
Well, Snow Leopard 10.6.0 is doing it now. And does it a lot. At first I thought it was a caching issue but it’s not. And in the screenshot accompanying this post two of the icons never switched over (Address Book.app and Airfoil.app) until I went to a different directory and came back to /Applications. This must be a side affect of rewriting the Finder. It’s sloppy and doesn’t give me a “rock solid” feel like 10.5.x (and before) where you never saw this happen.
Windows 7 has the USB-to-Serial driver for my never-released development board. Hmmm. I’m good, but I’m not that good.
We’re using the Atmel AT91SAM 32-Bit ARM7 chip on a development board. Apparently so is Wonde Proud because Windows 7 thinks my development board is their GPS Camera Detect. Wonde Proud forgot to change the USB Vendor ID and Product ID from the sample code provided to them (and me) from Atmel. A classic mistake. I just wish they had done the same for 64-bit Windows 7 so I could use my hardware over on that platform – it would save me some time.
I created a Windows 7 Enterprise 32-bit VM and a 64-bit VM. I wanted to see which provides better performance. Since VMware Tools aren’t ready I treaded lightly with my tests. Other caveats: VMware Fusion does not support Windows 7 yet. These are PassMark tests and not real world tests. I didn’t run endless tests – just a handful. Your milage may vary (greatly!). The performance is based on Win7 32-bit (32/32). The results are:
Win7 64-bit Running PassMark 65-bit (64/64)
29% faster on CPU
178% faster on 2D graphics
36% faster on Memory
19% slower on disk operations
Win7 64-bit Running PassMark 32-bit (64/32)
11% faster on CPU
13% faster on 2D graphics
11% faster on Memory
35% faster on disk operations
I was perplexed on the 64/64 disk performance being slower than the baseline and re-ran the test a handful of times and got similar results. 64/64 2D graphic results were impressive but not a driving factor for me. For CPU and Memory 64/64 showed a nice bump over 32/32 and even 64/32. In the end, the issue of whether to move to 64-bit Windows 7 is moot for me – the driver I need is only available in 32-bit so I’ll be running 32/32.
Here are all the versions used in the testing:
VMware Fusion Version 2.0.5 (173382)
Microsoft Windows 7 Enterprise [Version 6.1.7600]
VMware Tools for Windows Version 7.9.6. build-173382
PassMark PerformanceTest 6.1 (1010) WIN32
PassMark PerformanceTest 6.1 (1018) WIN64
Here’s a classic example of a seemingly easy problem actually being harder to implement. I wanted a dialog with white static controls in MFC. The resulting code is simple but divining the answer was no easy feat. Ultimately it’s more a failure of documentation that it is a engineering challenge. More details in my commented code which follows:
HBRUSH TReaderDlg::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
HBRUSH hbr = __super::OnCtlColor(pDC, pWnd, nCtlColor);
// For static controls, draw black text on a white
// background (instead of the default Windows
// dialog background color)
if (nCtlColor == CTLCOLOR_STATIC)
// Set the background color to white
// This is a red herring. You will only affect the text
// drawn and the static control is certainly larger than
// the text drawn so you will have the original color
// "leaking" out. (see pic)
//pDC->SetBkColor(RGB(255, 255, 255));
// Set the background mode for the drawn text to
// If you use SetBkColor with SetBkMode you will further
// compound the confusion/frustrtion. Using
// SetBkMode(TRANSPARENT) after SetBkColor cancels
// out SetBkColor.
// The real solution is to create a brush with a solid
// white background and return that from this function.
// Also set the background mode to transparent.
static CBrush mBrush(RGB(255, 255, 255)); // Solid white brush.
hbr = mBrush;
// Return a different brush if the default is
// not desired
Working in MFC today I wanted to know when the user clicked on a radio button so I could change the default button with SetDefID(IDC_LOAD_MEMORY_BTN) but for some reason after adding the event handler for BN_SETFOCUS I never got a notification. After poking around the radio button’s properties in Visual Studio 2008 I found Notify – changing it from False to True allowed me to start receiving focus events