REALbasic
Maybe a diary of REALbasic app development. Maybe just stuff about REALbasic. Maybe nothing :)


@ Monday, May 6, 2002
 

WWDC

WWDC, Apple's developer love-fest, starts today. I went a few years ago and I can tell you that it is a blast. My favorite part is all the free Guinness. Any company that treats its developers to free Guinness knows what it is doing.

Well, ok, there were also some cool presentations on new Apple technology. When I went I believe that OS X hadn't even shipped yet. But Apple was talking about it a lot. And there were many sessions on OS X stuff. There were also a number of WebObjects' sessions. WebObjects is another NeXT technology that Apple got when it bought NeXT. I was amazed by the number of people attending the WebObjects' sessions. And Java as well. Many people interested in Java. Not me, though.

This year REAL Software will have a big presence at WWDC. I wish I could go just to meet the RS people that I correspond with on the RB mailing list.

But I've got two buddies there so they can have a good time for me. Doh!

comment ()  10:07:27 AM  #  


AppleEvents and REALbasic Developer

I have to write one "extra" column for REALbasic Developer and I had thought of covering localization but I've changed my mind. The problem with localization is that it is a great big complicated topic that would really require an in-depth analysis of all issues to get right. The chance of saying something wrong is great, I believe. There are bugs in REALbasic, for starters. For example, in Mac OS X, you can't enter Japanese in the constants dialog. So if I want to make constants with a Japanese version, I have to do some extra work. Probably European languages would be easier. Most if not all of the characters are available with the English keyboard. But so-called 2-byte languages like Japanese and Chinese are challenging.

Another problem is that REALbasic by itself just can't really handle the entire localization issue. You need separate apps. Two that I've found are REALglot and RBulk. Both very useful. But if I were to write an article about all of this there would be a number of issues I'd have to work through to make sure I didn't make a mistake.

So instead I've decided to talk about handling AppleEvents instead. The fact that I've been messing with AppleEvent handling in ResPloder is certainly one of the reason's that I've made that decision. It is still an interesting and important aspect of REALbasic programming. And it is a topic for which a 1500-word article should be possible.

Have I sold out?

comment ()  7:59:43 AM  #  


Scriptable ResPloder

Last night, instead of concentrating on "Six Feet Under", I spent my time making ResPloder scriptable. It's quite easy to do in REALbasic. There are some interesting quirks I had to deal with, but all in all a fun experience.

All the magic happens in the Application class' HandleAppleEvent event. You get all the info you need to figure out what kind of AppleEvent it is. AppleEvents themselves are objects with accessor methods for getting at the parameters. Replying to the event is also simple. The AppleEvent class has methods for added different kinds of replies.

I really wanted to return enough information to indicate success or failure (a boolean), the reason for failure (a string), and a reference to the exploded folder or imploded file (an alias). My first thought had been an AERecord, which appears to be a like like a REALbasic dictionary. It maps keys to values. But I couldn't figure out how to get the Script Editor to understand my keys. They weren't being treated as strings, which makes me think I hadn't set up something correctly in my 'aete' resource. So I decided to put the three things in an AEDescList, which is really just an array of values. That worked out very well, the only problem being that users will have to know the order of the values. They won't be able to pull them out by key.

More on the 'aete' resouce: You need to tell the outside world how to talk to a scriptable app in a high-level language like AppleScript. You can talk directly to a scriptable app using AppleEvents if you build the AppleEvents yourself. But if you want to allow scripting with AppleScript, then you need to indicate the verbs and such that your app understands. ResPloder understand two new verbs: explode and implode. Each takes one required parameter and two optional parameters. The one required parameter is a reference to the file or folder to explode or implode. The two optional parameters are the name and location of the exploded folder or imploded file.

comment ()  7:49:56 AM  #  


@ Sunday, May 5, 2002
 

Scriptable ResPloder

I'm in the process of adding scriptability to ResPloder. It's actually quite easy to add with REALbasic. You need to add an 'aete' resource that specifies the Apple Events you're going to recognize. Then you need to add some code to your App object's HandleAppleEvent event. In that event you'll get an AppleEvent object, which is REALbasic's encapsulation of an apple event. It's trivial to get the pieces out of the event and add replies.

But there is one interesting wrinkle. ResPloder explodes and implodes in a thread. HandleAppleEvent won't naturally wait around for the thread to complete. But if HandleAppleEvent returns before the operation has been completed, then the caller may think things are finished. Ideally HandleAppleEvent should wait until the explosion/implosion is finished before returning. It turns out there is a trick you can use to make that happen. Use ShowModal on a modal dialog inside of HandleAppleEvent. That will cause HandleAppleEvent to pause until somebody hides the dialog. Control will then return to HandleAppleEvent, which is then free to return a response to the caller. That trick fits very well with ResPloder's progress dialog. So instead of 'Show'-ing the progress dialog, I now 'ShowModal' it and low-and-behold HandleAppleEvent waits for the explode/implode to complete before returning.

Cool.

comment ()  9:42:51 AM  #  


Radio Poster and MovableType

MT 2.11 is out. I upgraded and now Radio Poster can post to an MT weblog using the MetaWeblog API. Almost. It won't work with the currently shipping version of Radio, unfortunately. There's a bug in Radio Poster. Well. I didn't have anything to test it with except Radio, so a bug slipped through. The problem is that when posting with the MetaWeblog protocol selected, Radio Poster ignores the Blog ID field in the configuration tab and always uses "home" instead. That works fine with Radio, of course. But for MT I need to set the blog id or MT won't let me post. I'm going to release a new version of Radio Poster to fix this problem. But I'm trying to decide how much other stuff I want to add. I really want to be able to control multiple weblogs and right now you just can't do that with Radio Poster.

comment ()  9:24:17 AM  #  

@ Friday, May 3, 2002
 

I was a bad boy

It turns out I never registered the creator code for either ResPloder or Radio Poster with Apple. So I thought it might be a good idea to go ahead and do that. Turns out that the creator code for ResPloder was already taken :( I tried a few other and finally found one that was available: RPlo. So the next version of ResPloder will have a new creator code. Which isn't really a big problem as ResPloder makes no document files. But Radio Poster is a different story. It does make document files and if I had to change its creator code then all the document files that people have already made wouldn't link to the new Radio Poster. But I got lucky. Radio Poster's creator code was available.

Let this be a lesson. If you are getting ready to ship a Mac app, register its creator code with Apple before you ship it.

comment ()  9:59:18 AM  #  



Click here to visit the Radio UserLand website. © Copyright 2002 Will Leshner.
Last update: 2/6/02; 9:39:50 AM.
May 2002
Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Apr   Jun

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.

~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~