Blocks have event logic handlers “on visibility change”. When the visibility of a block is tied to a property in Page Data, a change in visibility does occur… but the logic in “on visibility change” does not execute. Unless I misunderstand what “on visibility change” really means? To reproduce, create a button that toggles the property “on” between T & F in Page Data. Then add a (colored) block to the page with:
The logic block you posted seems to change the visibility of something (page title) when the visibility of some other component is changed. So it “does something”, the same as a “print” statement does something. Are you saying that logic in the “on visibility change” area only runs if it is logic to modify the visibility of some other component? That doesn’t make any sense…
or maybe you meant to say that “on visibility change” is triggered only when a “toggle visibility” code block is executed somewhere else on the page? But in that case, there is no reason to have the “on visibility change” area at all, we can just trigger logic in the same place where we place the “toggle visibility” block.
My bad, @Alex_Klein, for providing an inaccurate image. You are correct in this part:
“on visibility change” is triggered only when a “toggle visibility” code block is executed somewhere else on the page? But in that case, there is no reason to have the “on visibility change” area at all, we can just trigger logic in the same place where we place the “toggle visibility” block.
Additionally, "toggle visibility” can be called from different components, but “on visibility change” is one for this component.
Hi @Marina.Kan, I can confirm that when another piece of logic somewhere on the page runs “toggle visibility”, then the block’s “on visibility change” logic area does trigger.
However: my suggestions/feedback/feature request for Backendless are that
a) it would be great to have “on visibility change” execute when visibility changes, no matter for what reason or why it changes… otherwise the label “on visibility change” is very misleading. It would have saved us quite some time to understand that “on visibility change” doesn’t actually mean what it appears to mean.
b) if that’s not possible, I would recommend that you just eliminate this event handler from blocks and similar components… because rather than creating a block “toggle visibility” in order to effect some other logic to run, we can simply run such other logic directly. The “on visibility change” really serves no purpose, doesn’t save anyone any code simplification or clarity except for the most unusual circumstances that I can think of, and only leads to confusion as in our case.
c) If Backendless thinks “on visibility change” really is useful, it would be great to have some sort of warning or easy to find explanation about when this event trigger actually triggers (only if visibility changes as a result of a direct “toggle visibility” code block executing somewhere else on the page).
Hope this makes sense? I still suspect this behavior is actually a bug, but your explanation sounds like you’re confident that it’s “expected behavior”. Thanks for all you do
In case someone is interested in a work-around so as to be able to trigger an event when a container changes visibility:
We can put an empty block inside of the container, this “dummy block” can have 0 margin, 0 padding, no min width or height… so it’s basically invisible. The block is mounted/unmounted when the container visibility goes to True or False (see here). This means we can create our logic in the “on mounted” and “before unmount” logic areas of the dummy block.
