You asked if the buttons were getting squeezed and I thought it best to show you.
Video worked here when I posted but doesn’t work now.
Is the popup to change the size of the window working ok? Is the window still usable when it’s small?
There are anchors on a FileMaker Pro layout that lock the items on the window to something. They were all set to the left side of the window which is the default setting. I’m guessing resizing wasn’t very helpful. Which is why I just added a quicky popup. I can just put in some different sizes to get it close and change the anchor points to fix that. But that takes time because each window layout has to be redone by hand for all the items on the window.
Bill
I just uploaded “ASObj-C Database a5.zip” I finished implementing the popup to switch window sizes. But the window sizes only works on the “items for classes list” window for now. The menu items in the popup for changing window sizes indicate the screen sizes that the windows were designed for.
I rearranged the items on the smaller class items window so things would fit. I expanded the help text, added an “Extra info topics” popup menu and fixed some bugs. I also included a TextEdit file that is a copy of the help file included in ASObj-C a5 for anyone who wants to look at it. It lists what the database does.
Both the database file and the help file can be downloaded from dropbox at:
I think this will move the database far enough along that people can use it while I enter in more data. Then every so often I can just upload a new version with more data.
Bill
I tested two ways to open the database.
(1) press control key while opening the runtime application.
I got a warning claiming that “Le fichier principal “ASObj-C Database” requis pour cette application est introuvable”
Clicking the [OK] button in the warning open the open file dialog
(2) drop the database file onto the runtime application
I got a warning claiming that “Le fichier principal “ASObj-C Database” requis pour cette application est introuvable”
Clicking the [OK] button in the warning open the open file dialog
So it seems that there is no real difference between the two process but maybe I missed something.
koenigyvan,
Were you able to open and use the ASObj-C database?
Bill
Yes, the two schemes behaved flawlessly.
I saw some erroneous details.
In an example related to arrays, an instruction returning the length of 3 strings correctly return {1, 2, 3} but you wrote {3, 3, 3} 
In the glossary I read :
quoted form: This is a command built into AppleScript. It has a single parameter for the
I guess that the end of the sentence is missing.
As you see I retrieve my old habit : point things which are “wrong” even if most of them are right.
koenigyvan,
I haven’t finished the glossary yet. The {3, 3, 3} is a typo. I type those in after I run the script in Script Debugger. Thank’s for passing that on. I’ll fix it. If you find any more let me know.
Bill
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