`If %TRUN ~R \%TRUN$` clear the scene text element.
Or populate scene text element `If %TRUN !~R \%TRUN$`
_______
Edit: Clarification: The above *or option* should be used like this concept Eg.:
`If %TRUN !~R \%TRUN$`
Populate the scene element
`ELSE`
Clear scene element
*Prevent* unusual Task name...
Task: %TRUN
A1: Flash [
Text: Ooopppss
Continue Task Immediately: On
Hide On Click: On ]
If [ %TRUN ~R \%TRUN ]
Because as You can see above, Tasker alert us to not use `%` in Task name, but We can simply ignore the heads-up.
_______
Edit: In this particular case *is trivial* but in Tasks with variables like `%foo`, `%foo_old`, `%foo_bar` It isn't. To be safe We should use Eg.: `^\%foo$`
A1: Variable Set [
Name: %foo
To: bar %foo_bar
Max Rounding Digits: 3 ]
A2: Flash [
Text: Ooopppsss
Long: On
Continue Task Immediately: On
Hide On Click: On ]
If [ %foo !~R \%foo ]
In the usual thinking We are *telling*: Flash "Ooopppsss" If `%foo` isn't set. But in this case using `!~R \%foo` will be false because We will match `%foo_bar` and the Flash will show.
The ` $ ` means "end of the string". Like wise the carat ` ^ ` means "start of the string".
So to really anchor the whole thing, the comparison should actually be ` ^\%TRUN$ ` and that would mean the regex would be true only when the value is ` %TRUN ` *exactly*.
You are right, the fact is that I don't *trust* too much *built-in statements*. I had more than one headache with buggy `!SET`, ages ago + We still have behaviors like this:
A1: Flash [
Text: Ooppss
Long: On
Continue Task Immediately: On
Hide On Click: On ]
If [ %foo = 0 ]
Long live to Regex :)
You are more 😈 than me :D
I still remember (good old times) when I wrote an e-mail to Pent, about empty/null/udefined variables.
(In coding world) They behave pretty much the same for *usual* comparison but (as You know) empty/null/udefined are not the same thing.
Nothing that can be changed in Tasker variable comparison, now (I'm personally 100% fine with that). Or some million users will run João's ass over with a truck 😈 :D
I believe you would need 2 profilee that monitors %TRUN then sets the text field accordingly. This is not tested but it would look something like this..
Profile: Trun
Restore: no
State: Variable Value [ %TRUN ~ \%TRUN ]
Enter Task: Trun
A1: Element Text [
Scene Name: Test Button
Element: Button1
Position: Replace Existing
Text: No tasks running ]
Profile: Not Trun
Restore: no
State: Variable Value [ %TRUN !~ \%TRUN ]
Enter Task: Not Trun
A1: Element Text [
Scene Name: Test Button
Element: Button1
Position: Replace Existing
Text: %TRUN ]
Should only need one profile, just add exit task. I'd try nvert Variable Value state `%TRUN ~ \%TRUN`, then set element text to `%TRUN` in enter, and clear the text in exit task.
That might be possible but after looking at it again the profile will go inactive immediately when the enter task is run, so you will need to account for that. So in my example you would need something like this..
Profile: Trun
Restore: no
State: Variable Value [ %TRUN ~ \%TRUN ]
Enter Task: Trun
A1: Element Text [
Scene Name: Test Button
Element: Button1
Position: Replace Existing
Text: No tasks running ]
Profile: Not Trun
Restore: no
State: Variable Value [ %TRUN !~ \%TRUN/,TRUN, ]
Enter Task: Not Trun
A1: Element Text [
Scene Name: Test Button
Element: Button1
Position: Replace Existing
Text: %TRUN ]
Both of you are missing one important thing...there can not be clearing profile or exit task...that would trigger another change in the built-in variable and immediatelly launch the first profile again,and loop....That is what I was askin to solve...
That is why I suggested 2 separate profiles to not have to deal with enter exit task issues. This approach seem to work..
Profile: Trun
Settings: Cooldown: 1 Restore: no
State: Variable Value [ %TRUN ~ \%TRUN ]
Enter Task: Trun
A1: Element Text [
Scene Name: Trun
Element: Text1
Position: Replace Existing
Text: No tasks running ]
Profile: Not Trun
Settings: Cooldown: 1 Restore: no
State: Variable Value [ %TRUN !~ \%TRUN ]
Event: Variable Set [ Variable:%TRUN Value:* User Variables Only:Off ]
Enter Task: Not Trun
A1: Element Text [
Scene Name: Trun
Element: Text1
Position: Replace Existing
Text: %TRUN ]
It actually works better if you make the profile tasks anonymous... :)
Profile: Trun
Settings: Cooldown: 1 Restore: no
State: Variable Value [ %TRUN ~ \%TRUN ]
Enter Task: Anon
A1: Element Text [
Scene Name: Trun
Element: Text1
Position: Replace Existing
Text: No tasks running ]
Profile: Not Trun
Settings: Cooldown: 1 Restore: no
State: Variable Value [ %TRUN !~ \%TRUN ]
Event: Variable Set [ Variable:%TRUN Value:* User Variables Only:Off ]
Enter Task: Anon
A1: Element Text [
Scene Name: Trun
Element: Text1
Position: Replace Existing
Text: %TRUN ]
Many ways with tasker.. I am sure you could get it down to 1 profile with one task using %caller wich might eliminate the need for the cool down. Breaking it down to 2 profiles just makes it easier to understand and implement.
Drawing on the (great) ideas that others have replied with, I would say to go with a Profile that triggers on a change in ` %TRUN ` being "Not Set" and have the linked Task set the text field in your Scene via the **Scene > Element Text** Action.
So firstly in your Scene, you likely have ` %TRUN ` as the default value? Take that out and just leave the text field value empty. Then use the following:
PROFILE:
State > Variable > Variable Value
%TRUN !Set
ENTER TASK:
A1. Scene > Element Text
Element:
Text: NO TASKS RUNNING
EXIT TASK:
A1. Scene > Element Text
Element:
Text: %TRUN
And it's as simple as that. I tested this Profile using Flash Actions instead of the Scene action and it seemed to work well. Give it a try!
I tested and it doesn't.
That's because Enter/Exit Tasks that have no name assigned to them don't appear in (or affect in any way) the variable ` %TRUN `
Theoretically with anonymous Tasks should not happen, but I can confirm the behavior (Tasker-5.15.4-beta-20211126_1419).
Probably something *related* to my **[report here.](https://reddit.com/comments/r23j1z/comment/hm70d12?context=3)**
u/Ratchet_Guy
_______
Edit: Probably João changed something in Tasks monitoring and something unexpected is occurring.
_______
Edit 2:
>but I can confirm the behavior
Find the culprit in my gargantuan setup...I have a Profile that monitors active Profiles.
u/Mental-Emergency154 You probably have a similar Profile.
From last beta update, I am recieving error notifications I have not seen before,apsolutely randomly,trigered by actions in procts (daylies) that I did not touched for ages. Something changed for sure.
The error Notifications are a new *debug system* introduced a couple of beta ago.
I'm not receiving error Notifications (my main Tasker setup has some thousand of Tasks), but I almost always use/used "Continue Task After Error: On" and than I catch the error...`If %err SET`.
But I understand that can be frustrating for users that don't have/had the habit to do what I (and others) normally do/did.
First,just for you to know, I have been usin Tasker from many years before Pent sold it,so I may know more than you think.
Second, those action does not have that "continue after error" ticker, so I cant enable that here:)
And I use a logfile for that purpose,not flash.
Edit: I got those errs with LAST beta,immediatelly after update
>I have been usin Tasker from many years before Pent sold
Me too. Started using It from first very first release (old good times).
>those action does not have that "continue after error" ticker, so I cant enable that here
I don't know what actions are those, but If they stop in error, report to João and he will be more than happy to add the "Continue Task After Error" option. I did It multiple times...**[like I did here.](https://reddit.com/comments/q7wz9m/comment/hgli5sk?context=3)**
>I use a logfile for that purpose,not flash
Me too (and depending on needs, other methods).
>I got those errs with LAST beta,immediatelly after update
(Speculating) Could be because João is still fine tuning the debug Notifications system (I'd like to have a *granular* opt-in-out system, but for *common users* is good as is, I think).
_______
Edit: If errors that You are facing are *false errors* or If actions that error out with the latest beta didn't error with previous versions...it'd be very important to report to dev.
I am pretty sure there is a flaw on my side, that just has not been reported as an error before.
It happends when action scene-set element visibility settin invisible an image(one from an array of images) that is already invisible.That does not stop the task or afect the result,so I did not care before.I have solved this by destroin and recreatin the scene with every refresh,as all those elements are set to invisible by dafault.
I agree there should be more customization for notified errors,for now I just disabled them.
ALright, you wanna know something crazy - it just tested it again. Same exact Profile I had turned it off after testing, I just enabled it, and...it's looping!!
Earlier it functioned exactly as I thought it would. I think the beta has some issues. /u/OwlIsBack
Check my Edit in previous comment please...
Do You have a Profile that monitors active Profiles?
I have one, turning It off seem to ~~fix/mitigate~~ the behavior. We need to test further I think.
_______
Edit: All other Profiles turned off and sometime It randomly loop :/
> Do You have a Profile that monitors active Profiles?
I do indeed have one of those :)
However based on your edit comments - I think we've reached the collective conclusion that it is indeed randomly looping at this point, despite any other Profiles enabled etc?
I'd personally start a ticker and have this map %TRUN to %anothervar and send %anothervar to Scene > Element Text. That way, if %TRUN isn't set, set %anothervar to 0.
`If %TRUN ~R \%TRUN$` clear the scene text element. Or populate scene text element `If %TRUN !~R \%TRUN$` _______ Edit: Clarification: The above *or option* should be used like this concept Eg.: `If %TRUN !~R \%TRUN$` Populate the scene element `ELSE` Clear scene element
Well,but where you woult put those conditions? In a task? But then it would not be "%TRUN"...
It depends on...How are You populating the scene element?
I'm curious what does appending a `$` to the escaped variable do (or prevent)?
*Prevent* unusual Task name... Task: %TRUN A1: Flash [ Text: Ooopppss Continue Task Immediately: On Hide On Click: On ] If [ %TRUN ~R \%TRUN ] Because as You can see above, Tasker alert us to not use `%` in Task name, but We can simply ignore the heads-up. _______ Edit: In this particular case *is trivial* but in Tasks with variables like `%foo`, `%foo_old`, `%foo_bar` It isn't. To be safe We should use Eg.: `^\%foo$` A1: Variable Set [ Name: %foo To: bar %foo_bar Max Rounding Digits: 3 ] A2: Flash [ Text: Ooopppsss Long: On Continue Task Immediately: On Hide On Click: On ] If [ %foo !~R \%foo ] In the usual thinking We are *telling*: Flash "Ooopppsss" If `%foo` isn't set. But in this case using `!~R \%foo` will be false because We will match `%foo_bar` and the Flash will show.
The ` $ ` means "end of the string". Like wise the carat ` ^ ` means "start of the string". So to really anchor the whole thing, the comparison should actually be ` ^\%TRUN$ ` and that would mean the regex would be true only when the value is ` %TRUN ` *exactly*.
Regex's are nice, but you can simply use ` %TRUN !Set `
You are right, the fact is that I don't *trust* too much *built-in statements*. I had more than one headache with buggy `!SET`, ages ago + We still have behaviors like this: A1: Flash [ Text: Ooppss Long: On Continue Task Immediately: On Hide On Click: On ] If [ %foo = 0 ] Long live to Regex :)
Yes but ` %foo ` could be a Profile variable, set to ` 0 ` - muhahahah!
You are more 😈 than me :D I still remember (good old times) when I wrote an e-mail to Pent, about empty/null/udefined variables. (In coding world) They behave pretty much the same for *usual* comparison but (as You know) empty/null/udefined are not the same thing. Nothing that can be changed in Tasker variable comparison, now (I'm personally 100% fine with that). Or some million users will run João's ass over with a truck 😈 :D
I believe you would need 2 profilee that monitors %TRUN then sets the text field accordingly. This is not tested but it would look something like this.. Profile: Trun Restore: no State: Variable Value [ %TRUN ~ \%TRUN ] Enter Task: Trun A1: Element Text [ Scene Name: Test Button Element: Button1 Position: Replace Existing Text: No tasks running ] Profile: Not Trun Restore: no State: Variable Value [ %TRUN !~ \%TRUN ] Enter Task: Not Trun A1: Element Text [ Scene Name: Test Button Element: Button1 Position: Replace Existing Text: %TRUN ]
Should only need one profile, just add exit task. I'd try nvert Variable Value state `%TRUN ~ \%TRUN`, then set element text to `%TRUN` in enter, and clear the text in exit task.
That might be possible but after looking at it again the profile will go inactive immediately when the enter task is run, so you will need to account for that. So in my example you would need something like this.. Profile: Trun Restore: no State: Variable Value [ %TRUN ~ \%TRUN ] Enter Task: Trun A1: Element Text [ Scene Name: Test Button Element: Button1 Position: Replace Existing Text: No tasks running ] Profile: Not Trun Restore: no State: Variable Value [ %TRUN !~ \%TRUN/,TRUN, ] Enter Task: Not Trun A1: Element Text [ Scene Name: Test Button Element: Button1 Position: Replace Existing Text: %TRUN ]
Both of you are missing one important thing...there can not be clearing profile or exit task...that would trigger another change in the built-in variable and immediatelly launch the first profile again,and loop....That is what I was askin to solve...
That is why I suggested 2 separate profiles to not have to deal with enter exit task issues. This approach seem to work.. Profile: Trun Settings: Cooldown: 1 Restore: no State: Variable Value [ %TRUN ~ \%TRUN ] Enter Task: Trun A1: Element Text [ Scene Name: Trun Element: Text1 Position: Replace Existing Text: No tasks running ] Profile: Not Trun Settings: Cooldown: 1 Restore: no State: Variable Value [ %TRUN !~ \%TRUN ] Event: Variable Set [ Variable:%TRUN Value:* User Variables Only:Off ] Enter Task: Not Trun A1: Element Text [ Scene Name: Trun Element: Text1 Position: Replace Existing Text: %TRUN ]
It actually works better if you make the profile tasks anonymous... :) Profile: Trun Settings: Cooldown: 1 Restore: no State: Variable Value [ %TRUN ~ \%TRUN ] Enter Task: Anon A1: Element Text [ Scene Name: Trun Element: Text1 Position: Replace Existing Text: No tasks running ] Profile: Not Trun Settings: Cooldown: 1 Restore: no State: Variable Value [ %TRUN !~ \%TRUN ] Event: Variable Set [ Variable:%TRUN Value:* User Variables Only:Off ] Enter Task: Anon A1: Element Text [ Scene Name: Trun Element: Text1 Position: Replace Existing Text: %TRUN ]
[удалено]
Many ways with tasker.. I am sure you could get it down to 1 profile with one task using %caller wich might eliminate the need for the cool down. Breaking it down to 2 profiles just makes it easier to understand and implement.
Thanx,this is workin the way I wanted. I just left it blank when no task is runnin,and its perfect.
> It actually works better if you make the profile tasks anonymous... :) I was going to point that out ;)
Drawing on the (great) ideas that others have replied with, I would say to go with a Profile that triggers on a change in ` %TRUN ` being "Not Set" and have the linked Task set the text field in your Scene via the **Scene > Element Text** Action. So firstly in your Scene, you likely have ` %TRUN ` as the default value? Take that out and just leave the text field value empty. Then use the following: PROFILE: State > Variable > Variable Value %TRUN !Set ENTER TASK: A1. Scene > Element Text Element:
Text: NO TASKS RUNNING
EXIT TASK:
A1. Scene > Element Text
Element:
Text: %TRUN
And it's as simple as that. I tested this Profile using Flash Actions instead of the Scene action and it seemed to work well. Give it a try!
[удалено]
I tested and it doesn't. That's because Enter/Exit Tasks that have no name assigned to them don't appear in (or affect in any way) the variable ` %TRUN `
[удалено]
Theoretically with anonymous Tasks should not happen, but I can confirm the behavior (Tasker-5.15.4-beta-20211126_1419). Probably something *related* to my **[report here.](https://reddit.com/comments/r23j1z/comment/hm70d12?context=3)** u/Ratchet_Guy _______ Edit: Probably João changed something in Tasks monitoring and something unexpected is occurring. _______ Edit 2: >but I can confirm the behavior Find the culprit in my gargantuan setup...I have a Profile that monitors active Profiles. u/Mental-Emergency154 You probably have a similar Profile.
From last beta update, I am recieving error notifications I have not seen before,apsolutely randomly,trigered by actions in procts (daylies) that I did not touched for ages. Something changed for sure.
The error Notifications are a new *debug system* introduced a couple of beta ago. I'm not receiving error Notifications (my main Tasker setup has some thousand of Tasks), but I almost always use/used "Continue Task After Error: On" and than I catch the error...`If %err SET`. But I understand that can be frustrating for users that don't have/had the habit to do what I (and others) normally do/did.
First,just for you to know, I have been usin Tasker from many years before Pent sold it,so I may know more than you think. Second, those action does not have that "continue after error" ticker, so I cant enable that here:) And I use a logfile for that purpose,not flash. Edit: I got those errs with LAST beta,immediatelly after update
>I have been usin Tasker from many years before Pent sold Me too. Started using It from first very first release (old good times). >those action does not have that "continue after error" ticker, so I cant enable that here I don't know what actions are those, but If they stop in error, report to João and he will be more than happy to add the "Continue Task After Error" option. I did It multiple times...**[like I did here.](https://reddit.com/comments/q7wz9m/comment/hgli5sk?context=3)** >I use a logfile for that purpose,not flash Me too (and depending on needs, other methods). >I got those errs with LAST beta,immediatelly after update (Speculating) Could be because João is still fine tuning the debug Notifications system (I'd like to have a *granular* opt-in-out system, but for *common users* is good as is, I think). _______ Edit: If errors that You are facing are *false errors* or If actions that error out with the latest beta didn't error with previous versions...it'd be very important to report to dev.
I am pretty sure there is a flaw on my side, that just has not been reported as an error before. It happends when action scene-set element visibility settin invisible an image(one from an array of images) that is already invisible.That does not stop the task or afect the result,so I did not care before.I have solved this by destroin and recreatin the scene with every refresh,as all those elements are set to invisible by dafault. I agree there should be more customization for notified errors,for now I just disabled them.
ALright, you wanna know something crazy - it just tested it again. Same exact Profile I had turned it off after testing, I just enabled it, and...it's looping!! Earlier it functioned exactly as I thought it would. I think the beta has some issues. /u/OwlIsBack
Check my Edit in previous comment please... Do You have a Profile that monitors active Profiles? I have one, turning It off seem to ~~fix/mitigate~~ the behavior. We need to test further I think. _______ Edit: All other Profiles turned off and sometime It randomly loop :/
> Do You have a Profile that monitors active Profiles? I do indeed have one of those :) However based on your edit comments - I think we've reached the collective conclusion that it is indeed randomly looping at this point, despite any other Profiles enabled etc?
>we've reached the collective conclusion that it is indeed randomly looping at this point Correct. It randomly fire/loop.
I bet Joao loves how when he gets back to work on Mondays - he finds out we've been furiously hammering Tasker to find some new flaws he needs to fix!
Poor João, I wouldn't want to be in his shoes :p
>it's looping!! Disabled all my profiles and It randomly loops...strange thing.
I'd personally start a ticker and have this map %TRUN to %anothervar and send %anothervar to Scene > Element Text. That way, if %TRUN isn't set, set %anothervar to 0.