Older blog entries for JoeNotCharles (starting at number 32)

W2E Day 2: Morning Presentations

I’ve resigned myself to being a day behind in blogging. I’m just too slow at organizing my thoughts to get them into an order worthy of publishing in the evenings. Better to come at it fresh in the morning.

The shift from Monday’s 3 hour long workshops to yesterday’s shorter presentations was pretty jarring. I kept thinking the presenters were just finishing their introduction and finally about to go into detail – and the talk would be over. So my biggest complaint about a lot of these talks is that they gave such a broad overview that I didn’t really learn much.

How to Develop a Rich, Native-quality User Experience for Mobile Using Web Standards
by David Kaneda of Sencha, a company that was namedropped quite a few times by Jonathan Stark yesterday as the makers of a really high quality Javascript UI toolkit.

I expected this to overlap quite a bit with Jonathan’s workshop, but I wanted to see it anyway because I spoke with David briefly afterwards and I wanted to see how his opinions differed.

He offered quite a few nuggets of info like this interesting graph: in January 2010 the breakdown of US mobile web traffic was 47% iOS (iPhone/iPad), 39% Android, 7% RIM, 3% WebOS (Palm-now-HP Pre), 2% Windows Mobile, 2% Other – so 95% webkit. (Actually David was wrong about that – if these were released in January the RIM numbers would have to be pre-Torch, so that’s only 86% WebKit. For now.) Even at the height of IE’s popularity that kind of homogeneity is new for the web. It means the mobile developers, unlike web developers, are free to target the WebKit-specific subset of HTML5, without worrying about, for a trivial example, including both -webkit and -mozilla namespaced CSS selectors. That’s good because with limited networking, avoiding redundancy is important. I suspect it’s temporary, though, as new features are added and phones diverge in which exact webkit versions they support.

(Of course, this list reflects web usage, not phone ownership: these are the phones whose users spend the most time online. Even still I was surprised to see the Pre passing Windows Mobile.)

Wow, there are a lot more Android phones than I realized. David believes a year from now the basic free phone you get with your mobile account will be a shovelware Android phone, with a touch screen, GPU, etc, and a good browser, so really rich web apps will be available to everyone, not just the high end. (But, as I mentioned above, WebKit will continue to evolve and these phones would be good candidates for lack of upgrade support.)

As I expected, David mentioned a lot of the same things yesterday’s workshops did: he glossed over web storage and form validation (as well as web workers, which everybody seems to mention and then says “but I don’t have time to discuss that”.) He did cover, briefly, the new input types, video/audio (mentioning that video can be styled using the new CSS transforms, which stands to reason but hadn’t occurred to me to try; I assume it doesn’t distort the contents, that would be crazy!), meta viewport tags, CSS3 features, and the application cache manifest. That’s my biggest eye-opener so far – I helped to test the cache manifest in the Torch browser, although someone else did the implementation, and when I read the spec I thought it was ridiculous and would never catch on. But all the mobile app developers here seen really excited about it. It’s a huge pain in the ass to use, though, so clearly there’s some room for improvement (or at least tool support.)

David then went on to talk about some glitches in the mobile implementation, which is valuable info:

Touchscreen events: apparently there is a hardcoded 350ms delay in tapping an element before the click event is fired. That’s crazy sluggish! (He speculated that the reason was an attempt to allow people to cancel quickly if they touch the wrong thing, since fingers are thick and clumsy. I’ve seen other posts online guessing that this is to allow the user to continue and turn the click into a gesture.) David recommends working around this by binding custom events to touch down and touch up, which generate a click event immediately if the user does touch down and then touch up within a small radius. I dunno – sounds hackish and fragile to me. (I looked this up to see if it was in a spec somewhere or just an implementation detail, and all I could find was posts complaining about it on the iPhone. I’ll have to check with our UI people and see if it’s iPhone-specific or built into WebKit.)

