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?
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 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"/>
...
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 read about the new OneNote Cloud API, but I am afraid that it's not what I am looking for.
I search a possibility to manipulate the pen in oneNote. So for example to be able to change the color or the Pen thickness from another program. Also it would be nice to click the "action back" and "Redo" buttons.
Do you knows if there is any possibility to do so? I am an experienced Java and C / C++ programer, but never did anything windows-specific, so this could be the reason why I do not know where I have to look.
Best regards! Any help is appreciated!
The REST API won't help here, there is some mention of support in the wishlist, but it doesn't appear to have a lot of traction.
I'm not 100% sure of your use case, you want to interact with the OneNote UI and change the user's pen setting so the next time they draw something then pen is what you've specified from your app?
If that's the case then the REST api won't help anyway as it's for manipulating content, you want to directly interact with OneNote and change the user's experience?
You could look at the COM API and interact via the Windows desktop version though I can tell you now that the options for UI interaction are pretty minimal (e.g. show a quick filing dialogue, create new note window, dock note window)
You can interact with a user's basic ink content using GetPageContent and from the below example I ripped out of one of my pages it looks pretty simple to change the thickness, but maybe have a play with GetBinaryPageContent and you could alter colour too?
<one:OE author="Darren Beale" authorInitials="DB" lastModifiedBy="Darren Beale" lastModifiedByInitials="DB" creationTime="2014-05-11T07:42:59.000Z" lastModifiedTime="2014-05-11T07:42:59.000Z" objectID="{F8158129-96AB-4D65-80B0-3AF7DE849E62}{15}{B0}" alignment="left" quickStyleIndex="0">
<one:T><![CDATA[]]></one:T>
</one:OE>
</one:Title>
<one:InkDrawing lastModifiedTime="2014-05-11T07:43:17.000Z" objectID="{F8158129-96AB-4D65-80B0-3AF7DE849E62}{53}{B0}">
<one:Position x="241.4976348876953" y="73.48818969726562" z="4" />
<one:Size width="45.01417922973633" height="157.5212554931641" />
<one:CallbackID callbackID="{F8158129-96AB-4D65-80B0-3AF7DE849E62}{53}{B0}" />
</one:InkDrawing>
<one:InkDrawing lastModifiedTime="2014-05-11T07:43:23.000Z" objectID="{F8158129-96AB-4D65-80B0-3AF7DE849E62}{63}{B0}">
<one:Position x="209.9763793945312" y="108.7228317260742" z="5" />
<one:Size width="42.77478790283203" height="116.3055114746094" />
<one:CallbackID callbackID="{F8158129-96AB-4D65-80B0-3AF7DE849E62}{63}{B0}" />
</one:InkDrawing>
<one:InkDrawing lastModifiedTime="2014-05-11T07:43:14.000Z" objectID="{F8158129-96AB-4D65-80B0-3AF7DE849E62}{36}{B0}">
<one:Position x="113.9952697753906" y="124.4834671020508" z="0" />
<one:Size width="3.770078659057617" height="145.5307006835937" />
<one:CallbackID callbackID="{F8158129-96AB-4D65-80B0-3AF7DE849E62}{36}{B0}" />
</one:InkDrawing>
<one:InkDrawing lastModifiedTime="2014-05-11T07:43:15.000Z" objectID="{F8158129-96AB-4D65-80B0-3AF7DE849E62}{43}{B0}">
<one:Position x="149.9952697753906" y="163.4881896972656" z="2" />
<one:Size width="1.530704498291016" height="102.7842559814453" />
<one:CallbackID callbackID="{F8158129-96AB-4D65-80B0-3AF7DE849E62}{43}{B0}" />
</one:InkDrawing>
<one:InkDrawing lastModifiedTime="2014-05-11T07:43:16.000Z" objectID="{F8158129-96AB-4D65-80B0-3AF7DE849E62}{48}{B0}">
<one:Position x="176.2440948486328" y="171.0" z="3" />
<one:Size width="51.76062393188476" height="121.5212478637695" />
<one:CallbackID callbackID="{F8158129-96AB-4D65-80B0-3AF7DE849E62}{48}{B0}" />
</one:InkDrawing>
<one:InkDrawing lastModifiedTime="2014-05-11T07:43:26.000Z" objectID="{F8158129-96AB-4D65-80B0-3AF7DE849E62}{68}{B0}">
<one:Position x="292.492919921875" y="180.7228240966797" z="6" />
<one:Size width="76.50707244873047" height="40.53543090820312" />
<one:CallbackID callbackID="{F8158129-96AB-4D65-80B0-3AF7DE849E62}{68}{B0}" />
</one:InkDrawing>
<one:InkDrawing lastModifiedTime="2014-05-11T07:43:14.000Z" objectID="{F8158129-96AB-4D65-80B0-3AF7DE849E62}{38}{B0}">
<one:Position x="98.97164916992187" y="197.2488098144531" z="1" />
<one:Size width="52.55432891845703" height="51.02363204956054" />
<one:CallbackID callbackID="{F8158129-96AB-4D65-80B0-3AF7DE849E62}{38}{B0}" />
</one:InkDrawing>
I made a custom component and I'm trying to make the menu item link add &id=x, however I can't seem to find any documentation on how to make this work. The field is read only, but even then I would still want it to be automated (similar to how adding an article works). It will be taking a value from a parameter field. Any help is appreciated!
Found the answer in this thread towards the bottom.
http://forum.joomla.org/viewtopic.php?p=2250321
It's also important to note that the params to be added to the link need to be out of the params, like so.
<state>
<name>Standard Page Layout</name>
<url>
<param name="id" type="text" default="0" label="Page ID" description="The ID of the page to view." />
</url>
<params>
</params>
</state>
The following is incorrect.
<state>
<name>Standard Page Layout</name>
<params>
<url>
<param name="id" type="text" default="0" label="Page ID" description="The ID of the page to view." />
</url>
</params>
</state>