took me a while to find whats wrong here.
Every time I do [perform task] without giving priority to 10 the child task
works as expected but throws an error at [return] action (as seen in
runlog) and doesn't return the value. If priority is 10 though everything
works.
Hope it is clear, tell me if you need the export description.

Could someone please explain whats going on here? Or if this is a bug?

Thank you.

task works as expected but throws an error at [return] action (as seen in
runlog) and doesn't return the value. If priority is 10 though everything
works.

I can confirm  this. Just changed one of my perform tasks with a return to
priority 10 and got a error....

Rich...

thanks for confirming Rich :)
(I think you meaned you changed it from 10 to something else)

Always using priority 10 as workaround is not the best option as it is
blocking until it is ready even if it is not that important in the workflow.

Am Samstag, 10. November 2012 15:21:39 UTC+1 schrieb Rich:

blocking until it is ready even if it is not that important in the workflow.

Hmmm, don't think we are on the same page..

I have several perform tasks with several different priorities and with
return values none of them currently have a priority 10.

I changed one of then to a priority 10 and then I got the error..

Is that your findings??

Rich....

oh thats weird I have the opposite.

*Testreturn* (190)
A1: Perform Task [ Name:*Returner* Stop:Off Priority:*10* Parameter 1
(%par1):return this Parameter 2 (%par2): Return Value
Variable:%returnvalue1 ]
A2: Perform Task [ Name:*Returner* Stop:Off Priority:*7* Parameter 1
(%par1):return this too Parameter 2 (%par2): Return Value
Variable:%returnvalue2 ]
A3: Flash [ Text:%returnvalue1
%returnvalue2 Long:Off ]

*Returner* (193)
A1: Return [ Value:%par1 Stop:On ]

the flash ouput is :
*return this
%returnvalue2*

If I change priority of second perform task to 10
output is as expected:
*return this*
*return this too*

Am Samstag, 10. November 2012 15:45:30 UTC+1 schrieb Rich:

On Nov 10, 2012 9:58 AM, "spiral" <marko.pah...@googlemail.com> wrote:

(%par1):return this Parameter 2 (%par2): Return Value
Variable:%returnvalue1 ]
(%par1):return this too Parameter 2 (%par2): Return Value
Variable:%returnvalue2 ]

OK.. very strange, I just did a similar test as you listed above and got
the SAME results...  this will take a little time to figure out the
differences in the tasks and I can not do it right now (family time is
calling (speaking loudly(yelling)))  but will definitely look into later.

Rich....

OK... took some looking but here is what I found ..

The reason the lower priorities were working in my other tasks is because
it was in a chain of 'perform tasks' so in other words if you take your
above test and call it from another task you will still see the error in
the run log but you will get the return value..

Hope that makes sense .....

Let me know if it works on your end...    Rich..

I just found this in the user guide and assume this new change might be the
culprit but I am a little confused on how it SHOULD be working

If I am reading it correctly it would seem that if I want to call a task t2
from task t1 that has been started from a profile and would like t2 to
finish before t1 continues then 1 would have to  deselecting Enforce Task
Order for that profile.  Correct?

 Same-Profile Tasks

Tasks from the same profile (including any sub-tasks started via Perform
Task) by default always execute in the order in which they are launched.
Other tasks from the same profile remain completely inactive until any
previous profile is complete. The main purpose of this rule is to correctly
handle rapid changes in a profile's activation state.

This behaviour can be disabled by deselecting Enforce Task Order in the
Profile Properties dialog.

Rich.....

Hey Rich thanks for trying to debug this further.

"in other words if you take your above test and call it from another task
you will still see the error in the run log but you will get the return
value.."
that is something that I observed too, but couldn't nail down. I sometimes
got the value anyway even when the error occurred in the runlog but I did
something else I can't remember now :/ but I can confirm that calling from
another task works.

and regarding "Same-Profile Tasks" you quoted I don't understand it too but
what I think is that we haven't profiles involved at all, in our test case.
And that "other tasks from the same profile remain completely inactive"
doesn't quite fit in with the error we get AND that the task executes fine
until it should return a value.

I guess we are stuck now and maybe only pent could tell whats really going
on here or rather what should be going on.

but what I think is that we haven't profiles involved at all, in our test
case. And that "other tasks from the same profile remain completely
inactive" doesn't quite fit in with the error we get AND that the task
executes fine until it should return a value.

Ah, yes.. definitely strayed off topic... I believe we are definitely
discussing a bug here  that pent will be able to confirm and hopefully it
will be a simple fix..

I will start another thread with the above question to try to fully
understand how the priorities should be working with the perform task. It
will make the info easier to find for others in a search as well..

