Database & Ed's project

The small size now works, but the option to change it is only visible on one layout and it took me a while to find it.

In general the database displays well, but it seems a bit disjointed.

I’m not clear on the hierarchy, if there is one.

It seems it should be something like:

   Framework
      Class
         Class Item
            Sample
```


Is that the case? If so I'd like to see the current hierarch for a selected clearly represented in every screen, or else I get lost very easily.

And, with the samples, I'd like to see two things. First at the top of the sample I'd like to see all of the required "use" statements:

```applescript
use AppleScript version "2.4"
use framework "Foundation"
use framework "AppKit"
use scripting additions
```

And then, I'd like to see each sample enclosed in a handler, with a working call to the handler, so that, whenever possible, a sample could be opened as in a script editor, and executed.

This is all very demanding, I know, but you asked!

I see this as something that could be very useful. Both as a stand-alone reference resource, and to use with a tutorial, or with a book like Shane's.

Ed,

I wouldn’t call what you listed demanding. I want something that will be helpful and I am willing to do what it takes to achieve that.

The hierarchy is put into the scrolling list. From left to right it is class item, class and then Framework. The “item type” is not part of the hierarchy but it seemed like a good place to put the information. Then when you go to the class layout window the hierarchy is class and then Framework. The Framework window doesn’t have a hierarchy because Framework is at the top.

Perhaps it would be better if I moved the item type column into the first column and then moved what is now first column into the second column. The list would then be class item-class-framework. That should make the hierarchy more clear.

The hierarchy can be written Framework-class-class item but that means when working with class items the column I would be most interested in looking at would be in the center which overtime could become annoying. Also it seems best to the “item type” next to the “class item.”

All the samples only use 1 type of of Framework and that is listed at the top of the window. But the use statement can be added. That way it would work “as is” when opened in Script Debugger.

I have suggested to Shane that this could be used with his book. If Shane wants to do that I don’t have any problem with that. My whole idea is to help people understand ASObj-C. If scripters used ASObj-C to it’s fullest potential then Apple would have an entirely different perspective to judge AppleScript from.

I assume Shane will continue to update his “Everyday ASObj-C” book in which cause I would not try to write a book. His book is enough to give a person the good general idea of how ASObj-C works and the database can provide easy documentation to work out the rest. Trying to make a book that fully explains all of “ASObj-C” would be insane.

I have still never settled on what to call what is currently the first column. Right now it has a long, stupid name because I can’t think of a decent name.

So I will do:
Required Framework use statements
switch column 1 and 2 in class items,

My thought on always including a “use scripting additions” statement is that it doesn’t allow the user to see the sample doesn’t require that use statement. The same thing is true for ‘use framework “AppKit.”’ It seems to me I am telling the user that ‘use framework “AppKit”’ is always requires. Some ASObj-C only require AppKit in which case I included ‘use framework “AppKit”’ and left out ‘use framework “Foundation”’ Is there some advantage I am missing to adding unneeded statements?

The problem with putting each sample in a handler is that when possible I use samples that show the ASObj-C item being used in context. In other words the ASObj-C item is used inside a larger script. Separating them out and putting them in a handler doesn’t show how the item is used in code. One of the goals of the database is how to use ASObj-C items with other ASObj-C items. Am I understanding this correctly?

Thanks for your comments : ) None of your comments bothered me or seemed extreme.

Bill

I would only include “use scripting additions” with sample script that required scripting additions, same with any of the other uses. (I was simply providing an example). In fact, if the use statement is not required, including it could be confusing.

The thing about handlers, is you can copy and paste them into a script in the context that they can be used. You send them a parameter and they return a result. Plus, if you don’t want to use the command in a handler, but want to incorporate it with other commands it’s easy to extract.

By putting every command/class/executable script into a handler you’ll also provide a high level of consistency for the reader.

(Glad you’re taking this feedback in the spirit that’s it’s given, I think this is a worthwhile project)

Ed

OK, Here’s an example about why I’d like to see the hierarchy for each item clearly spelled out.

I tried to run a script sample and found some problems with it. Just reporting which Framework, class etc. for the problem script, is more confusing that it should be.

Framework: Foundation (Root)
Class Name: NSObject
Item Type: Function
Class: className()

That should be all in one string somewhere in the layout I can cut and paste. (I could also be in the sample window itself).

Here’s the sample script:

set AppleScriptString to "Hello world"
set CocoaString to current application's NSString's stringWithString:AppleScriptString
class of AppleScriptString --> text
class of CocoaString --> __NSCFString
CocoaString's className() --> __NSCFString
__________________________________________________________________________

set TheValues to current application's NSArray's arrayWithArray:{"v1", "v2", "v3", "v4"} --> (NSArray) {"v1","v2","3","v4"}
set TheKeys to current application's NSArray's arrayWithArray:{"k1", "k2", "k3", "k4"} --> (NSArray) {"k1","k2","k3","k4"}
set TheDictionary2 to current application's NSDictionary's alloc()'s initWithObjects:TheValues forKeys:TheKeys
TheDictionary2's className() --> (NSString) "__NSDictionaryI"
(TheDictionary2's className()) as string --> "__NSDictionaryI"
class of TheDictionary2 --> (Class) __NSDictionaryI

__________________________________________________________________________

set TheNSString to (NSString's stringWithString:"12345678")
TheNSString's |description| --> (NSString) "12345678"
TheNSString's className() --> (NSString) "__NSCFString"

So the first problem is there are no “Use” statements.

Next, it won’t run because the separator you’re using is treated like a variable.

This is a case where I’d suggest using handlers to make it work.

Finally the script itself seems buggy. The last segment doesn’t run at all. I think the variable name is wrong and it’s missing a “current application”.

Here’s a version I edited that runs, and I think is a little more clear and easier to understand.

use framework "foundation"

set AppleScriptString to "Hello world"
set firstList to {"v1", "v2", "v3", "v4"}
set secondList to {"k1", "k2", "k3", "k4"}
set AppleScriptText to "12345678"

ReturnTextClass(AppleScriptString)
ReturnArrayClass(firstList, secondList)
ReturnStringDescClass(AppleScriptText)

on ReturnTextClass(AppleScriptString)
   set CocoaString to current application's NSString's stringWithString:AppleScriptString
   set ASTextClass to class of AppleScriptString --> text
   set cocoaClass to class of CocoaString --> __NSCFString
   set cocoaClassName to CocoaString's className() --> __NSCFString
   return {ASTextClass, cocoaClass, cocoaClassName}
end ReturnTextClass

on ReturnArrayClass(firstList, secondList)
   set TheValues to current application's NSArray's arrayWithArray:firstList --> (NSArray) 
   set TheKeys to current application's NSArray's arrayWithArray:secondList --> (NSArray) 
   set TheDictionary2 to current application's NSDictionary's alloc()'s initWithObjects:TheValues forKeys:TheKeys
   set dictClassName to TheDictionary2's className() --> (NSString) "__NSDictionaryI"
   set dictClassNameText to (TheDictionary2's className()) as string --> "__NSDictionaryI"
   set dictClass to class of TheDictionary2 --> (Class) __NSDictionaryI
   return {dictClassName, dictClassNameText, dictClass}
end ReturnArrayClass

on ReturnStringDescClass(AppleScriptText)
   set the NSString to (current application's NSString's stringWithString:AppleScriptText)
   set NSStringDesc to the NSString's |description| --> (NSString) "12345678"
   set nsStringClassName to the NSString's className() --> (NSString) "__NSCFString"
   return {NSStringDesc, nsStringClassName}
end ReturnStringDescClass

Shane,

I ran into a problem with FileMaker Pro 14. I can not get any AppleScript to run in in the runtime application. After a lot of fiddling I found out that the fmpro.sdef was not copied from the FileMaker Pro application to the the runtime “FileMaker Pro runtime” application. So I manually copied the file.

I copied the the sdef from:
“FileMaker Pro 14 Advanced:FileMaker Pro.app:Contents:Resources:fmpro.sdef”

I copied the the sdef to:
“FileMaker Pro runtime:FileMaker Pro.app:Contents:Resources:fmpro.sdef”

But it still didn’t work. FileMaker Pro docs at (https://community.filemaker.com/thread/149171) say this problem was fixed in version 14.0.4. I am using version 14.0.6 and the sdef was not copied automatically and even after I moved the sdef manually and it still gets the same errors as described in the post mentioned before (https://community.filemaker.com/thread/149171).

I am going to find a work around, or make a standalone applet that will copy the currently selected sample in the database to Script Debugger. The AppleScript works fine when I run it from the FileMaker pro application but fails when it is run from the runtime application.

I enclosed a compressed version of the FileMaker Pro sdef in case that might be helpful.

Any thoughts?

Bill

fmpro.sdef.zip (4.8 KB)

Here is the script to copy the AppleScript from the samples of the currently selected “item” in “class items.”

This also places a comment at the top of the script that shows what the “class item” name is as well as the class and framework names. If you don’t want that added just remove the second “set ScriptText to …” from the tell application “FileMaker Pro Advanced” block.

I’m posting this so scripters can use this functionality while I see what I can do to get it to work inside the FileMaker solution.

tell application "FileMaker Pro runtime"
	set ScriptText to cell "Samples" of current record of window 1
	set ScriptText to "-- Sample(s) of " & cell "Class item Name" & " of (class " & cell "Class Name through relation" & ") of (framework " & cell "Framework name" & ")" & return & return & ScriptText
end tell

tell application "Script Debugger"
	activate
	set NewDocument to make new document with properties {source text:ScriptText}
	delay 0.5
	compile NewDocument
end tell

Bill

Now that I think of it people using the database would probably want to do lots of open samples. On a slow computer all those separate Applet launches could add up time wise.

So here’s a “stay open” version of the script I posted earlier. It uses the “reopen” handler so if you double click the script again it will open the sample in script debugger without having the launch each time.

Here is the script:

use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions


on OnOpenInSD()
	tell application "FileMaker Pro runtime"
		set ScriptText to cell "Samples" of current record of window 1
		set ScriptText to "-- Sample(s) of " & cell "Class item Name" & " of (class " & cell "Class Name through relation" & ") of (framework " & cell "Framework name" & ")" & return & return & ScriptText
	end tell
	
	tell application "Script Debugger"
		activate
		set NewDocument to make new document with properties {source text:ScriptText}
		delay 0.5
		compile NewDocument
	end tell
end OnOpenInSD

on reopen
	OnOpenInSD()
end reopen


on run
	OnOpenInSD()
end run

To quite the applet you got to the applet menu and selected quit.

I also enclosed a working version of the Applet in this post.

Move sample to SD (stay open).app.zip (55.9 KB)

I just uploaded “ASObj-C Database a6.fmpur.zip”.

I added the ‘use framework “Foundation”’ statement to all the script samples.

I switched columns 1 and 2 in the class items layout.

The database file can be downloaded from dropbox at:

Bill

That has been fixed.

The problem there was me making assumptions. I always copied the script text between the separators, never all the text. Now that you bring this up I can see that is a poor assumption on my part. But using a “-” character would make a good separator and applescript would consider a line of them as a comment. I’ll change the old separators to a line of dashes. Thanks for pointing that out.

It’s the missing current application’s it was in there when I tested it in script debugger some how in the editing when I moved it from SD to FileMaker I must have deleted that. I should automate that process more so I don’t mess something up transferring it. It set up something where I just selected the text in Script Debugger execute an AppleScript and the sample code will be moved automatically. When I think about it it is way to easy to mess up the transfer when moving script text manually. Thanks for pointing that out.

I’ll change the separators and test each script again. This time I’ll use an automatic process to move the samples into script debugger. From now on I’ll use automated processes to move script text into the sample field in the database.

Now I understand what you were talking about with using handlers. I did misunderstand what you were saying. Although the problem seems better fixed by using a better separator unless you think is another advantage to using handlers.

Bill

Also the variable name changed, with the “the” becoming part of the variable name:

theNSString

should be

the NSString

Well I would say that anytime the example script does something useful, rather than just illustrate a point, it should be in a handler that could be used.

I find the syntax of handler calls, with parameters and handler results very instructive. In SD one could paste in a handler step over it and see what it does, or step into it and see how it does it.

Also, I know it’s more work, but I think it’s best to be consistent in the interface. It would be better if all samples were done the same way.

(I’ll have a look at the new version when I get home this evening).

Ed,

Ok, you got me, there are a lot of places where I used display dialog and didn’t add “use scripting additions.” Once I called “current time” and that didn’t have a “use scripting additions.” The “closeFile” was just plain nonsense. It was beyond wrong. I must of been really tried when I did that. There was one example where the top 3 lines were missing. copyItemAtPath had lines missing that defines the paths for the example at the beginning of the script. There are a lot of script with the beginning cut off. Apparently I can’t cut and paste with any accuracy.

18 scripts did not work “as is” when I ran the script text from the samples. This time I’m running the script straight from the text stored in the database.

I’m not sure what happened but the comment at the top of the script when it is opened in Script Debugger stopped working.

Hopefully the sample will work a lot better now.

I just uploaded ASObj-C a7 to dropbox. You can download it from:

Bill

Hmmm, those appleScripts don’t compile for me. It looks like FM Runtime doesn’t have a dictionary.

This works, but it would be better to have an in-app option. I double click on the icon in the doc to run it

I would prefer to have an in app option as well but I have to figure out how to do that since AppleScript is broke in FileMaker Pro 14. It’s on my list of things to work on but I’m trying to get the basic functionality going first.

I’m taking an unusual approach to development. Most often a lot more things are tried and worked out before anyone else sees it. The testing in this stage is referred to as alpha test. That’s why there is an “a” in front of the version numbers. The version I first posted on the discourse site was my very first screen design, mostly my first everything. Before that I had just been compiling data.

Some people might think this was improper for me to do this but showing it so early shortened the design time a lot. If I can get to some kind of beta level I can start posting it in places so other people out side the group can use it. Your input and Shane’s input helped me to make it a lot better. I find it hard to believe if people could figure out how to use ASObj-C that only a few people would still use it. ASObj-C is very powerful.

My thought for the in-app load in the database is to use some FileMaker routine to access an app that would be inside the bundle. The app would launch with the database and and quit when the database quits. Then clicking a button in the database would cause the samples to load in Script Debugger. Right now I am adding the colons and parentheses after the method names and expanding the text in the “description” and “notes” fields to make using the methods easier to use.

Bill

I think I temporarily munged my version of the database.

I clicked “Go to Frameworks List” button

Then clicked the “Framework Live Search” pop up and tried to select an item. Nothing happened. I typed a letter to jump to a different item and the popup menu was editable.

After editing the menu, nothing showed was in the Frameworks list until I clicked “Clear Live Search Field”

The Framework Live Search is no longer a pop-up, but a text entry field.

Currently I have only implemented live search for class items. It isn’t implemented in class or Framework lists. It is on the my to do list. Things came up and I haven’t been able to get to the database for a while I started again on it tonight. I created a button called “See instructive image” tonight. I was trying to explain the NSFileHandle stuff with its count starting from zero, the file offset, the file pointer, the end of file, byte numbering in a string before it’s written to a disk and the numbering afterwards, … and I decided the database needed an ability to include pictures. It’s a whole easier to explain with a picture draw in vector graphics :slight_smile:

I took me an hour and a half to get through 27 so far, so it shouldn’t be that much longer. It’s mostly a process of translating Xcode documentation into normal english :slight_smile: Then once we get this ASObj-C going the entire world will transferred into a paradise :thumbsup: but I’m stating to do the old :sleeping: so I’m done for the night. Live long and prosper. :vulcan:

Bill

Got on the searching, thanks.

You know I find stepping through a script in SD while watching variables and results is the most instructive way of learning this stuff.

That’s why I created a database that is for the most part examples. Stepping thought it helps a lot. Once you can see what’s passed in and returned it helps a lot.

Bill

I moved this discussion to a new topic called “New version of ASObj-C database version a8” It is a more descriptive name then “Database & Ed’s project.” I will post future updates to that topic.

Bill

Ed,

I did finally get the samples in the database to open directly in Script Debugger. It took me a while. I uploaded the new version under the topic “New version of ASObj-C database version a8.” It seemed weird to have a topic name that didn’t fit the topic.

Bill