No fixed elements: position:fixed doesn’t work on mobile – he didn’t say why, so I had to look it up. Actually it works fine to fix an item to a specific position on the page, that’s just not very useful on mobile since most people want it fixed to the viewport. This makes building pages with independently scrolling areas difficult. To fix this, he again recommends writing custom touch handlers to track movement events and update content based on that – a simple implementation would just move linearly, but to match the platform native scrolling, you would need to track acceleration and add bounce at the end, which gets pretty complex.

Wow. That’s even worse! After all the talk of moving transitions and animations into CSS so they can be implemented in the browser and accelerated, it saddens me deeply to hear people talk about implementing kinetic scrolling of all things in Javascript.

Finally he listed some Javascript frameworks to help with mobile development:

iScroll and TouchScroll both wrap touch scrolling as described above, and contain their own implementations of acceleration.

jQTouch he described as “limited” and “hypercard-like”; I guess he’s allowed to denigrate it since he wrote it. It fixes the 350 msec delay but not scrolling.

And Sencha Touch, his company’s product which is in beta, abstracts all touch events to generate artifical events like doubletap, swipe, and rotate, implements independantly scrollable areas, and a ton of other features.

For deployment he mentioned OpenAppMkt, an app store for web apps, and PhoneGap again for wrapping web apps in a native shell.

David’s slides and additional links are online at his site, including a lot of links to further resources. (Including a bunch I took the time to Google for myself. Oops.)

And at this point my fingers started to cramp up and my notes became much sketchier, so the rest of these writeups will be much, much shorter.

The Browser Performance Toolkit
by Matt Sweeney of YUI/Yahoo!

I was expecting this to describe a specific product, but it turned out to be a metaphorical toolkit – a list of performance measurement tools.

I thought this talk could have benefited from some more demonstration: how to read a waterfall diagram, how to use a profiler. It came off as just a list of products to check out later. It also do a lot to distinguish between them: there was a lot of, “And this has a network waterfall display which is a lot like the last one.” So why should I choose this one over the last one? When somebody asked which products he personally used, Matt’s answer was, “All of them,” which isn’t too helpful. Would have liked more depth here.

I won’t bother linking to these since there are so many and they’re easy to Google:

Firebug: Firefox’s builtin debugger, gives a waterfall display of asset loading, and can break out each load into DNS lookup time, connection time, data transfer time, etc; also has a Javasript profiler, which unfortunately is limited because it only gives function names and call counts, not full call stacks.

YSlow: an open source Firebug add-on from Yahoo, which gives a grade on various categories of network usage and detailed stats, good for getting a high-level view of network usage.

Page Speed: another open source Firebug add-on, from Google; similar to YSlow but also tracks some runtime performance. It can profile deferable Javascript by listing functions not yet called at onload time (candidates for deferral), and displays waterfall diagrams including separate JS parse and execute times.

Web Inspector: WebKit’s built-in debugger. Similar to Firebug, plus an “Audits” tab similar to YSlow/Page Speed. It includes the standard network loading waterfall, and a JS profiler which unlike Firebug’s includes system events like GC and DOM calls, and does include call stacks but not call counts, just run times.

IE8 “has a robust set of developer tools”, but he didn’t say any more about them. IE9 has a network usage tracker and profiler which seem on par with Firebug and Web inspector, with one huge caveat: the profiler’s timer is in 15msec chunks! So runtimes are not close to accurate due to rounding. At least call counts are still useful.

DynaTrace AJAX Edition is a free IE add-on supporting versions 6-8, with IE9 and Firefox support coming soon. It has the standard network waterfall, plus some nice high-level pie charts showing percentage of time spent loading various resources. Its profiler tracks builtins like Web Inspector’s, and can also capture function arguments, which sounds very useful, and has the nicest UI demonstrated, including pretty-printing the source code when looking at a function (especially useful when debugging obfuscated JS).

Matt also mentioned a few online tools: apparently showslow.com aggregates YSlow, Page Speed and DynaTrace scores, and publishes the results so it’s a good way to compare your page to others. But when I tried to go there I got what looked like a domain squatter, and I see no mentions of it in Google – did I copy the name down wrong? Webpagetest.org does network analysis for IE7.

