I am attempting to use the Text Suite in my scriptable Mac app.
The little documentation I found in the Cocoa Scripting Guide suggests to use NSTextStorage. But it does not explain how the rest needs to be set up, both in the Sdef and on the coding side.
In particular, I wonder how I tell my scripting definition when to use the Text Suite with its richer commands and when not. The problem I see is that the Text Suite declares its own type named text. But that's already a predefined type used for plain text as well.
So I end up with two choices of "text" in the Sdef editor's text selector for my elements' properties, and to the Sdef that gets written it's the same type. Meaning I cannot make a distinction in the Sdef between properties that handle text that supports the Text Suite and those that don't, even if my code doesn't always use NSTextStorage for them.
Does that mean that I need to store all my scriptable properties in objects of class NSTextStorage? Otherwise, a user may expect to use the extended Text Suite commands on any textual property but will get runtime errors if I use NSString instead of NSTextStorage for them, right?
But for simple properties that only give simple plain text strings back, such as the app's name, it would be overkill to support the Text Suite, doesn't it?
So, how shall I go about this? Shall I simply let the user figure it out when he can use the Text Suite and where not because I use NSTextStorage only for properties that I deem worthy of the rich text support? How do others solve this?
Update
Turns out that when I simply add the Text Suite to my Sdef (I'm using the one the Sdef editor offers as "NSTextSuite" under its File submenu), all properties that return text stop working (causing error -10000). I've compared the Text Suite entries to those from other apps and cannot see any obvious differences.
Why would adding the Text Suite break all properties that have a property of type "text"?
What follows is an abbreviated Sdef so you can see what I'm doing:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE dictionary SYSTEM "file://localhost/System/Library/DTDs/sdef.dtd">
<dictionary title="Demo Terminology">
<suite name="Demo Suite" code="Demo" description="Demo suite">
<class name="application" code="capp" description="The application's top-level scripting object.">
<cocoa class="NSApplication"/>
<property name="demo text" code="DeTx" description="A text prop for testing" type="text">
<cocoa key="testText"/>
</property>
</class>
</suite>
<suite name="Text Suite" code="????" description="A set of basic classes for text processing.">
<cocoa name="NSTextSuite"/>
<class name="text" code="ctxt" description="Rich (styled) text" plural="text">
<cocoa class="NSTextStorage"/>
<element type="paragraph">
<cocoa key="paragraphs"/>
</element>
<element type="word">
<cocoa key="words"/>
</element>
<element type="character">
<cocoa key="characters"/>
</element>
<element type="attribute run">
<cocoa key="attributeRuns"/>
</element>
<element type="attachment">
<cocoa key="attachments"/>
</element>
<property name="color" code="colr" description="The color of the first character." type="color">
<cocoa key="foregroundColor"/>
</property>
<property name="font" code="font" description="The name of the font of the first character." type="text">
<cocoa key="fontName"/>
</property>
<property name="size" code="ptsz" description="The size in points of the first character." type="number">
<cocoa key="fontSize"/>
</property>
</class>
<class name="attachment" code="atts" description="Represents an inline text attachment. This class is used mainly for make commands." inherits="text">
<cocoa class="NSAttachmentTextStorage"/>
<!-- This property should be deprecated like all the other path-centric properties, and replaced with a type="file" property. -->
<property name="file name" code="atfn" description="The path to the file for the attachment" type="text">
<cocoa key="filename"/>
</property>
</class>
<class name="paragraph" code="cpar" description="This subdivides the text into paragraphs." inherits="text">
<cocoa class="NSTextStorage"/>
</class>
<class name="word" code="cwor" description="This subdivides the text into words." inherits="text">
<cocoa class="NSTextStorage"/>
</class>
<class name="character" code="cha " description="This subdivides the text into characters." inherits="text">
<cocoa class="NSTextStorage"/>
</class>
<class name="attribute run" code="catr" description="This subdivides the text into chunks that all have the same attributes." inherits="text">
<cocoa class="NSTextStorage"/>
</class>
</suite>
<suite name="Standard Suite" code="????" description="Common classes and commands for most applications.">
<cocoa name="NSCoreSuite"/>
<class name="color" code="colr" description="A color.">
<cocoa class="NSColor"/>
</class>
</suite>
</dictionary>
Running this script will then result in error -10000:
tell application "Demo"
demo text
end tell
If I remove the "Text Suite" from the Sdef, the code runs without error.
Looks like the Text Suite that the Sdef Editor offers is not usable for apps using the Cocoa Scripting framework. Nor can one adapt the technique that "TextEdit.app" uses, where the text class gets an id assigned ("text.ctxt"), which is then used with property types that shall use the Text Suite's text class.
Instead, the one from the "Sketch" sample code should be used. That one renames the type from "text" to "rich text", thereby solving the issue of conflicting type names I have described in my question.
I find it curious that that "classic" apps use the type "text" for both plain and rich text properties, whereas that appears not possible any more with modern apps that rely on the new Cocoa Scripting framework.
I believe there is an error in the generated SDEF in the line:
<cocoa name="NSTextSuite" />
The tag is used to reference classes or variables in your code. There is no class named NSTextSuite in the framework, afaik. The text suite definition should start like this:
<suite name="Text Suite" code="????" description="...">
<class name="rich text" plural="rich text" code="ctxt" description="Rich (styled) text." inherits="item" hidden="yes" >
<cocoa class="NSTextStorage"/>
<type type="text"/>
...
Related
I created the following report:
<?xml version="1.0" encoding="UTF-8"?>
<report xmlns="http://www.eclipse.org/birt/2005/design" version="3.2.23" id="1">
<property name="createdBy">Eclipse BIRT Designer Version 4.6.0.v201606072122</property>
<simple-property-list name="includeResource">
<value>Resources</value>
</simple-property-list>
<property name="units">in</property>
<method name="beforeFactory"><!
[CDATA[reportContext.getDesignHandle().setStringProperty("locale",
params["__locale"].value);]]></method>
<property name="iconFile">/templates/blank_report.gif</property>
<property name="bidiLayoutOrientation">ltr</property>
<property name="imageDPI">96</property>
<parameters>
<scalar-parameter name="__locale" id="8">
<property name="valueType">static</property>
<property name="dataType">string</property>
<property name="distinct">true</property>
<list-property name="selectionList"/>
<property name="paramType">simple</property>
<property name="controlType">text-box</property>
<structure name="format">
<property name="category">Unformatted</property>
</structure>
</scalar-parameter>
</parameters>
<page-setup>
<simple-master-page name="Simple MasterPage" id="2">
<page-footer>
<text id="3">
<property name="contentType">html</property>
<text-property name="content"><![CDATA[<value-of>new Date()</value-of>]]></text-property>
</text>
</page-footer>
</simple-master-page>
</page-setup>
<body>
<label id="7">
<text-property name="text" key="offerte.offerte"></text-property>
</label>
<label id="9">
<text-property name="text" key="offerte.klant"></text-property>
</label>
</body>
It works great, but now I want to use a datasource instead of the properties file. Anyone know where to start?
A properties file is the "standard" way to support internationalization in BIRT, but you can do it any way you like.
For example, in our application we are using a SQL database. All the translations are storend in tables. The output language is specified as a report parameter. Each and every translation is done on this basis.
For example, we are never using labels. Instead, we use dynamic text items (with plain text or html depending on the circumstances.
A little javascript function pr(x) returns the translation for a text x.
We do all the date and number formatting with SQL if possible (I don't know if it is possible to change the "format date" and "format number" properties dynamically - this might work as well).
I'm getting the following error when trying to change a custom work item's state through Visual Studio:
The field 'Assigned To' contains the value 'Seth Denburg <Project\SDenburg>' that is not in the list of supported values.
During the state transition the value from another field is copied to the System.AssignedTo field. This error stopping me from resolving a related work item during my check in through Visual Studio.
I've noticed the following alternatives allow me to successfully change the state which could help point to what the issue is:
Changing the work item's state in the web interface. No errors are displayed here.
Reentering the user's name in the field being copied from before the transition in Visual Studio.
Reentering the user's name in the System.AssignedTo field after the transition in Visual Studio.
Here is a subset of states, transitions, and fields from the custom work item type definition that I think are related to this issue:
<FIELD name="Assigned To" refname="System.AssignedTo" type="String" syncnamechanges="true" reportable="dimension">
<ALLOWEXISTINGVALUE />
<VALIDUSER group="Project\Users" />
</FIELD>
<FIELD name="Lead" refname="Project.Tfs.Lead" type="String" reportable="dimension">
<ALLOWEXISTINGVALUE />
<DEFAULT from="value" value="Seth Denburg" />
<REQUIRED />
<VALIDUSER group="Project\TechnicalLeads" />
</FIELD>
<STATE value="Pending">
<FIELDS>
<FIELD refname="System.AssignedTo">
<VALIDUSER />
</FIELD>
</FIELDS>
</STATE>
<TRANSITION from="Active" to="Pending">
<REASONS>
<DEFAULTREASON value="Completed" />
</REASONS>
<FIELDS>
<FIELD refname="System.AssignedTo">
<COPY from="field" field="Project.Tfs.Lead" />
</FIELD>
<ACTIONS>
<ACTION value="Microsoft.VSTS.Actions.Checkin" />
</ACTIONS>
</TRANSITION>
The issue ended up being that the field Project.Tfs.Lead didn't have syncnamechanges="true". Here is what the field looked like after the change was made:
<FIELD name="Lead" refname="Project.Tfs.Lead" type="String" syncnamechanges="true" reportable="dimension">
<ALLOWEXISTINGVALUE />
<DEFAULT from="value" value="Seth Denburg" />
<REQUIRED />
<VALIDUSER group="Project\TechnicalLeads" />
</FIELD>
When making the change ensure that you use witadmin changefield like the following command because the field needs to be updated across work item type definitions. Importing an xml change won't work and will give you warning TF248017.
witadmin changefield /collection:https://project.com/tfs/projectCollection/ /n:Project.Tfs.Lead /syncnamechanges:true
Here's why this change was necessary from MSDN:
You must manually enable synchronization of any custom work item
fields that you have created in previous releases of Visual Studio
Team Foundation Server and that are used to assign person names that
reference Active Directory. You must enable synchronization for each
field for each team project collection that contains the custom
fields.
https://msdn.microsoft.com/en-us/library/dd286562(v=vs.100).aspx
Have created a test in myside, works well. The code of the custom work item type definition above seems missing a </FIELDS> of TRANSITION part.
Make sure the user Seth Denburg is in both group Project\TechnicalLeads and Project\Users.
You could also create a new team project in TFS2015 and use this custom work item type definition to see if the issue still exists. If not, the issue should related to the upgrade from TFS 2012 to 2015. Make sure you have Configure features after an upgrade.
What does isSummary=true mean in a type profile? Especially, what does it mean in the "root" element of a type:
<element>
<path value="CodeableConcept"/>
<short value="Concept - reference to a terminology or just text"/>
<min value="0"/>
<max value="*"/>
<type>
<code value="Element"/>
</type>
<isSummary value="true"/>
</element>
It's meaningless. There should be a constraint that isSummary can only be declared on child elements of resource profiles. It makes no sense anywhere else. Can you submit a change request?
Is is possible to slice an element by ordinal position (rank)? For instance, to profile the first given element in HumanName differently than the second (and subsequent) instances:
... snip ...
<element>
<path value="Patient.name.given" />
<slicing>
<discriminator value="???" />
<ordered value="true" />
</slicing>
</element>
<element>
<path value="Patient.name.given" />
<name value="First Name" />
<fixed?? value="0" />
</element>
I don't see any facility for this? This was the easiest example, but there are many situations where we'd like to differentiate between the first element ("primary") and others.
well, you can say that the slicing is ordered, and set constraints on the first element. This makes everything else ordered too. This is not the same as 'slicing by order' but it does make the first element special
Note that, unless the base resource assigns a meaning to order, enforcing order in a profile will impede interoperability. Only systems specifically configured for the profile will be able to conform to it.
I am trying to add a trivial AppleScript support to a Cocoa application. The application performs a check periodically and I just want to be able to tell it to perform it on demand.
I am trying to follow the SimpleScriptingVerbs Apple example.
I have subclassed NSScriptCommand as follows:
Header:
#import <Cocoa/Cocoa.h>
#interface rdrNotifierUpdateCommand : NSScriptCommand {
}
-(id)performDefaultImplementation;
#end
Implementation:
#import "rdrNotifierUpdateCommand.h"
#import "rdrNotifierAppDelegate.h"
#implementation rdrNotifierUpdateCommand
-(id)performDefaultImplementation {
NSLog(#"Works at last");
[((rdrNotifierAppDelegate *)[[NSApplication sharedApplication] delegate])
checkForNewItems]; // This just fires the timer
return nil;
}
#end
My .sdef file goes as follows (and the problem seems to be there, but I cannot find it):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE dictionary SYSTEM "file://localhost/System/Library/DTDs/sdef.dtd">
<dictionary title="Dictionary" xmlns:xi="http://www.w3.org/2003/XInclude">
<xi:include href="file:///System/Library/ScriptingDefinitions/CocoaStandard.sdef" xpointer="xpointer(/dictionary/suite)"/>
<suite name="rdrNotifier Suite" code="rdrN" description="rdrNotifier application specific scripting facilities.">
<command name="do update" code="rdrNUpdt" description="Check for new items">
<cocoa class="rdrNotifierUpdateCommand"/>
</command>
</suite>
</dictionary>
The Info.plist is set up appropriately.
But, when I try to run the following script in AppleScript editor:
tell application "rdrNotifier"
do update
end tell
I receive an error about variable "update" not being defined.
I can open the dictionary for my application from AppleScript Editor (i.e. it is successfully registered).
Edit: Found a solution
The problem was indeed in the sdef file: I was not specifying that the application can reply to the command. My final definition goes as follows (Obj-C code unchanged):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE dictionary SYSTEM "file://localhost/System/Library/DTDs/sdef.dtd">
<dictionary title="Dictionary" xmlns:xi="http://www.w3.org/2003/XInclude">
<!-- I have removed the standard suite as the application does not open, print... -->
<suite name="rdrNotifier Suite" code="rdrN" description="rdrNotifier application specific scripting facilities.">
<command name="do update" code="rdrNUpdt" description="Check for new items">
<cocoa class="rdrNotifierUpdateCommand"/>
</command>
<class name="application" code="Capp">
<cocoa class="NSApplication"/>
<responds-to name="do update">
<!-- Note you need to specify a method here,
although it is blank -->
<cocoa method=""/>
</responds-to>
</class>
</suite>
</dictionary>
Any improvements/tips/criticisms are still welcome.
Thanks for making the effort of adding applescript support to your app! Just a quick observation / criticism: When constructing terminology, by all means include spaces, but if that terminology takes the form of 'verb noun' (like 'do update') appleScripters will be irritated if the noun 'update' is not a properly modelled object, and if 'do' is not a proper command.
I would argue that 'do' is a poor choice for a command name, because it is very vague. What's wrong with just using 'update' as the command? (i.e. treat it as a verb).
This issue is treated in some detail by Apple's own technote 2106 (currently here), which you definitely should read and digest if you hope to please your AppleScripting user community.
Apple themselves are not beyond stupid terminology choices such as updatePodcast and updateAllPodcasts (in iTunes). These are stupid choices because (according to tn2106) they contain no spaces, and because the better choice would be to have a proper podcast class and then have an update command which could be used on an individual podcast, all podcasts, or a particular chosen set of podcasts.