Showing posts with label Carbon. Show all posts
Showing posts with label Carbon. Show all posts

Saturday, December 12, 2009

Cocoa and Drawing truncated text

To properly allow for long names of objects in the time-line I need to draw truncated text.
Untruncated Text

What I mean is that I want to truncate the text if the area is to small for the text and then to have some ellipses that show where the truncation occurs. This was second nature to me in my days as a ToolBox (Carbon) programmer but fathoming it out under Cocoa tool a while. Whatever I tried failed - and it seemed that the Apple docs failed me.

In a tight corner Google is a good friend and I found the blog-post from Preston Jackson. It is an example of the kind of blog-post I find most useful. A problem and a solution - with a code snippet. Thanks Preston.

I copy/pasted his code and it worked. Then I integrated it into the code that should have worked but didn't and it failed. It took (unbelievably) an hour to get to the bottom of the problem. In full numpty horror I realized that I was calculating the width of the text I was and changing my destination rectangle so it would be that width.

With the truncation the text looks like this:

Saturday, June 21, 2008

Moving DIBs (device-independent bitmaps) to CGImage

The biggest remaining clot of link errors (probably about 30 or so) relate to Cello's handing of Bitmaps. There are a handful of classes, many parts of which of which are commented out or omitted from compilation, that deal with bitmaps. Hanging on to this are classes and libraries that deal with reading and writing images to and from physical files. Central to all of this is the class that manages the DIB which I have discovered is a device-independent bitmap. The wikipedia article is an excellent introduction and explained why, when I was reviewing the code, I saw code and logic that dealt with vertically flipping images (it seems that DIBs are an inverted format). There is also a fair amount of wrangling to move DIBs (which represents an actual bit image) between images.

My plan here is to replace the DIBs and indeed the image classes with a thin wrapper around CGImage. Apple's ImageIO framework provides a homogenous way to read and write these images in a variety of file-formats.

Sunday, June 15, 2008

Implementing SetFileTime and GetFileTime under OSX

Working through the link errors makes for some catching up on some things that I sketched out and did not complete. I have been looking at the file handling class, file streams and writing unit tests to make sure that the they are working properly as I flesh them out.

I have backed Cello file handling class more or less straight onto STL file streams. In this class there are a couple of methods SetFileTime, and GetFileTime. In the MFC version these are more-or-less straight wraps of the API calls SetFileTime, and GetFileTime:
 BOOL WINAPI SetFileTime(
__in HANDLE hFile,
__in_opt const FILETIME *lpCreationTime,
__in_opt const FILETIME *lpLastAccessTime,
__in_opt const FILETIME *lpLastWriteTime
);

Under OSX I have implemented them in terms of FSGetCatalogInfo and FSSetCatalogInfo. So, for example, the blood and guts of the SetFileTime method boils out like this:
 const char *path = (LPCSTR)m_dwsName;
FSRef fsRef;
Boolean isDirectory;
FSCatalogInfo fsCatalogInfo;

OSStatus err = FSPathMakeRef(reinterpret_cast(path), &fsRef, &isDirectory);
::ThrowIfOSErr(err);
err = FSGetCatalogInfo(&fsRef, kFSCatInfoAllDates, &fsCatalogInfo, NULL, NULL, NULL);
::ThrowIfOSErr(err);

fsCatalogInfo.createDate = *lpCreationTime;
fsCatalogInfo.contentModDate = *lpLastWriteTime;
fsCatalogInfo.accessDate = *lpLastWriteTime;

err = FSSetCatalogInfo(&fsRef, kFSCatInfoAllDates, &fsCatalogInfo);
::ThrowIfOSErr(err);
In my first cut I implemented FILETIME as a CFDate - however looking at FILETIME when writing the test cases I changed this to UTCDateTime which is actually practically the same.

The only wrinkle I have found is that the FSGetCatalogInfo ignore the fractional part in the UTCDateTime - which is something that tripped me in the Unit Tests

Sunday, May 18, 2008

Replacing GetKeys with CGEventSourceKeyState

Working through some of the ECMA (JavaScript) interpreter there is a line of code that tests for the escape key being held down in order to abort execution.
if ((::GetAsyncKeyState(VK_ESCAPE) & 0x8000))
{
  :
}
On the Mac the equivalent UI convention is the command-period. Looking at the world through old Carbon programmer eyes I would probably use GetKeys. In the brave new world of Cocoa replete with the Animal Farm bleat of "Cocoa good, Carbon bad" GetKeys is deprecated. I could use it but I'd rather not.

It took a little hunting but the replacement for GetKeys is CGEventSourceKeyState. This function will return if a given key (expressed as a virtual key code) is depressed. Virtual key codes are defined in HIToolbox/Events.h.

So the function drops out quite nicely:
bool IsCommandPeriodPressed()
{
  CGEventSourceStateID eventSource
    = kCGEventSourceStateCombinedSessionState;

  return ::CGEventSourceKeyState(eventSource, kVK_Command)
    && ::CGEventSourceKeyState(eventSource, kVK_ANSI_Period);
}
As a postscript, and for the avoidance of doubt, I have no beef with Cocoa; Cocoa is good and fun as well as being splendid bed-time beverage for children and adults alike. After all I will be using pure Cocoa for the Cello UI - it is just the Cocoa religion thing that is a bit scary.