Mentioned but not detailed were Fiddler and Charles (no relation), a proxy which among other things can be used to see Flash resource requests over the wire.

His final point was that, since browsers vary, you can’t just use one tool and need to profile in multiple browsers with multiple tools. Which makes sense, but it would have been nice to give more detail on what YSlow or Page Speed give you over the browsers’ builtin debuggers.

NPR Everywhere: The Power of Flexible Content
by Zach Brand, head of NPR’s digital media group

I could have gone to the HTML5 vs Flash presentation in this time slot, but after seeing 3 variants on HTML5 in a row I figured I should see something a little different instead. Here, the head of NPR’s digital media group described the challenges in getting NPR’s original news reporting formatted in a way that could be used in many contexts: large screens, small mobile devices, summarized on affiliates’ web sites, serialized through RSS, embedded in blogs.

This was another presentation where I would have liked to see more technical detail and less overview, but I guess there wasn’t time. The talk was interesting, but didn’t contain anything directly applicable to my work so I won’t bother to summarize it.

I will list two important links, though:

An API for public access to NPR’s news stories is at npr.org/api.

Zach promised a followup on the blog at npr.org/blog/inside

(While I’m attending this conference on behalf of Research In Motion, this blog and its contents are my personal opinions and do not represent the views of my employers. That ghost is full of cake.)


Syndicated 2010-09-29 16:53:00 from I Am Not Charles

W2E Day 1: Building Cross-Platform Mobile Web Apps with Jonathan Stark

Jonathan Stark, author of two O’Reilly books on mobile app development, shares techniques for doing it with web technologies.

This was a good companion to this morning’s session (okay, yesterday morning’s session now: Alex’s workshop took so long to write up that now I’m behind.) It covered a lot of the same ground but in a more hands-on, less theoretical way. It discussed the same CSS3 features: transforms, transitions, animation, gradients, rounded corners, and text shadows, but gave more complete code examples, took some time to explain them, and tweaked a lot of parameters to show their effect.

Jonathan disagreed with Alex on one thing: they both gave equal weight to Web Storage (for keeping simple persistent data on the client) and app cache manifests (for keeping resources on the client), Jonathan went on to give a gung-ho demo of HTML5′s SQL database integration, which Alex dismissed yesterday saying the API was “a mess”. One reason might be that Jonathan was speaking specifically about writing mobile pages, which means WebKit (which has the SQL API) while Alex, despite being a chrome developer, was being careful to keep his talk cross-platform and highlight the Firefox and Opera way to do things. I’m not sure now if Alex meant that the db situation is “a mess” because there is no convergence, or if he had actual problems with the API design.

Apart from the new CSS and HTML practical overview, Jonathan did cover some more philosophical questions: is it better to use native UI toolkits to write a mobile app for each device, or just write your “app” in HTML and use these new features to make it look as much like an app instead of a web page as possible? HTML is the clear winner in terms of developing for multiple devices (no need to learn Objective-C just to build for iPhone), distribution, and updating (just dump the new version to the live site), but native apps still have slightly better cosmetics and – critically – access to device features. Random apps on a web site aren’t allowed to access the camera, dial the phone or open the address book.

Nonetheless, Jonathan strongly recommended using web tools to build apps, since it let’s you target more than a single device. To get around the sandboxing problem, he touted PhoneGap, a very cool looking open source framework for compiling HTML apps into native packages. Just dump your web code into a dir, point PhoneGap at it, and it will generate an appropriate project to embed it for your platform (some Java classes and ant build files for Android, some Objective-C code and an Xcode project for iPhone, etc). Even better, it generates bridges to allow access to sandboxed features like the camera from Javascript (though obviously you can’t test this in the browser). Their supported feature list only lists Blackberry 4.5, but that’s not too surprising as the WebKit browser is so new. Hopefully support for BB6 widgets will be coming soon. I’ll definitely need to take a look at this project.

