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.
Bill
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.
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.
Bill
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.
Ed,
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 
Bill
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
Accounts
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).
Phil,
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.
Bill
Ed,
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
filter-list
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.
Bill
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?
Best
Phil
Phil,
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.
Bill
I uploaded ASObj-C Database a10.fmpur.zip to Dropbox. The download link is: https://www.dropbox.com/s/194vr3g554lqklw/ASObj-C%20Database%20a10.fmpur.zip?dl=0
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.
Bill
I made a lot of changes to the database. This is ASObj-C Database a11.fmpur.zip.
Here is the ASObj-C Database a11.fmpur.zip 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.
I’m posting a new version of the ASObj-C Database a12. Apparently the older version did not properly display the version number in the aboutbox. This has now been fixed. To see the version of the ASObj-C Database go to the ASObj-C menu and choose “About ASObj-C…” from the menu. The database name and version are displayed at the top of the about box.
I uploaded ASObj-C Database a12.fmpur.zip 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:
Version a12 also has some other new things.
I can remember being frustrated with NSNumbers in the beginning. Everybody told me they are a box to put things in, but never say what to do with the box. So I added 3 NSNumber properties and 5 NSNumber methods to the data base that actually accomplish something using NSNumbers. The samples for NSNumber show exactly what can be done with NSNumbers.
Changed the advanced sample for writeToFile:atomically:encoding:error: Previously it did no error checking. Now it does full error checking. This is a full error checking that properly handle errors in a meaningful way. Most of the time people just enter “missing value” for the “error” parameter. The new version shows the general process of handing errors with dialogs.
Since I used the NSError properties: domain, localizedDescription and code to handle error notification I added these properties to the database. I put the samples for NSError into the advanced Samples. This seemed like an advanced operation for beginners and perhaps those in the intermediate level. But if people want I can put in other levels as well.
The reason I used “localizedDescription” property instead of “userInfo” property to extract the NSError information was because a few time I used “userInfo” the information was displayed in a foreign language. “localizedDescription” is guaranteed to display in the correct language.
I don’t know if I ever mentioned it or not but the reason I make the modification date and creation date visible on the database is so users can tell what things were added recently and when things were initially added. I think this is useful information. But if it is a problem for some one, the only reason I can think is screen space, let me know.
Bill
I uploaded ASObj-C Database a13.fmpur.zip 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 a new feature and a few more words added to the glossary. Of the original planned features for the database all but 1 have been implemented. The remaining feature is key word searching. This is the hardest because a person has to really think about it to get a good key word list. The right key words will do as Ed said “Allow a person to find something they didn’t know existed.” The wrong words leave the user in the same state as before the key words were added or the user is in a better state but not better enough.
After the key words are done I will be focusing on mostly database entry and adding whatever feature might turn up missing later on.
The new feature is in a new window called “Display Inheritance Path”. There is a new button at the bottom middle of the “Framework,” “class” and “class items” windows titled “Display Inheritance path.” Clicking the button brings up a window of the same name. The window has a list of classes. Each line in the window starts out with NSObject (all classes ultimately inherit from NSObject) and then shows a unique line inheritance until it reaches the end of the line which means I don’t know of any more subclasses. But there could be more.
Each line has a ––> symbol. This symbol is intended to to indicate the class pointed to is receiving inherited classes from the left side. Sometimes the inheritance path will repeat a line above or below it for a while. This means both lines share the same inheritance path up to the point where the class names in the lines no longer match. For example: the lines “NSObject ––> NSString ––> NSLocalizableString” and “NSObject ––> NSString ––> NSMutableString” means there is a single path for Inheritance until after NSString, then there are multiple lines of inheritance.
The reason this is important for ASObj-C is knowing the the properties, methods, enums, … for a particular class is not enough to work with in ASObj-C. Unless you’re working with the NSObject class the current class you’re using only shows part of what can be done. When you find the class you want to work with in this list, all the things in the classes to the left of the chosen class are inherited. Unfortunately locating a decent list or complete lists of these inheritances is very hard, if not impossible, to find. So the current list of inheritances are show in this list. Overtime they may change but I would guess a good sized part of the list will stay correct for a long time.
There is also a live search that can be used on the list. The search box is in the top right corner of the window. To use this just type in the class name you are working with then only lines that contain that class will appear. This makes it much easier to find the inheritance line you’re looking for. The usual record status is shown in the upper right of the window. Also the “Show all” records, “Omit record” selected and the “Show Omitted” records not currently displayed in the list can be used to start over, or it can be used to reduce the number of inheritance lines shown.
After finding the classes that were inherited from the database, the same database can be used to find out what those can actually classes do.
Bill
I created a new topic for the ASObj-c database called “New version of ASObj-C database version a14” The old topic was getting pretty long.
Bill
Here’s some feedback…
In the script we were working on, I wanted to find each of the commands/classes/parameters in the database but couldn’t. And I realized that searching the database is a bit of a pain.
It seems that if I’m in the frameworks list a search only finds things in that list. It seems I have to know what framework, class etc. the thing I’m searching for is in to find it. If I knew that I probably wouldn’t need to search for it.
It would be nice to be able to just double-click on the framework to get to the class list, and so on.
The Previous and Next buttons at the bottom of the scrolling field don’t work. I get a couple error messages each time I click them.
What I’m really hoping for, and I’m not sure if the database is designed to do this or not, or maybe I’m just missing it, is to look up something like:
SDBundle’s infoDictionary()'s objectForKey
And see all the information I can get from SDBundle; from its infoDictionary and what object keys I would need to do that.
The post for ASObj-C has been moved to a new permanent topic called
Permanent place for ASObj-C database
All further post will go to this topic
Bill