Rich..

Pent, I just wanted to bump this up as I believe spiral has definitely come
across a bug as discussed above...

Thanks,    Rich..
On Nov 11, 2012 11:47 AM, "Richard Davis" <ricpd...@gmail.com> wrote:

 I am sorry to bump this up again, but this error is really a big one for
me as it makes using perform task almost unusable.
Just a short message from you pent that you noticed this issue would be
appreciated. Thanks.

Am Dienstag, 13. November 2012 10:09:32 UTC+1 schrieb Rich:

Maybe 3rd time will be the charm......   :)

Bum,bum,bum,bumbum---- bump /bump

Hmmm, this was not bumping up with regular email. Trying from the
forum on this one..

You're running the task with the test button, right ? Then the parent
task has a priority of 10 and and so the task launched with A2 doesn't
run until the parent has finished. If A2 uses priority 10, then it
finishes before the parent task because Tasker gives preference to sub-
tasks if two tasks have the same priority.

Pent

p.s. thanks for the external bump Richard :-)

Pent

Ummm,  yup...   :)

Then the parent

Damm, I actually knew that..

and so the task launched with A2 doesn't

As usual Pent quite correct.....    :)

OK...  re-tested and everything works as it should however it does show the
errors in the run log as spiral reported ( it will be interesting to see if
he was using the same faulty  test procedure). I have posted the run log of
my test below.

I'm assuming that since  everything is working correctly these errors can
be ignored?

Thanks for the reply Pent, Sorry about the false bug report.   :(

Rich....

Oops forgot the log....

20121115 16.53.01 P Inactive ID337    Return Test
20121115 16.53.12 P Active   ID337    Return Test
20121115 16.53.12 T Running  ID338    Task Send
20121115 16.53.13 A OK       ID338.1  Task Send.Perform Task
20121115 16.53.13 T Running  ID339:2  Returner
20121115 16.53.13 A OK       ID339:2.1 Returner.Variable Set
20121115 16.53.13 A Err      ID339:2.2 Returner.Return
20121115 16.53.13 T ExitErr  ID339:2  Returner
20121115 16.53.13 A OK       ID338.2  Task Send.Flash
20121115 16.53.13 T ExitOK   ID338    Task Send

Actually, the Run Log doesn't seem to fit with my nice story since the
Send task is still running when the Return action takes place so I
don't see why it should error.

Will have to test it myself I think.

Pent

Thanks for testing and bumping Rich. And thanks Pent for responding. I just
didn't reply yet because I have no time logging into groups from my pc to
respond as spiral.

But back to topic, your explanation seemed logical but even with this in
mind I couldn't, other than Richard, understand why it acts the way it
does. Take for example the conclusion from before that if you put another
parent before the task that calls the responding task it works. According
to your explanation it shouldn't work neither, because as you said child
tasks have higher priority if called with the same priority as the
executing task. So it does essentially not matter if you put an extra task
before or not. But it acts clearly differentially.
And another thing according to your explanation the calling task should
exit before the child can respond and hence the error but it does not if
you look into run log. Everything works as expected until return action.
But I was still not able to nail the issue down to something concrete. For
me it seems as if priorities aren't respected everytime the run log always
seems a little different than what I would expect even after very carefully
tuning priorities.

Thanks for testing pent.
Spiral
Am 16.11.2012 08:38 schrieb "Pent" <supp...@apps.dinglisch.net>:

mind I couldn't, other than Richard, understand why it acts the way it
does. Take for example the conclusion from before that if you put another
parent before the task that calls the responding task it works. According
to your explanation it shouldn't work neither, because as you said child
tasks have higher priority if called with the same priority as the
executing task. So it does essentially not matter if you put an extra task
before or not.

'I think' pents logic does work here (assuming we are still using the test
button), because now the original task (the test button) has priority 10 so
that will finish first but now you have made the first called task a lower
priority by defining it in the perform task action. So now things work as
they should with respect priorities.  In my test I took the test button out
of the equation and fired the tasks with a profile and i believe everything
worked as it should with exception of the errors which did not seem to
affect the expected behavior.

Does that sound correct??

Rich..

There's a bug with the Return action, if you have Stop checked, it
stops with an error instead of with an OK. Have fixed for next update,
sorry for all the problems caused.

Pent

Thanks Pent. Does this error affect the resuming of the parent? Or is it
just a cosmetic change.

Rich you are right I think.

Waiting for the next version (or beta first?)

Thanks again.
Am 16.11.2012 13:09 schrieb "Pent" <supp...@apps.dinglisch.net>:

It's just cosmetic.

Pent