It’s important to note that Jonathan was talking about building apps through HTML, not just web pages. His examples blatantly ignored a lot of Alex’s optimization (or more precisely “not sucking horribly” advise), but as he reminded me when I talked to him afterwards, not blocking on network performance doesn’t matter as much when the app is all installed. He swears by Steve Souders for performance advice: I’ll need to check out his stuff to see how it compares. (I see he and Alex both work for Google, so probably Alex got it from him in the first place.)

Jonathan also touted the JQTouch library that he maintains, originally written by David Kaneda, whose presentation I’m going to see tomorrow. (Today, now. In fact, I’ve already seen it. But let’s maintain the fiction that I just walked out of the workshop.) It looks like a pretty good widget toolkit – built on jQuery, but I won’t hold that against it for native development. I wonder how hard it would be to rip out the jQuery usage and replace it with Alex’s h5.js…

Jonathan had some useful advice for mobile developers as well: as well as the obvious small screen and slow, unreliable, expensive data channels, remember that the user’s interaction with a mobile device will be different because they are almost always using it in a distracting environment. Users want to pop open the app, perform a tiny task, and be done before they reach the head of the line. That means always let the user know how much is left to go in their interaction, try to break things up into tiny chunks, and if there is ever the slightest pause for God’s sake throw up a progress bar or something!

A more specific recommendation: on a touch decvice, put controls (search bars, navigation buttons, etc) on the bottom of the page, since reaching up to tap a control will block the user’s view. Good common-sense advice; I hadn’t thought of that.

One thing that rubbed me the wrong way, as a traditional developer, is that Stark taught terrible coding discipline. Several times he pasted the same code into his sample app over and over and said, “this is a bit verbose, but you can just add a macro to your text editor to paste it in automatically.” Augh! No! No more cut and paste code – abstract it into a function if you use it more than once! (Unless maybe Javascript function calls have a lot of overhead I’m not aware of that make two line wrapper functions horribly inefficient.)

Other than that, a pretty good presentation, and it was good to see that a web designer is just as excited about new HTML features as browser developers expect (and for much the same reasons – both easier to write and faster).

Slides and some extended notes are promised at http://jonathanstark.com/web20.

(While I’m attending this conference on behalf of Research In Motion, this blog and its contents are my personal opinions and do not represent the views of my employers. )


Syndicated 2010-09-28 21:03:59 from I Am Not Charles

W2E Day 1: HTML5 with Alex Russell

First impression: some guys behind me talking about which smartphones they should get for testing. “Not a Blackberry, though – I can’t stand doing web development on the Blackberry browser.” Sob. We were vindicated when Alex listed the browsers that could and could not handle HTML5 features, and carefully split BB into “Torch+” and “pre-Torch” in each list.

Second Impression: wow, dense. This was a dense, dense, dense, dense talk.

The first part of this talk was basically, “A browser engineer tells you how to build web pages.” Actually Alex’s epigram for it was more illustrative: “Think about your web pages the way a browser thinks about web pages.” About time! You wouldn’t believe how many optimizations we have to bypass because it would break some ridiculous crufty feature that page authors nevertheless make heavy use of. Like Javascript.

Many web developers just don’t realize how many side effects common techniques have. The most obvious is that Javascript is executed as soon as it’s parsed, and it blocks page loading until it’s finished. But Alex went through some more obscure and situation-dependent ones: for example, reading computed style info from Javascript requires the engine to do a layout pass to compute that info, which can be very slow, unless it’s already been done. So try to delay Javascript like this until after the page has already been laid out and rendered once (good luck reliably figuring out when that is.). You especially want to avoid Javascript that alters the page structure, forcing it to be layed out again (unfortunately, this is the most useful thing for Javascript to do).

Another extremely important thing that’s often misunderstood is just how much DNS sucks. Because DNS is a giant bottleneck, and for other reasons that Alex went into at length but I won’t because this is long enough, opening an http connection is heavyweight, so for good performance you want to avoid downloading lots of small resources: put as much as you can into each resource, and try to prioritize so that the important ones (CSS that applies to every element on the page) doesn’t have to wait on the tiny images that form the rounded corners of your logo.

