Thanks Ian.

If we have some html displayed in a web object and that html contains a link/url to a pdf file, is it possible to give the user the option to open the pdf in an external app like you show above rather than just have it open in the web object?

If it would help, we may be able to modify the url to the pdf file within the html to add some kind of prefix like 'itms-books:', etc.

In reality there are sync tags around the code. I just left them out of the sample.

Also the looping action 'build-panels' is not doing the creation directly but rather is alternately calling different actions which are doing the creation.

I would really like to clear the flag when creation is complete, which is pretty hard to do when calling a cascading series of actions.

The (simplified) use case is like this:


<action name="handle-user-action">
<if lhs="[var:busy-flag]" operator="eq" rhs="0">
<assign property="var:busy-flag" value="1">
<delete target="existing-panels">
<assign property="var:panel-count" value="0">
<play action="build-panels">
<assign property="var:busy-flag" value="0">
</if>
</action>

<action name="build-panels">
<if lhs="[var:panel-count]" operator="lt" rhs="[datasource:somedata.dataSourceResultCount]">
<sync>
<create class="panels" target="someparent" />
<play action="build-panels" />
</sync>
</if>
</action>


The busy flag gets cleared BEFORE the panels have finished being created. If the user triggers the action again before it completes, the app crashes because it is deleting objects that are still being created.

Perhaps 'valignment' support could be added to the text object soon. It would complement the 'alignment' attribute and make vertical positioning of text simpler.

Wow that's an awful lot of work to go to just to vertically align text in a fixed sized box...

This is not a solution for this case:

If we replace a text object's text on the fly the height is not recalculated when the 'fit' attribute is used. This means that text objects that have dynamic text must have a fixed height, which in turn means that you can only ever have the text vertically centered.

I understand what you are saying and the usage. My point is about the nomenclature. To me the purpose of these programmer defined attributes is similar to having programmer defined attributes in an <object> where I can also define arbitrary attributes and use them to pass some value specific to the object on to somewhere else. However, when processing a class attached to that object the parameters from the object are referenced using the notation [param:someobjectattribute], NOT directly as someobjectattribute.

The problem here is that a programmer defined attribute on a <panel> type object is being referenced in an action triggered by that panel object NO special notation is used to indicate that the programmer is attempting to use that attribute (for example by wrapping it with [param:someobjectattribute]), so it is ambiguous and there is an opportunity for the wire to break.
For example:

<panel name="somename" ... _value="abc" onclick="dosomething" />
...
<alert name="dosomething">
<alert message="value of curr_value is 5">
</alert>

did I mean to print exactly what is in the above quotation marks or did I really want "_value" to be substituted with the programmer defined attribute _value from the <panel> object that I clicked on to get the action.
Without wrapping the attribute name with some special notation, as is used with the other variable types, the program is unable to determine my intentions leading to exactly the kind of difficult to track down problem I experienced.

I think this would not be a problem if the parameters passed in had to be referenced using [param:_myvar], this would be following the same pattern as how other variables are handled [datasource:xyz.abc], [var:somevar], etc, and from a programming perspective would make more sense. To me the fact they are referenced differently is a source of some confusion.

Right now they are a kind of magic variable which can cause problems like the one that I identified above when they get inadvertently substituted.

it happens on panels too:


<wire>
<main>
<text name="panel1" height="100%" width="100%" onclick="assign" _myvar="abc" text="tap the screen" background="#ffffff" />
</main>

<actions>

<action name="assign">
<sync>
<assign property="var:curr_myvar" value="_myvar" />
<assign property="var:somevar" value="_myvar" />
<play action="display" />
</sync>
</action>

<action name="display">
<alert message="'var:curr_myvar'=[var:curr_myvar] 'var:somevar'=[var:somevar]" />
</action>

</actions>
</wire>


It is a little frustrating sometimes :-)

Of course its not just the yes/no ones, for example, the background attribute is optional and I believe the default background color is transparent.