http://radio.weblogs.com/0100438/categories/realbasic/ Maybe a diary of REALbasic app development. Maybe just stuff about REALbasic. Maybe nothing :) Copyright 2002 Will Leshner Mon, 06 May 2002 17:07:55 GMT http://backend.userland.com/rss092 will@amianduri.com will@amianduri.com WWDC, <a href="http://apple.com">Apple</a>'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 <a href="http://www.guinness.com">Guinness</a>. 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 <a href="http://realsoftware.com">REAL Software</a> 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! I have to write one "extra" column for <a href="http://rbdeveloper.com">REALbasic Developer</a> 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 <a href="http://realbasic.com">REALbasic</a>, 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 <a href="http://webster.realsoftware.com/realbasic/about/REALglot.html">REALglot</a> and <a href="http://www.liane.net/rb/rbulk/">RBulk</a>. 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 <a href="http://ljug.com/sw/resploder.html">ResPloder</a> 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? Last night, instead of concentrating on "Six Feet Under", I spent my time making ResPloder scriptable. It's quite easy to do in <a href="http://realbasic.com">REALbasic</a>. 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. I'm in the process of adding scriptability to <a href="http://ljug.com/sw/resploder.html">ResPloder</a>. It's actually quite easy to add with <a href="http://realbasic.com">REALbasic</a>. 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. <a href="http://movabletype.org">MT</a> 2.11 is out. I upgraded and now <a href="http://ljug.com/sw/radioposter">Radio Poster</a> 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 <a href="http://radio.userland.com">Radio</a>, 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 <a href="http://radio.userland.com">Radio</a>, 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. It turns out I never <a href="http://developer.apple.com/dev/cftype/">registered</a> the creator code for either <a href="http://ljug.com/sw/resploder.html">ResPloder</a> or <a href="http://ljug.com/sw/radioposter">Radio Poster</a> with <a href="http://apple.com">Apple</a>. 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 <i>before</i> you ship it. Oh yeah. I forgot one Radio Poster thing I want to do. Support metaWeblog.getPost. Then you can get all of your posts and maybe put them in a DB or something. Haven't quite figured that part out yet. Things to do for the next version of Radio Poster (v1.2): 1. Support for multiple weblogs<br> 2. Use WASTEfield (maybe)<br> 3. Support Japanese (for my wife :) ) How does that sound? Things to do for the next version of Radio Poster (probably v1.6): 1. fix a problem with special characters in resource type names<br> 2. user specified type/creator for resource files<br> 3. respond to apple events (become scriptable)<br> 4. first pass as opening resource files with templates How does that sound? My next <a href="http://realbasic.com">REALbasic</a> app is going to use the new Virtual File System in <a href="http://realbasic.com">REALbasic</a>. It's going to be a bug tracking system I'm calling <i>Bugzy</i>. You'll have a form for entering all the bug info and you'll also be able to search and sort for bugs. Eventually I think I want to bake an HTTP server into it so that you can access it from the web. I shipped both <a href="http://ljug.com/sw/radioposter">Radio Poster</a> 1.1 and <a href="http://ljug.com/sw/resploder.html">ResPloder</a> 1.5 today. They are both significantly improved, but ResPloder in particular is quite nice, if I do say so myself. This version should really make it useful to people who find it useful. I'm not sure what's up next. For Radio Poster I want to add support for posting to multiple weblogs. Radio Poster doesn't really do that now. It expects that you've only got one weblog. I also want to replace REALbasic's EditField with a WASTEfield for the compose field. For ResPloder I think I want to add a preferences dialog that will allow users to set their favorite file helpers. So a user can specify on a resource-by-resource basic what helper to use to open the exploded files. I think, eventually, I want to figure out how to add pre and post processing of the data during an explosion and implosion. I found two more Radio Poster bugs. It's a good thing I'm using it before I release it tomorrow :) The first bug is a bug in <a href="http://realbasic.com">REALbasic</a>. It has a TextConverter class that I'm using to convert my MacLatin text to Latin-1 text. But it only converts 1k of text. Anything more than that and it just returns an empty string. So if your post is too long it gets sent as an empty post. Fortunately, I save all of my posts locally, so it was easy to repost after I had fixed the bug. The second bug was that I wasn't correctly encoding quotes in the XML I save as a document file. So Radio Poster's XML parser (which I wrote) barfed on the file. Fixed that too. Anybody who uses <a href="http://ljug.com/sw/radioposter">Radio Poster</a>, knows that the typing in the compose field slows down the more stuff you type. The <a href="http://realbasic.com">REALbasic</a> guys claim that's a problem with <a href="http://apple.com">Apple</a>'s text engine and that Apple is working on it. Perhaps. But I can do something about it myself. I can use WASTEfield instead of REALbasic's EditField. WASTEfield is a plugin by Doug Holton that wraps <a href="http://www.merzwaren.com/waste/">WASTE</a>, a replacement text engine for Mac OS. WASTE is used in a number of applications on the Mac (including REALbasic itself) and is quite mature. It doesn't have a problem with slowdowns when typing, but it also doesn't use ATSUI, which is Apple's going-forward text engine on Carbon. Unfortunately, there are problems with using WASTEfield with REALbasic 4.0.2, the current version. The problems appear to be solved in REALbasic 4.5, but I'm not ready to build Radio Poster with an alpha version of REALbasic. As soon as I can start using WASTEfield, however, I should be able to do quite a few interesting things. WYSIWIG editing is one thing I'd like to add to Radio Poster. Then you could just make things bold, or italic, or whaterver, and Radio Poster will figure out the tags for you. The previous post had a tag in the title and body. I was testing to see if putting angle brackets into a title worked correctly. First, it didn't work as I wasn't correclty turning it into an HTML entity. But it wouldn't work anyway as it would be treated as markup and not as content. So my "tag" ended up getting removed from the post. Actually, the tag is there in the data, but a browser, thinking it is a tag (that it doesn't recognize) strips it. This post has tags in the title but this time they are tags a browser understands. Can you guess what the tags are? came from my desktop web page and it shows the 8-bit character problem in reverse. There, the body is fine but the title is messed up. That's got to be because Radio is converting the body to Latin-1 but not the title. The posts themselves live on the Mac, so they are probably MacLatin there. But when they go up to the cloud, they need to be converted to Latin-1 or they won't display correctly on the web. So the body is being converted and the title isn't. The problem, of course, is that I need to leave Radio the way it is for now. It works. But when UserLand fixes this bug I'll need to ship another version immediately to keep in sync. That's ok, though. I don't really consider this to be the same kind of problem as the MetaWeblog API bug, which, was a showstopper, in my opinion. Well, as you can all see, that doesn't work. Very strange. It's almost as if Radio handles the body of the post as Latin-1 but the title as MacLatin. Actually, I'll be that's exactly what's going on. Why that just may be a Radio bug. I'm heading off to the discussion group to see if there's anything about it there. Wish me luck :) Now I'm converting the title to Latin-1 from MacLatin. Let's see if that makes any difference. My feeling is that I <i>should</i> be doing the conversion. The fact that I don't need to feels like a bug. I figured out my problem. As you can imagine, I was sending Mac characters instead of ISO-8859-1 (or Latin-1 or, let's face it, Windows) characters as post data. Or well :) I think there may still be a problem with the title/link, though maybe not. VFS, or Virtual File System, is something that will be in <a href="http://realbasic.com">REALbasic</a> 4.5. It's a whole file system in one file. So you can use FolderItems and such just as you would with a regular file system. But it's all in one file. So it's like a database. And it should be fast like a database. I think I've come up with my first VFS app: Buggy. A bug database. I need that to track bugs for my apps anyway. So I might as well make it a releasable app and let other people use it. A Radio Poster user has pointed out a bug. Radio Poster doesn't handle 8-bit characters correctly. They end up wrong on the web. I'm looking into it right now. It <i>might</i> be a bug in <a href="http://radio.userland.com">Radio</a> but even if it is I should be able to work around it. Nothing as serious as the recent MetaWeblog API bug, which <a href="http://userland.com">UserLand</a> fixed, thank you very much. ResPloder 1.1 does work on OS 9. It's a bit slow to explode/implode big files. I tried it on IE 5 :) It took it a good while to both explode and implode the result. But in the end I got a working copy of IE from my exploded file. I think the slowness is due to the fact that I put the explode and implode code in threads so I could make it stopable. You can even put it in the background and it behaves well. Gives you time to do stuff. But it means that it'll take a bit longer to finish. Oh yeah. And it ran out of memory. It couldn't explode all of IE 5 with the 4M I give it as its default memory setting. I set it to 10M and it worked fine. This, of course, isn't a problem in Mac OS X. I'm going to post everything from Mac OS 9 today. That should be an interesting change of pace. I haven't used OS 9 in so long. But I want to find out if there are any bugs in the OS 9 versions of Radio Poster and ResPloder before I release them next week. So wish me luck. I'm noticing some cosmetic problems with Radio Poster on Mac OS 9. In particular, the fonts are giving me fits. The system font on Mac OS X is Lucida Grande. The system font on Mac OS 9 is Charcoal. Lucida Grande looks pretty good for an edit window on OS X, but Charcoal looks pretty bad on OS 9. And REALbasic does some funky things depending on whether font smoothing is turned on. I found that if I am using a font size that doesn't do font smoothing, then my styles don't show up. I bold the title in the preview pane, but that doesn't work on OS X without font smoothing. Very strange. What I think I really want to do is switch to WASTEfield, but there are some problems with that as well. I think a lot of the problems are fixed in REALbasic 4.5, but I'm not quite sure when that will be released. I ran into some interesting ResPloder details. I knew things worked pretty well, but sometimes, if I explode and then implode I'd get something that wasn't exactly the same as the original. For example, I tried exploding <a href="http://lemkesoft.com/us_gcabout.html">Graphics Converter</a> and then imploding it back to an application. I got a file with the right icon, but when I tried to launch it nothing happened. And it wasn't the right size. A bit too small. So I investigated and found two problems. One, resources have flags. Purgeable. Locked. System Heap. I think there are five in all. I wasn't preserving those flags. Now I do. I actually write the bits as 0's and 1's into the file name. The second problem was that the names of some of the resources are so long that the filename I got when I stuck everything together was too long. And I guess there was a bug in ResPloder such that the file would be completely dropped on the floor. So I tried not saving the resource names. And then everything worked. But that can't be what I do in the final version. I want to preserve resource names. So I'm going to have to do what I didn't want to do. I'm going to have to have a separate file to store resource-related gunk and I'm going to have to put that file in the resource type folder. I have no choice, really. A test using Radio Poster 1.1 from Mac OS 9.