Well… let’s hope this one will last more than a few hours…? ![]()
Well… let’s hope this one will last more than a few hours…? ![]()
One of the nice things Objective-C inherited from C is the switch statement. If you have set different tags in all your menu items, you often find you can do things like:
- (BOOL)validateMenuItem:(NSMenuItem*)menuItem {
switch ([menuItem action]) {
case 1:
...
case 2:
...
}
return YES;
}
Those tags have to be set in Interface Builder, and you probably will have an enum somewhere to use symbolic constants instead. However, the standard C switch() is restricted to integer values; you can’t switch on strings or selectors. So, if you don’t want tags and need to switch on the menu item’s selectors, you’ll have to do:
- (BOOL)validateMenuItem:(NSMenuItem*)menuItem {
SEL action = [menuItem action];
if (action==@selector(firstAction:)) {
...
} else if (action==@selector(secondAction:)) {
...
} else...
return YES;
}
Bearable if you have two, or even four or five cases, but what if there are dozens? Or suppose you have to compare strings instead of selectors:
- (BOOL)validateMenuItem:(NSMenuItem*)menuItem {
NSString* title = [menuItem title];
if ([title isEqualToString:@"firstTitle"]) {
...
} else if ([title isEqualToString:@"secondTitle"]) {
...
} else...
return YES;
}
Not that it’s recommendable, in practice, to compare menu item titles, but it’s a good example.
Well, there are other ways to make this more readable, or even more efficient. But here’s one neat way to convert a group of strings into integers for use in a switch(). First, let’s write an utility C function to do so:
NSUInteger CaseCodeForString(NSString* string) {
static NSArray* array = nil;
if (!array) {
array = [[NSArray alloc] initWithObjects:
@"zeroth string",
@"first string",
@"second string",
@"third string",
...
nil];
}
return [array indexOfObject:string];
}
Note the standard lazy allocate-once trick of declaring array static, initialize it to nil, and test before using. Anyway, this function will return 0 if you feed it @”zeroth string”, 1 for @”first string” and so forth… and return NSNotFound if the string isn’t in the array. So you could, in our last example, do:
- (BOOL)validateMenuItem:(NSMenuItem*)menuItem {
switch (CaseCodeForString([menuItem title])) {
case 0:
...
case 1:
...
}
return YES;
}
If there are many strings, this will be faster than a series of isEqualToString: calls; this is because NSArray uses a hash table to find the index of a particular object, and only goes into the actual string comparison if the two string’s -hash methods return the same value.
Pushed out 119, then literally a second later got a bug report, had to do 120. Sorry about that.
In my post on event taps, I mentioned the following code to get a global event tap:
CFMachPortRef tapg = CGEventTapCreate(kCGAnnotatedSessionEventTap, kCGEventTapOptionDefault,
CGEventMaskBit(kCGEventLeftMouseDown)|CGEventMaskBit(kCGEventLeftMouseUp),
ProcessEvent,NULL);
This taps the event stream at the “annotated session” point (hence the kCGAnnotatedSessionEventTap parameter). Basically, this means that the event has already been analyzed as to destination application, and you can ask the passed event directly for that application’s process ID. This is was I was using in Klicko.
Unfortunately the docs don’t mention another step that takes place while “annotating” a mouse-down event: apparently, if the click was on a window’s title bar (not elsewhere in the window), the owning process is brought to the front before the tap sees the event! Klicko’s processing varied depending on the clicked-on window’s and the owning process’ state, so I was seeing different results depending on the click location – title bar or inside the window. Worse, a workaround I needed to do to bring non-main windows to the front for background processes wouldn’t be applied at all if the user clicked on a title bar!
A more subtle consequence was that I was intercepting (and discarding) mouse clicks, while the system was expecting the click that brought the process to the front to actually arrive at the process… the result was that, while the menu bar changed to the process, its windows would remain in the back.
After beating my head against this wall for several days, I was rereading the CGEvent docs again for ideas and noticed that I hadn’t tried applying a global tap before event annotation:
CFMachPortRef tapg = CGEventTapCreate(kCGSessionEventTap, kCGEventTapOptionDefault,
CGEventMaskBit(kCGEventLeftMouseDown)|CGEventMaskBit(kCGEventLeftMouseUp),
ProcessEvent,NULL);
Note the kCGSessionEventTap parameter. This meant that I had to discover the owning application’s process ID myself (instead of asking the mouse-down event directly). Premature optimization strikes again; I’d selected the annotated tap just to avoid doing these steps.
At any rate, I immediately discovered that I now could properly intercept clicks anywhere, discard them, and do process and window activation as I wanted to. Well, almost; there was still some redundant window activation to do, as Carbon and Cocoa apps seem to still have some residual differences in that regard. I’ll be filing bugs at Apple about some of these things.
This latest build of Klicko fixes all known bugs and edge cases, and some memory leaks. Hopefully this will be the last build for a long time.
In my next post I’ll explain some technical details.