Inspired by this bug report, I just wrote a small, quick and dirty utility to dump the current clipboard content on Windows. Windows development to me is still pretty much an uncharted territory, so even a utility as simple as this took me some time. Anyway, you can download the binary from here: clipdump.exe. Note that this is a console utility, so you need to run this from the console window.
Here is the source code.
using namespace std;
size_t char_per_line = 16;
typedef vector<WORD> line_store_type;
void dump_line(const line_store_type& line)
size_t fill_size = char_per_line - line.size();
line_store_type::const_iterator i = line.begin(), iend = line.end();
for (; i != iend; ++i)
printf("%04X ", *i);
cout << " ";
cout << ' ';
i = line.begin();
for (; i != iend; ++i)
WORD c = *i;
if (32 <= c && c <= 126)
// ASCII printable range
cout << static_cast<char>(c);
// non-printable range
cout << '.';
cout << endl;
void dump_clip(HANDLE hdl)
LPTSTR buf = static_cast<LPTSTR>(GlobalLock(hdl));
for (size_t i = 0, n = GlobalSize(hdl); i < n; ++i)
if (line.size() == char_per_line)
UINT fmt = 0;
for (fmt = EnumClipboardFormats(fmt); fmt; fmt = EnumClipboardFormats(fmt))
int len = GetClipboardFormatName(fmt, name, 100);
cout << "---" << endl;
cout << "format code: " << fmt << endl;
cout << "name: " << name << endl << endl;
HANDLE hdl = GetClipboardData(fmt);
It’s nothing sophisticated, and it could probably use more polishing and perhaps some GUI (since it’s a Windows app). But for now it serves the purpose for me.
Tor has submitted his version in the comment section. Much more sophisticated than mine (and it’s C not C++).
While searching for a debug tool equivalent of strace that runs on Windows, I’ve come across Process Monitor. This appears to work well for me. For anyone in search of strace equivalent on Windows, give this one a try.
I’ve also tried StraceNT, but this one was not very reliable as it tends to crash the traced process almost every time.
An equally useful tool for debugging on Windows is DebugView, which captures output from the OutputDebugString calls.
I guess I don’t really have to tell the world about this, since if you type the title of this blog post in Google it will come back as the top hit. But it’s still worth mentioning msysgit, a pretty darn good git client on Windows. It’s small, it’s efficient, and it’s git. :-) You could of course use git in cygwin, but git in cygwin feels a little “heavy” and by no means small, since you have to get the whole cygwin environment to even use git. So, if you don’t already have cygwin, and want to use git on Windows, msysgit is a pretty good choice. It comes with a minimal bash shell, and while I’m happy to see ssh included with its shell, I was a little disappointed that they left out rsync. But that’s just one minor downside.
For me, msysgit is my git client of choice on Windows, especially in a virtual machine setting where the disk space is tight. On a build machine, though, I still use git in cygwin since I already have to use cygwin to build OOo.
I just released a new version of Calc Solver after more than a year since the last release. A lot of effort has gone into this release mostly to re-package it as a true UNO extension, and also to make it available for the Windows version of OO.o beginning with this release.
The UI has been localized for French and Japanese, thanks to Laurent Godard and Kazunari Hirano. Laurent also helped me on various UNO related issues, so I would really like to acknowledge his help. Thank you Laurent. :-) The system language should be automatically picked up and the appropriate translation texts should be displayed for English, French and Japanese. If this doesn’t work for you, please let me know.
The ride was quite bumpy, however, to get Solver to build on Windows. Since this was my first attempt to build anything non-trivial on Windows, I had to spend a few days (and nights) studying how the MSVC compiler works so that I could build a DLL. There was also an issue with multi-thread vs single-thread libraries, so I had to manually select the default libraries to be all single-threaded for the Solver as well as the lpsolve code. Not to mention I didn’t know how to set up a build environment since GNU make in cygwin didn’t work too reliably due to file path separator and the driver letter issues. In the end, I came up with a custom DOS batch script with everything hardcoded to semi-automate the build process, but that’s far from being elegant. I’m just wondering if there is any better way to set up a build environment on Windows… Question: what do Windows developers use these days to build C++ projects?
On the Linux side, the Solver extension installed and worked fine, but I’ve experienced a major problem with installing it in the Extension Manager UI. But as long as it’s installed from the command line using unopkg, it works fine. I still haven’t figured out why installing with the Extension Manager caused a problem but installing with unopkg didn’t.
Oh I almost forgot. If you use Go-oo version of OO.o (aka ooo-build) or any variant of it with my Solver already included, you don’t need to install this extension. It’s already there in Tools – Solver.
Anyway, enough talk. Enjoy! :-) And please report me any problems you may experience.