27 July 2013

Beware of a pitfall when reading the OS X clipboard with the Carbon API

This is a heads-up for all those who read the Clipboard with the Carbon API (e.g. PasteboardCreate).

This is about rare but possible issue where you might be reading the clipboard contents incorrectly.

A very simple demo for this is the following:

  1. Open Automator to create a new Workflow.
  2. Add a Run Shell Script, with the command: ls -l /
  3. Add a Copy to Clipboard.
  4. Run it.

Launch TextEdit and Paste into a document. You should be seeing the listing of your root folder.
That's what is expected.

Now try your Carbon app and see what it takes from the same clipboard.
Does it only see one line of the clipboard ("total NNN")? Then you're subject to this issue.

Well, here's the explanation: That darn automator operation puts each line as a separate item into the pasteboard instead of putting all lines into a single text item. (The Finder does that, too, if you Copy a multi-selection of files.)

The fact that this Automator operation does it this way is suggesting that other NeXT (Cocoa) based apps may do the same, so you better be prepared for it.

To deal with this, you'll have to iterate over all items (whose count you find via PasteboardGetItemCount), and concatenate them with a line delimiter in between.
Or use NSPasteboard and get the NSStringPboardType, which contains all in one, with the proper delimiters.

Note: You can access the pasteboard using any of the 3 APIs (Scrap Mgr, Carbon Pastebaord, NSPasteboard) at the same time. E.g., if you put a new item into the Carbon Pasteboard, it becomes instantly available to the other APIs as well. Meaning that the 3 pasteboards are fully synchronized.

Therefore, you could just handle this special case like this, provided you're interested in text:

 if PasteboardGetItemCount() > 1 then
   txt = [[NSPasteboard pasteboardWithName:NSGeneralPboard] dataForType:NSStringPboardType]

Finally, a blog from a coder!

Hello visitor,
This is a short intro about my background and what you can expect from this blog in the future.

I've been programming for over 30 years now. Started with programmable calculators, then chose to go to the school in my town that had the first computer, i.e. a CBM 3032, eventually could afford a VIC-20, C-64, Atari ST, and many Macs since. Had a few Windows PCs, too, mainly for gaming.

I tried earning my money with designing my own software from early on. Had and still have to do contract work to get by, though.

My passion (in programming) is with tools. My earliest programs were a machine level debugger (for 6502, later the same for the Gepard and Atari ST computers) and a disk copy program (F-Copy 64). I also worked intensively on a 68000 OS, later maintained a complete Modula-2 development system. For a while, I also worked on low level software and drivers (e.g. Joliet and UDF file systems for Mac OS, HFS drivers for iPodLinux), until I discovered the programming system REALbasic (formerly Crossbasic, then Real Studio, now Xojo), short RB. REALbasic is my preferred programming system for several reasons:

  • It has all the basic building blocks of a modern programming languages (well, I'm still waiting for lambda expressions and/or ObjectiveC-like blocks).
  • It lets me create a program with a simple user interface very quickly.
  • It is cross-platform (Mac, Windows, even Linux).
  • It supplies its own scripting engine which I've used many times to make complex development tasks much simpler.
  • It's quite flexible, allowing me to add native C/C++ code via external libs or plugins.
There's also a few things I strongly dislike about Xojo, and not because I just am a hater but because I feel that Xojo has made a few bad design decisions that they could have avoided had they been giving it more thought or just asked someone for advice who had more experience in this field, i.e. me, for example). You'll most probably learn about a few of them if you keep reading this blog.

Because of my long experience with programming tools I also have a quite good understanding of how RB works internally. I understand quite well how both the framework and the compiler work. I've been able to identify or even fix bugs in RB that even RB's own developers were unable to find, in some cases.

Based on this knowledge I started writing tools for RB, which eventually evolved into Arbed, a editor that offers a lot of functionality that Xojo's IDE does not offer. My goal for this blog is to frequently give tips for using Xojo more effectively with the help of Arbed.

I suck at visual design, so I don't even try. You'll probably know this already if you had a look at my website or at my programs.

However, I care for usability and elegance, and I can get quite annoyed if I have to use a program that doesn't follow standards or makes using it unnecessarily cumbersome. Xojo's IDE is a recurring example of that, unfortunately.

I am one of those who chose the Mac platform over Windows for its clean usability concepts and for its rather smart OS technologies (back in the 80s, Mac OS was far superior over DOS, technically).

My native language is German, BTW. I learned a little English in school and only got fairly good at it after living around the turn of the millenium for five years in Carlifornia, USA. Still, I keep making grammatical mistakes or use incorrect idioms. Feel free to let me know about them, I don't take offense at being corrected, I rather try to welcome it.

See my website for more about my work and musings: http://www.tempel.org/