Hopefully the talk went into enough detail on this to give the audience a good conception of these issues. But I think it might have been a bit heavy on the browser developer jargon – it included an overview of webkit render trees (!) to explain how the various bits of timing interact.

Fortunately the take-away for general design can be boiled down to some simple points: put your CSS first; put your Javascript last; and use “defer async” as much as possible. (But don’t take my word for it, check out the slides, because it’s important to understand why this helps in order to generalize it.)

I spent the opening half of the presentation thinking, “It’s great how he’s showing all these web developers the complexities involved in the browser!” But then when he started talking about individual CSS elements, I started to zone out. “I can just look these up in the spec when I need them.” I wonder if the web developers in the audience had the opposite reaction?

Speaking of which, there wasn’t a lot of audience reaction. He kept asking for questions and getting none. I think it was more of a, “This is really cool but I’ll clearly need to play around with it myself to get a feel for it, so I don’t have anything to ask yet,” kind of silence, and less of a, “I have no idea what’s going on,” silence, but it’s hard to be sure because the second half of the talk flew through a whole bunch of new HTML5 features without pausing on any of them. Too densely packed to linger. So let’s repeat the whirlwind tour:

HTML5 ~= HTML + CSS + JS APIs

HTML has some new and shiny things:

New, cool input types that let you remove validation code (they have builtin constraints) and avoid writing complex user interaction objects (they have builtin themes and behaviour that’s more complete than traditional objects).

Canvas – lets you draw on the page with inline code instead of downloading tons of images which fight for network priority.

ContentEditable – turns any HTML element into a rich text editor.

CSS has more new and shiny things:

Gradients, shadows and rounded borders: again, less use of images.

Layered backgrounds so you can draw your background with a canvas instead of, again, an image.

Transitions for hardware accelerated page effects without writing and parsing Javascript.

Transforms for morphing the display of items (although they’re not available everywhere, so use judiciously).

Animations for even more elaborate (and hardware accelerated!) page effects, although they are probably not finalized as the syntax is still not very clean compared to transitions.

Javascript and the DOM have new things that are less shiny, but useful:

First, let me digress to talk a bit about jQuery. It’s a horrible anchor around the neck of every web site. It’s a gigantic library that must be downloaded and parsed (synchronously) before even beginning to parse the rest of the page, and because everybody uses a slightly different version of it served from a different URL they can’t even share a cache of the thing! The only thing worse than using jQuery is not using it: can you imagine the bugs that would be caused if everyone tried to duplicate its functionality by hand?

So replacing jQuery with something making better use of inbuilt browser features is a worthy goal, because it would hit points (a) and (b) above perfectly.

So when Alex says, “These new features let you do everything jQuery does in 30 lines of code!” I prick up my ears. Not being a web developer, I don’t know what jQuery actually does, so I’m probably being naïve, but here they are:

querySelectorAll is a new DOM method that ties in with the CSS declarative model: give it a string and it will return all the nodes which match that CSS declarator. As I mentioned yesterday, CSS is not my thing so the descriptors Alex demonstrated were all gibberish to me, but the concept seems pretty useful.

defineProperty is a new Javascript statement that let’s you add functions to any prototype, meaning if you stick something on the root of an object tree, it’s automatically available to every derived object (what most languages would call a “subclass”). This has always been possible, but there were side effects that made it dangerous to use in libraries; defineProperty does it cleanly.

Some more Javascript goodness:

WebStorage let’s you store persistent key-value pairs. Traditionally you would use cookies for this, but cookies are terrible for performance: they’re included in the headers sent with every request and response, and the headers can’t even be zipped. And incidentally, the cookie “spec” is a joke (it is fundamentally ambiguous, so it is not possible to write an algorithm to parse cookies correctly) so anything that gets rid of them is A-OK by me!

Drag and drop is traditionally done with fragile and inefficient Javascript; now it’s built into the browser.

And, uh, some more, but by this point my notes are becoming illegible because my God that’s a lot of stuff. And there are a lot of intriguing points brought up about all of these, which this margin is too small to contain, so if I have time I’ll make more in-depth followup posts on some of them.

