New version of ASObj-C database version a8

I cleaned up some stuff that needed cleaning up.

I updated the glossary by filling in definitions. I updated help information so it is now current. I added more examples to the database examples. These example deal more with boundary conditions where bugs often occur.

I put a copy of the updated help and glossary in an “TextEdit” file with the new database file. Everything in this post is also in the help file with more detailed explanations.

I added a new feature called “Has Image.” An “class item” can have an image associated with it for purposes of better explaining something. There is a button that the user clicks to see the image. When looking at the database in class items view there is a new column in the big scrolling list. This column is called “Has image” and if there is a brown check in the column the class item has a image associated with it.

I changed the entries in the database for methods to “Class Method”, “Instance Method” and there’s 1 “Class Property” thrown in as well.

I updated the menus in the database program so they have less menu items that don’t do anything useful and took out a couple of menus that didn’t do anything useful.

The database has a menu item called ASObj-C on the far right of the menu bar. The first menu item in this menu is the “About box” for the database. This also lists the version number. Below that about box are a couple of menu items that do preset searches of the database. Then there’s a hierarchical menu item with some more preset searches.

My sister has been having some construction done and I’ve been involved in that so I haven’t got much done lately. But I will be getting back to adding to the database now that the construction is over.

I uploaded the new database, help file and glossary to dropbox. The link is:

I noticed after I downloaded what I had just uploaded that the information in the database for the glossary is the old information. The Glossary.rtf file included in this post has the new and corrected text.


This looks interesting. I can‘t open the .fmpur file — isn‘t it possible to distribute a standalone File Maker Pro document that doesn‘t require the application to read it?


I’m posting version a9 of the “ASObj-C Database.” It took me a while but I finally got the ASObj-C samples to open up directly in Script Debugger from the runtime app. It opens directly from the database and does not use any kind of intermediary apps. A new window opens in Script Debugger, the text appears and then it compiles. AppleScript in FileMaker Pro runtime is completely dead and there is no direct connection between AppleScript and FileMaker Pro for version 14 so it was fun doing that.

This is version a9. The only change between this version and version 8 is the ability to open samples in Script Debugger directly. Now I’m going to go back to adding new entries into the the database.

Version a9 can be downloaded at the following dropbox link:



FileMaker Pro is a full database package that can create an application which allows people to use a database without having to own a copy of FileMaker Pro. Without the App I post, or FileMaker Pro, you can’t run it.

But it is a bit weird to get it launched and some people have had a hard time signing into the program. So far I haven’t had anyone who couldn’t sign on eventually. I ended up helping a few people.

To give you an idea how it works there is a file called “ASObj-C Database.fmpur” which is where the data is stored. There is an application called “FileMaker Pro”. This is the application that does all the FileMakerPro database stuff. It is like the commercial version that is a full powerful database but the runtime version that I posted does not allow people to create new databases from the one I posted. There is also a folder called “Extensions” that is used with the program. All 3 of these have to be in the same folder for the database to work.

The “FileMaker Pro” app and the “Extensions” folder can be downloaded from a dropbox link at:

There are different ways people open the database.

Shane commented on the database saying "I don’t think your description of how to open it allows for the fact that it will be quarantined on other users’ Macs. I suspect the easiest method is to control-click on the runtime and choose Open, and then choose the database file in the dialog that comes up. At least, that worked here.

I myself just drag the file “ASObj-C Database.fmpur” file on top of the “FileMaker Pro” and let go but as Shane pointed out that might not work for everyone.

If you still can’t get it to work just leave a post and I’ll see if I can help you get in. I want everyone to be able to use the database.


Hey, Bill, for your samples, how would you feel about using something like this, so that they would run on anyone’s mac?

use framework "Foundation"
tell application "System Events" to set userName to name of current user
set NewFolderURL to current application's class "NSURL"'s fileURLWithPath:(("/Users/" & userName & "/Desktop/") & "TheNewFolder")

--file "Macintosh HD:Users:stocklys:Desktop:TheNewFolder"

This sounds like a good idea. The the example would run on anyone’s Mac without needing any adjustment.

There is a shorter way to get the path:

((current application's NSHomeDirectory()) as text) & "/Desktop/TheNewFolder"

This uses a function defined in foundation but it’s not part of any class so there is just the current application’s in the front.


OK another early impression of the database.

I think it might be better if these things were labeled and organized (or could easily be organized, as with a relational database) by use and function, in addition to ASObj-C’s hierarchy. Both are useful.

If I’m looking for something that’s going to give me a home directory, for example, I would never know how to find it unless I already knew what it was. A search for “home Directory” turns up nothing. I’d need to know “NSHomeDirectory” but if I already knew that maybe I wouldn’t need the database so much?

Also, while this is perfectly fine appleScripting,

I’d have to see how you use it.

I know programmers and AppleScripters (myself included) often like to use compound commands that may include multiple apple Events.

I believe it is far more instructive to provide samples that use only the minimum appleEvents required to illustrate a specific command.

For example, if you were trying to illustrate the “open file” command it would be more instructive write:

set afileToOpen to choose file

open file afileToOpen

set the openedFile to the result

than it would be to write

set openedFile to open choose file

The first might be longer and maybe everyone on this list would prefer the second in their scripts, but I think the first is more clearly instructive when it comes to illustrating that command.

That example is as simple an example as I could think of.

ASObj-C commands, are inherently more complex, just in their syntax and punctuation.

I would go so far as to say that it’s best if there are no coercions or concoctions on same the line what you’re illustrating. Use a clearly named variable to do all of that and maybe even a second or third line in a script.

The goal in the database scripts is not to write short, elegant and compact code.

The goal is to clearly illustrate the function, use and potential of the specific command or concept the user is looking at.

I hope that makes sense.

1 Like

I agree that text spread out on to more lines are generally easier to read and for someone who is not familiar with ASObj-C then this is a necessity. But for the line shown above I left it all on the same line because it seemed like it was more natural to see the beginning and then the end of the path on the same line.

I put something like the line below in one line:

current application's NSArray's arrayWithArray:{1, 2, 3}

instead of typing:

set TheAppleScriptList to {1, 2, 3}
current application's NSArray's arrayWithArray:TheAppleScriptList

because it seems more straight forward. Would you disagree with that?

Nearly all the Foundation framework is broken down into classes and to some extent that serves to break things down by use. But there are some Foundation functions that don’t belong to any class. In this case unless you knew this functions existed, knew where to find them and understood what they did once you found them them it would be difficult for someone to ever end up using NSHomeDirectory(). I’ve looked at the layout of all of Foundation and the functions not placed in a class are the most surprising when you find out about them.

I never seen an example of HomeDirectory. I just read the description, knew it was function and it was straight forward. But someone with little or no experience would not be likely to figure it out. In this case examples are essential. But what category would you put this in? Having a lot of categories with 2 or 3 items creates a different problem. Namely the difficulties of navigating a large list of categories. Categories can have sub-categories and those sub-categories can have sub-sub-categories and so one which is easier to navigate but a lot more complex to create. If breaking down into more and more categories goes on too far then it also becomes harder to find anything in the list. ASObj-C just goes all over the place when it comes to implementing methods. Breaking them down by class was the best I could come up with at the time. Do you have any thoughts on how to break down the commands and functions?

In a relational database braking down data by some type of category is simple to implement but the trick is figuring out what those categories, classifications, assignments, … would be. The classes provide a good starting place to look as long as the searcher know what the different classes do. I put a description on some of the classes in the class list. But I could finish filling in the list.

If you have any suggestion for how to break down various commands and functions feel free to send them to me. Relational databases can have lot of different keys to sort by, as well as determining if an item should be shown or hidden. The real trick is coming up with keys that are actualy helpful.

Coercions go on all the time with the bridge. I would probably add a comment to point out the coercion but I think eliminating coercions altogether might be hard to avoid in all cases.

I agree with this 100% This is my goal with the entire database.


I would say it’s less instructive. You’re not teaching people how to write natural or straight forward AppleScripts.

You’re instructing them on the capabilities of ASObj-c. By using well named variables you can make it clear what the actual command is; what kind of value it accepts and its result is.

It’s also important to be consistent. To follow the same basic style for every sample.

I don’t see that at all. Did you at first?

Also, I hope I didn’t confuse things when I used the word “Function.”

I wasn’t meaning “Functions” per se, but I meant what the script actually does. It’s purpose.

From my point of view, based on looking at the database; having read Shane’s book when it first came out (and, admittedly not doing much with it since); it seems like a huge mass of various random things ASObj-c can do but you need to know each one before you can use it.

There is no way to, for example, find out “Is there any way to do X?”

It’s like "Command y for Framework z will do X, so just lookup command y in framework z and see what it does.

The only way to approach it from the “I need a script to do x” now is to ask on AppleScript users and hope Shane has an answer.


First I want to say I really liked your responses. They were direct and to the point and made some of the short comings of the database as it now very clear. Understanding the problem is key to fixing an design issue.

Ok I see your point. It is not just less instructive it’s not instructive at all. It is straight forward to me because I understand what is happening behind the scenes. People less familiar do not understand what the bridge is doing and what ASObj-C is looking for. Both of these become clearer when it is broken down into more steps with comments inserted to explain what is going on.

This is true in most cases by far. But if a particular thing comes up that does not lend itself to the current style and the current style is working very well then it doesn’t make sense to discard the current style. In this case I would deviate from the current style if made the explanation better. If it comes up a lot then perhaps the general style needs to be altered. But what I have learned over time is the longer someone is into a project like this the more compelling the problem has to be to change the general style. The reason being that people get stuck in finding the perfect style which leads to endless changes or poor illustrations of a concept. Also the time spent to go back and change previous entries to match a new style becomes more costly the larger the database is.

I can look at the style I’m using and see if the style is wondering. I didn’t think it has but maybe it did. Less then 100 items can be redone is short time. But 300 is a lot harder and 500 is no fun at all, but over a thousand is pretty much forget it for a 1 man operation. I can’t be redoing that many examples. I am expecting to have a minimum of well over a thousand different class items. Perhaps it would 2 thousand to make it a decent usable database. There are a lot of methods, functions, constants, … in Objective-C. At the moment I do not know how many Objective-C things can be done in ASObj-C. I have to try everything and see what happens. It’s a big task but I’ve done things like this before.

I did confuse things but I am unconfused now.

I have work with a number of large massive object-oriented things and have gotten used to it. But if I think back I can remember wondering how do I know where to start in such a large mass of things. The answer is just pick a spot and just start trying. But it can take a few years of banging one’s head against the wall before you just surrender to the inevitable and just pick a place and start. Then slowly, sometimes very slowly, it starts to make more and more sense. This part can also takes years.

The problem with this process is many people just quit and find less demanding methods. I was a research assistant and also did this for a living and was forced to learn it. But for learning ASObj-C, learning it will be optional for nearly everyone. ASObj-C is never going to get off the ground until the learning curve can be reduced a lot. Shane’s book is an excellent start to learn the general principles but the documentation is just not accessible enough for scripters. I’ve seen cases where it was not accessible enough for developers.

I’m am very grateful you reminded me of this in your response. I need to remember this. This is key to getting ASObj-C to be accepted by a large portion of AppleScripters.

Once you put what you wanted in a very clear sentence it made solutions more obvious. For databases keys are used for just about everything. Before I talked about keys that divided all the entries in the database into different pieces, i.e. each item has 1, and only one, key. But each of the items can have many keys. For this type of situation you are looking for something that implements all the requirements spelled out by the keys.

For something like this, one solution would be, the user enters an unordered list of keywords. Then the database would list class items that fulfil the requested features. The list produced would be ordered by:
first class items that met all requirements, then
items that met the requested features minus 1
… … … … … … … … … …, down to
items that only have 1 of the requested features.

Other rules can be defined to rank one class item over another when they both have the same number of requested feature matches. There are a huge number of tweeks to determining the order so the best matches are higher in the list. This is the whole reason I wanted to do this in a database is because the match list can be tweeked. This is something a book on the subject can never do.

There are a lot of ways to rank search matches. The way to pick which method(s) to use is to figure out the requirements and then implement best implementation given all the known constraints. Picking the implementation type is my problem but figuring out the requirements is something everyone can contribute too.

Based on what you said I think multiple, well chosen, keys along with rules applied, would give you the chance of getting a database that can tell you if there is a way to do X and this could be done a reasonable timeframe.

The thing that anyone could do is suggest good keys to use for searching a database, or in other words tell me what kinds of general things you want the database to search for. I can easily give the database some rudimentary intelligence to allow it to parse database entries and recognize certain types of things. For example use the parts of the method parameters and name (all the stuff before, after and in between colons) as keys to match against the user request. Having a database aware of synonyms can find even more matches without a lot of extra work but if that gets too fancy it can slow the database down. The point is there are a lot of ways to attack the problem you pointed out. Using methods involving keys with something like this could be up and running in a week, maybe 2 weeks. Keys are easy and FileMaker can process them quickly.

I laughed when I read this part. It is so true :smile:


I was thinking about how to organize into categories and I realized there’s already a way.

AppleScript suites. Nearly every command or function could be categorized with one (or more) of the existing suites in Finder; system events; or standard additions. Plus, it’s terminology that the appleScripters are already familiar with.

The Home Folder command could easily identified in these suites

Disk Folder File
File Commands

No reason to limit a single command to a single suite.

(I’ve glad you’re taking my feedback in the spirit it’s given!)

TBH, I think that boat has already sailed. Both languages are on their way out in the grand scheme of things.

Still, on a less pessimistic note, I’ll say that the learning curve isn’t really anything to do with ASObj-C itself but with the Cocoa APIs. When Shane first brought out his pdf books on this, I dived right in, but I soon got lost once I was outside of the examples in his books because I just didn’t know how to navigate my way around Cocoa. For that reason, I decided to learn Cocoa and Objective-C directly. That did take a couple of years head-banging (largely cos I’m a bit thick), but eventually I got the hang of it.

Once you’ve learned Cocoa, and you’ve got Script Debugger to hand, it’s a fairly easy matter to follow the translation rules to convert things from Obj-C into ASObj-C. However, with the exception of powering up a few dusty AppleScripts, the use-case (at least for me) is far from clear. Basically, if I need anything much more powerful than vanilla AppleScript, I might as well go ahead and write me a full-on Cocoa app (a lesson I remembered the hard way just last week with my Disk Inspector project).

1 Like


I found your post interesting. It points out a number of things I would like to comment on but I have to be very specific about how I see thing. This doesn’t mean I’m attacking your view point, but without being specific I can’t say much that is worth reading.

You are right, I keep talking about Objective-C when what ASObj-C is wrapped up in is the Cocoa portions of Objective-C. But I do not agree that it is easy for scripters to translate Objective-C to ASObj-C. That is the whole reason I am doing the database. It might be easy for Objective-C programers to translate to ASObj-C but the reverse is most definitely not true.

The important thing to remember is most people when faced with a steep learning curve find another option. You were one of the people that stuck with it. When it comes to masses you are the exception, not the rule.

I have been with AppleScript since day one. This language has been buried a few times by now. I’ve hear all about the ship that has sailed a few times over the years but so far the ship never quite gets out of the harbor. When it comes right down to it Apple is interested in a scripting language that will empower “many, many” users and will draw in new customers. They are looking for a scripting language that is a “marketing asset.” AppleScript being useful is not enough for the Apple executives. AppleScript has never been the asset the executives are looking for. This is because the language has never risen above a small niche market. This in turn is because Apple never made it accessible to the masses before ASObj-C was released, and it has gotten worse since. Apple tried automator and it flopped as well because it was too tedious and a lot of work just to enter a simple command even when the coder understood automator well.

Since Apple has gotten rid of the automation department nearly everyone says this is the end. To follow that reasoning then Apple is getting rid of all automation, not just AppleScript. They didn’t close down AppleScript, they closed down automation. Apple has failed to produce a scripting language that is accessible to the masses and decided to stop throwing money into a project that has not produced the results that Apple executives wanted. This is all know to be true. The rest is built on speculation. ASObj-C is a good idea but it was implemented badly. But still the language has tremendous power.

Objective-C is old school stuff and swift is the new school stuff. While Objective-C won’t go away soon, it is on it’s way out. Objective-C has the same weakness. It has a steep learning curve. I’ve looked at swift and without ever learning swift I can tell what the program is doing and while I am familiar with Objective-C it is still harder to figure out what is going on. Every developer I’ve talked to says Objective-C is slowly on it’s way out. AppleScript may well be slowly on it’s way out as well. Should developers all stop using Objective-C now. This has not been the case so far. ASObj-C and Objective-C suffer from the problem. They are both wrapped up in Objective-C and Objective-C is not a well designed language. ASObj-C can be run with swift. But currently there are a number of difficulties with using swift with ASObj-C. If ASObj-C was used with Swift the situation might be very different. There as some trying to get ASObj-C to work with Swift. But Apple doesn’t seem all that interested in this either.

The whole reason I’m doing the database is because if AppleScript can become what the Apple executives are looking for then AppleScript has a decent chance. If it can’t then we are left with nothing as far as scripting languages go. Everything with OSX scripting will eventually wither away. The Objective-C you are using now will be slowly phased out and in the end you will have to learn yet another language. TBH Objective-C could be like AppleScript has been and remain on the edge of being replaced for decades. For that matter it might not be dropped in your lifetime. Who knows.

I am not sure what your post was advocating. Perhaps the post was just your thought on the subject. But I am curious where you see automation in general going at Apple.



It is an interesting idea to organize ASObj-C commands in the way AS dictionaries are organized. That sounds like a good idea. That addresses the issue of organizing the keys.

But there is also the matter of how the keys themselves are formed. One thing I have used is a key that starts with a verb, sometimes a noun follows, but the end is usually the part that varies the most. For example here are some verbs:

add			create		move		set
calculate		delete		read (data)	sort
check			filter		rearrange	store (in data structure)
compare			find		save (file)

Here are some keys:
add-file-with preset data
find-text-in list

This allows the user to specify an action, a target of the action and then other details to add without being more specific then that.

This is 1 possible way for people to specify what users are looking for. This is a small example to give you an idea of how it could be done. A real list of keys would be bigger. But the example shows how the keys can match a number of different examples or commands. The keys need to be abstract enough to match different commands, without being so abstract that too many commands are matched. The abstractness is really important to how effective the keys are. The example I showed is one I came up with quickly without much thought. But it shows the general idea.


I think that point got garbled somewhere. I was trying to say that if you’ve learned Objective-C, you can use AS-ObjC without much extra work (though I shied away from it myself until I started using SD 6, which makes the translation much easier). I most certainly AGREE that scripters who are not already au fait with Objective-C face a daunting challenge. But that’s where I started: my point is the challenge is really in understanding how the Cocoa APIs work and getting a feel for how object-oriented programming works so that you can plug the API calls together lego-like.

Yes, I’m afraid I wasn’t being that helpful - I was really just trying to point out where I saw the difficulty. Where do I see scripting going? I’ve been looking at PowerShell. It’s frightfully interesting. As for the mac, we’re all in the dark where Apple are going with anything - part of my increasing frustration with the platform - and I’ve no idea what will happen to automation.

That said, I’m not knocking your efforts. It’s valiant work, but I’m not sure who your audience is. I think the Filemaker format isnt’ helpful. I don’t have it, and I couldn’t get your app past Gatekeeper*, so I haven’t been able to view your database save for the Glossary and Help .rtf files. Is it possible you can get someone else to codesign it if you don’t have the ability to do so yourself?



  • I don’t mean that I don’t know how to open an unsigned app; I mean I’m not willing to open an unsigned app. There’s little point in having Gatekeeper at all if the user just overrides it when they come across an unsigned app. Hence, I make a point of never doing so except on a quarantined VM when I’m playing with malware suspects (a hobby).


Normally when I create a FileMaker Pro solution the customer has FileMaker Pro and I don’t need to use the app. The App is stripped down version of FileMaker that doesn’t allow the user to create any new solutions. But I’ve never needed to use the app before. It has proved disappointing to me as well. Worse yet AppleScript in the application is broken. That has lead to some fun experiences getting around that. But I can’t expect scripters to go out and buy a copy of FileMaker Pro so I am using the app.

I don’t have an account to do code signing so I can’t do it without paying for it.

I am using FileMaker Pro 14 and the current version is 15. In version 15 FileMaker redid the whole thing with the app. I suspect they did that because of the code signing problem. But I usually buy every other version and FileMaker 16 is a ways away. Even with the upgrade price that’s between $250 to $300 so I’m not real thrilled with that option.

Perhaps I will find a cheaper way.


I uploaded ASObj-C Database to Dropbox. The download link is:

For anyone who doesn’t have copy of the app to run the file it is uploaded to dropbox. The download link is:

• This version has all the correct colon or parentheses at the end of the method or function calls.

• I corrected one entry which had the wrong samples file.

• The live search for “Class list” and “Frameworks list” are fully functional.

• Added a status info field in the upper right of the Framework window just like what is found in the “class” and “class item” windows.

• Changed the “show all”, “show omitted” and “omit record” so when any of these are clicked any text in the:
“Class item Live search” or “Examples Live Search” will be cleared,
text in the “Class item Live search” will be cleared, and
text in the “Framework Live search” will be cleared.


I made a lot of changes to the database. This is ASObj-C Database

Here is the ASObj-C Database link

For anyone who doesn’t have a copy of the app to run the file it is uploaded to dropbox. The download link is:

I made a lot of changes to the database. I took ed’s idea of a database with basic intro stuff in it and expanded it. There are now 3 type of examples: Beginners, Intermediate and Advanced. The user can select which one to view. To implement this I added 3 buttons to the bottom of the screen labeled: Beginners, Intermediate and Advanced. These button a have a thin red rectangle around them to show they are related. Just to the left of the buttons is the word “Samples” in red. If there are no samples for a particular level of example for a class item the corresponding button will be dimmed on the class items window. The smaller screen size window did not have enough space on the class items window after adding the buttons so I moved the button “Open sample in SD” on the class items window to the ASObj-C menu and gave it the menu item name “Send Sample to Script Debugger” and gave it a keyboard shortcut of option-command-S (⌥⌘S).

The database can open more then one “sample window” at a time so the sample in the frontmost window will be sent to Script Debugger when executing the “Send Sample to Script Debugger” command. If the front-most window is not a samples window it will error with the text “Either the front window is not a samples window or the script failed to recognize the window was a samples window.”

The actual send to SD command can be initiated by choosing “Send Samples to Script Debugger” in the ASObj-C menu or pressing ⌥⌘S

It is possible to open the Beginners, Intermediate and Advanced sample all at the same time in three different windows for the same class item if you want to compare them. They can be compared in FileMaker or they can be sent to Script Debugger and compared.

The samples column is still in red on the “class items” window. But instead of having a check mark like before there can be any where from no characters to three characters in the “Has Samples” column for each line. If there is a capital letter “B” in the column then there are samples for beginners. If there is a capital letter “I” in the column then there are samples for Intermediate level users. If there is a capital letter “A” in the column then there are samples for Advanced users. If there are no letters in the column then there are no samples for any level of user yet. As I add to the database this situation will almost certainly come up from time to time. Multiple letters means there is more then one level of sample for the class item. It is tough to figure out what kind of sort to use for this column. I went with a straight alphabetical sort for lack of a better idea. But that sort does make it easier to figure out what is there as far as example levels.

I moved the “help” and “glossary” buttons from the “class items window” to the ASObj-C menu with the menu names “Show help…” and “Show glossary…” receptively.

Since I figured people would like a way to see database entries that are geared to the level they are comfortable with I added three additional items to the ASObj-C menu named: Find All Beginning Samples, Find All Intermediate Samples, Find All Advanced Samples. Selecting any of these menu items will select just those database entries. To see all the entries again click the “show all” icon in the top left corner of the class items window. Right now the samples I had before this release were all put in the intermediate level. As time goes on I can put more in the beginning and advanced parts.

Did one Advanced and Beginning example so people could see the difference. The NSString method
writeToFile:atomically:encoding:error: has all three levels. Since the constant NSUTF8StringEncoding has the same samples I also copied the same beginning and advanced samples to that entry as well.

Added a preference window to the database. This can be opened by choosing “Preferences…” from the ASObj-C menu. Currently there is only one thing in the preference dialog to turn off a feature that will copy the name of the method to the clipboard when the the method is clicked in the class items list. This feature is not done yet so the preference currently does nothing right now. But a lot of other preferences are possible. Not every person is going to like the same interface. I thought another thing to put in preferences would be a choice to choose what kind of keyboard short cut to use for the ASObj-C menu items.

In the “first column” on the left of the class items window the text is displayed in purple if the item being referenced is a constant.

Changed the column name from “Class, “Foundation function,” … name” (second column from the left) to “Methods, Functions & Property names”, for the class items window.

Added another “Extra info” topic about “Foundation Functions”

There were a number of small fixes made in this version. They are listed at the end.

Fixed the “record status” problem when switching layouts. It now works correctly.

The sort problem when clicking the “framework name” column heading in the “framework layout” has been fixed.

Removed the underline below “Description” in the column heading in the “framework layout” since the column is not sortable.

Fixed the sort for “has description” and “has notes” in the framework layout. They now sort correctly.

Fixed the sort for “framework name” in the “class items” layout.

Removed the “script trigger” for selecting the “item type” or “class item name” in the “class items” list since it is no longer used and creates an error when clicked.

Bill Kopp

Some screenshots would be nice, Bill (and tempt lurkers to give it a whirl…).

Is there a way to tell which version of the downloaded database is displaying? It would be really nice if there was something, small is fine, that says Ver. a19 or whatever.

I believe I installed the new version but I can’t really tell.