Concatenating strings in REALbasic itself is a very simple operation:

dim str as string = "foo" + "bar"

However, the plugins SDK provides no function for concatenating REALstrings together. There’s also no function we can load through REALLoadObjectMethod or REALLoadGlobalMethod. While it would be nice if it was provided, it’s rather easy to do yourself.

//! Creates a new string by concatenating `firstString` and `secondString`.
REALstring ALConcatStrings(REALstring firstString, REALstring secondString) {
    REALstring convertedFirstString = NULL;
    REALstring convertedSecondString = NULL;
    bool needsUnlock = false;
 
    if(REALGetStringEncoding(firstString) == REALGetStringEncoding(secondString)) {
        // encodings are equal, so no need to convert anything
        convertedFirstString = firstString;
        convertedSecondString = secondString;
    } else {
        // if the two strings aren't in the same encoding, we need to change them both to UTF8
        convertedFirstString = REALConvertString(firstString, kREALTextEncodingUTF8);
        convertedSecondString = REALConvertString(secondString, kREALTextEncodingUTF8);
        needsUnlock = true;
    }
 
    // the total length (in bytes) of the resulting string
    size_t totalLength = convertedFirstString->Length() + convertedSecondString->Length();
 
    // ok, now we need to create a buffer for the total string contents
    char *buffer = (char *)malloc(totalLength);
 
    // copy in the first and second strings' data to the right spots
    memcpy(buffer, convertedFirstString->CString(), convertedFirstString->Length());
    memcpy(buffer + convertedFirstString->Length(), convertedSecondString->CString(), convertedSecondString->Length());
 
    // next we create a REALstring from it
    REALstring result =  REALBuildString(buffer, totalLength, REALGetStringEncoding(convertedFirstString));
 
    // free our buffer (REALbasic copies it on BuildString)
    free(buffer);
 
    // unlock our converted strings if we have to
    if(needsUnlock) {
        REALUnlockString(convertedFirstString);
        REALUnlockString(convertedSecondString);
    }
 
    // phew, that was easy enough!
    return result;
}

I apologize for the awful formatting of this page! It looks decent in an RSS reader at least…

We’re pleased to release a second update to CalendarKit to address the requests of some users. Version 1.2 adds a URL property to ALCalendarItem objects, and also corrects one bug regarding Task completion dates.

If you have purchased CalendarKit, your account page will give you the option of downloading the latest version. If you’re interested in learning more about CalendarKit and what it can bring to your applications, please visit http://alacatialabs.com/products/calendarkit/ and download a demo.

Our changes in this release were user-requested. We’re always willing to take your needs into consideration when planning new releases. Let us know if there’s anything we can do for you.

Sorry if this looks like a repeat; it is a rewrite of a post on our old blog. It may differ from the original content.

C++ doesn’t let you get the address of an instance method. Even if you were to get the address, you couldn’t call it because the convention requires that ‘this’ be in the ecx register. However, with a little creativity we can work around this requirement.

(Please do not stare directly at the following code block until we manage to come up with a new color scheme for GeSHi!)

#include <stdarg.h>
 
void* GetInstanceMethodAddr(char x, ...) {
	va_list argp;
	void *addr;
 
	va_start(argp, x);
	addr = va_arg(argp, void *);
	va_end(argp);
 
	return addr;
}
 
// For example,
void *func = GetInstanceMethodAddr(42, &std::string::size);

The first parameter is arbitrary, and is only used because it’s required by varargs. You can change it as necessary.

A minor update to CalendarKit is now available, bringing the current release to version 1.1. This update fixes all reported bugs and introduces Tasks, or “to-dos.”

If you have purchased CalendarKit, your account page will give you the option of downloading the latest version. If you’re interested in learning more about CalendarKit and what it can bring to your applications, please visit http://alacatialabs.com/products/calendarkit/ and download a demo.

We are currently considering the possibility of porting CalendarKit to Windows. If you think Outlook integration would be beneficial to your Windows-oriented application, please let us know of your interest.

We’re always interested in hearing feedback from our users. Please let us know if there’s anything on your mind.

A few weeks ago I wrote about a hidden preference pane that ships with Leopard, Archives.prefPane.

As an anonymous reader pointed out this afternoon, the post made an unexpected shift when I put up a screenshot of DiskImages.prefPane and continued to discuss it rather than Archives.prefPane. Apparently I was more than a little absent-minded — even the file name of the image is “archiveprefpane.png”!

I’ve corrected the old post, so I’ll leave you with the assurance that I’ll pay closer attention next time!

Kyle, TX: CalendarKit provides an API for REALbasic-made applications to interact with a user’s calendars by providing fast, native integration with calendar software. It currently integrates with iCal 3 on Mac OS X 10.5 “Leopard,” and is the only supported way of manipulating .ics calendars on the new operating system.

A free demo of CalendarKit is available at:
http://alacatialabs.com/products/calendarkit

Licenses for CalendarKit cost $50 per developer, and source licenses are available.

About Alacatia Labs, Inc:
Alacatia Labs, Inc. was incorporated in the summer of 2007. We strive to operate it like a research facility rather than a monolithic corporation; in this sense, we seek to experiment and develop new technologies rather than make a buck. We’re enthusiastic about the work we do and are confident that this enthusiasm will show through our unique products.

For more information about Alacatia Labs, Inc, please visit:
http://www.alacatialabs.com/

In 10.5, applications can update their dock icon even if they aren’t running, though the only known use of this is iCal. The way this works is that the Dock loads a piece of code (the Dock Extra) to draw the application’s icon for it.

Ok, so that’s not entirely accurate. The Dock tells SystemUIServer to load the Dock Extra and communicates via Mach IPC to get the icon. So, Dock Extras are NOT a way to load code into the Dock.

The Dock Extra bundle is found by the DockExtra key in the application’s Info.plist. As needed, SystemUIServer loads the Dock Extra bundle and creates an instance of its principal class.

As with manipulating the Dock icon in an actual application, you need to request it be redrawn yourself. To do this, you call getContext: to get the graphics context and the rect to draw in. Once you are done drawing, simply flush the context and call setDockImageFromContext:.

It should be noted that the SystemUIServer does NOT unload the bundle when you drag the icon off the Dock (it simply calls invalidate). This causes problems if you try to delete your app, because the Dock Extra is still in use.

It should also be noted that Dock Extras are only invoked when the application is visible on the Dock. It isn’t invoked when showing stacks or if there’s an alias to the application on the Dock.

Download DockExtras Example