Of course, you can only use these features on bleeding-edge browsers – so, well, basically all of them except IE 6 to 8. Which still make up something like 30% of the market. Alex handwaved this a bit by talking up his Chrome Frame product – you can just ask your users to install an IE extension instead of a whole new browser – but it sounds pretty tenuous. I have no better solution for this, though – adding fallbacks defeats the whole purpose of using new builtins to make pages smaller and simpler.

Then there was a lab session, which Alex unsurprisingly ran out of time to show in detail. It showed a small sample app using these techniques, including a wrapper library called h5.js which makes using some features simpler, works around design flaws in others, and includes an async downloader for resources in less than 1K (gzipped). Source code is available here.

All in all, a very impressive presentation, covering lots of exciting ground, but could have used a little less scope and more depth. Fortunately, the afternoon’s session provided a very nice complement.


Syndicated 2010-09-27 15:52:18 from I Am Not Charles

Web 2.0 Expo

I’m not much of Web 2.0 kind of guy. Facebook confuses me, I don’t see the point of Twitter, and these are the only two rich web apps I can think of off the top of my head. (Ok, that’s not true, but it’s punchier than, “I’ve probably never heard of most of the stuff that you Web 2.0 type people get excited about.”)

Yet I’m on my way to the Web 2.0 Expo in NYC. What am I doing here?

Well, first off I’m representing my employer, whatever that means. Schmoozing, I guess.

I’m also going to be going to a lot of web development (as opposed to business or – ick – marketing) talks. I’m not a web developer, I’m a WebKit developer: I know quite a bit about the underpinnings of web technology, but I’m not so clear about how it’s used in the real world. So I want to find out things like: which of the cool new HTML5 features are people doing web development most excited about? Which will be seeing heavy use starting now, and which are still seen as not mature enough to rely on? What do people want to do that can’t be done with cross-platform web technologies yet, and how can we provide it? Does anybody actually care about Flash? And what do web developers want to see from the Blackberry, specifically, to make it a killer platform?

And rather than learn about all this stuff and then file it away somewhere, I’m going to blog about it as I go. That will let me feel like I’m being useful and not just schmoozing on my employer’s dime. Hey, it’s a blogging conference, and I have a handy blog sitting here unused. Seems like a good time to dust it off!

First off tomorrow are two workshops: “HTML5: Developing for the Desktop and Mobile”, by Google’s Alex Russell, and probably “Building Cross-Platform Mobile Apps”, by Jonathan Stark, which sounds pretty basic from the description, but I’m probably in need of some remedial CSS3. (It can’t be any harder than template metaprogramming, right?) More importantly right now, it’ll help me decide if I should go to Jonathan’s other talk, which conflicts with a bunch of other stuff I’d like to see.

(While I’m attending this conference on behalf of Research In Motion, this blog and its contents are my personal opinions and do not represent the views of my employers. Nutella is a registered trademark of Ferraro.)


Syndicated 2010-09-27 00:57:49 from I Am Not Charles

Retiring a link


One of the links over on the right that nobody ever clicks on is “Torch Mobile”, my employer. It’s time to retire that link, and replace it with something from Research In Motion – my employer.

Syndicated 2009-08-30 03:56:35 from I Am Not Charles

How’s Gimp doing these days?


I’ve always heard two opinions about Gimp: “It’s just like Photoshop, an incredibly complex and expensive piece of professional software, but it’s free! Behold the power of Open Source!” and “Gimp sucks. It’s better than nothing, I guess, but if you’re using Gimp instead of Photoshop you’re a chump.”

Of course, not having any need for a pro-quality image editor due to lack of artistic talent, it’s been 5 years since I paid any attention to this. My sister gives an update on how Gimp stacks up today.

Syndicated 2009-07-22 02:50:37 from I Am Not Charles

O(log n) continues to beat O(n^2)


Two items:

1. I feel pretty bad about the several months of silence. I swore this time I wouldn’t start a nice professional journal and then let it languish. Oops.

2. I also didn’t want to post links with no original content but, well, this is a pretty cool result and I have nothing more to add to it. So here you go.

(Brief summary: my coworkers found a way to significantly speed up image tiling in Qt, using a simple algorithm that’s easily applicable to other toolkits and environments. Briefer summary: It makes painting faster, which is always good.)

Syndicated 2009-03-03 05:30:47 from I Am Not Charles

Fresh data


So what runs better - OpenOffice or KOffice? Anecdotal evidence says KOffice is slimmer but OpenOffice works better, but it’s very hard to find actual hard numbers on memory and resource usage. And when you do find somebody who’s done a comparison, it invariably dates back to 1995 and it’s totally obsolete.

How about Evolution vs. KMail? Evolution’s much more popular, but there are a few blog posts that offhandedly mention it’s a huge hog compared to Kontact. Which is odd, because there are actual filed bug reports that claim Kontact leaks memory like a sieve. How can I find the truth without installing both and painstakingly testing them in a wide variety of common use cases?

Well, we know that Evolution’s more popular because of the Debian Popularity Contest, where Evolution has a commanding lead. (The “Vote” column is the useful one.) popularity-contest is a Debian (and Ubuntu) package which automatically collects stats on what software is installed and how often it’s used, and I urge everyone to install and enable it now so that it can give a more accurate picture of what’s popular and where developer resources are best spent.

It would be great to have a similar program that automatically collects resource usage statistics for all running programs. Suddenly we’ll have actual hard, fresh data to settle arguments about whether your favourite app is a bloated hog or no worse than everything else! This info would be invaluable for both developers and packagers.

      

Syndicated 2008-09-26 23:28:42 from I Am Not Charles

Your clipboard isn’t broken, just confused


This is kind of trivial, but it’s good to have it documented somewhere.

If you ever have to work with the Windows clipboard API directly (and it’s not too bad, as Windows API’s go) this might save you a lot of time: don’t try and step through any clipboard-related code in the debugger.

I was trying to figure out why pasting an image into my app didn’t work, so obviously the first thing to check is that the data is actually being retrieved from the clipboard correctly. I suspected it wasn’t being saved in the format I thought it was.

BOOL clipboardOpen = ::OpenClipboard(NULL);
if (clipboardOpen) {
    qDebug() << "Clipboard open";
} else {
    qDebug() << "Couldn't open clipboard: error" << ::GetLastError();
    return;
}

UINT format = 0;
while ((format = ::EnumClipboardFormats(format) != 0) {
    qDebug() << "Clipboard contains format" << format;
}

qDebug() << "Last EnumClipboardFormat status was" << ::GetLastError();
::CloseClipboard();

MSDN is pretty clear on how these two functions work: OpenClipboard returns true if the clipboard’s open, and EnumClipboardFormats returns 0 when there’s an error (in which case GetLastError returns the error code) or if it’s out of formats (in which case GetLastError returns 0, SUCCESS).

Since I was too lazy to actually hook up the Qt debug logger I was just stepping through this in the Visual Studio debugger to examine the results. And the results were basically:

Clipboard open
Last EnumClipboardFormat status was 1418

Since my app is emphatically not multithreaded, I was pretty baffled about how “Clipboard open” could be immediately followed by 1418: ERROR_CLIPBOARD_NOT_OPEN. I thought my paste problem was because my clipboard was seriously broken (on any OS but Windows I’d have thought something that fundamental was impossible, but on Windows I never assume anything). Took me ages to realize that it worked fine if it wasn’t in the debugger.

The problem, I think, is that when you pass NULL to OpenClipboard it associates the clipboard with the current process, and when you’re stepping through in the debugger it’s switching back and forth between the application and Visual Studio. Somehow the system is getting confused about which process has the clipboard open. This example seemed to work if you pass an HWND to associate it with a specific window instead of a process, but I wouldn’t want to place any bets that more complicated code would keep working. On Windows I never assume anything.

Syndicated 2008-07-04 05:27:15 from I Am Not Charles

23 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!