I've encountered a peculiar effect:
I execute a vis 255, 0 command at the start of a page preinitialize event and then go on to try and start a timer a few lines later, the command is completely ignored!
It seems like the timer enabling command will only work if the component is visible...?
Sure enough, when I get rid of vis 255, 0 the program works as expected and the timer starts ticking.
Here's an example to illustrate:
I open a page which contains a timer tm_init with its preinitialized tm_init.en parameter equaling 0.
Next, I write:
[tm_init timer body]:
if(con_nect==1) //con_nect is a variable which is initialized to 0
In this case, the timer refuses to start. In order to launch it, I need to get rid of vis 255,0. Should this behavior be expected, or have I found some flaw or bug?
Where is your proof the timer starts ticking?
- I haven't dug into recreating your scenario, yet.
- is this assumed that the timer started ticking
or is there evidence you have that it indeed has.
Preinitialize occurs before the HMI page is loaded as per static design.
Postinitialize occurs after the HMI page has been loaded per static design
the .vscope of a component can/will influence if the loading of static design
will change the state of the component.
Not to pick on things but as presented I see no means this can work
if(con_nect==1) should throw an error,
if con_nect is initialized to 0,
- nothing of the trigger is mentioned ??
- So I see no means presented where "timer is stopped"
all becomes visible and touch enabled
But really, vis 255,0 and tsw 255,0 is not programming purposefully
- this is really haphazard with too less thought as to why
Without being too hard, such is seen in great laziness to avoid having to
go through selectively and purposefully to create detailed code.
I would argue and have many times, MCUs need to be programmed purposefully.
It would be my take that vis 255 disables all components.
vis would be interpreted as visible
- but it isn't your eyesight that "visible" refers to
but the visibility of the component to the interpreter.
So hotspots, variables, timers
these may not be eyesight visible components
but they are components
- so to hide them from the interpreter ... how would they run
- what is expected behaviour for a hidden component - ignored.
I would think the only rescue would be a vis 255,1 sent over serial
But considering vis 255,0 and tsw 255,0
- why is this not an equivalent to an empty page?
- why not just wait on an actual empty page and
then wait for the MCU to issue a page change on proper condition?
Is the logic not flawed for con_nect as there is no actual determination of this
- the Nextion has no "if connected" to determine if connection has been established
or any determination if the connection has once again become lost.
So I would think this is would be more of a user created scenario, less of a flaw or bug.
Verified - vis will hide component from interpreter
vis tm0,1 will make visible the timer tm0
as it is visible, the timer's code event will trigger
vis tm0,0 will hide the timer tm0
and as hidden, the interpreter will once again ignore
but this also means that if con_nect is also hidden
again such will fail.
if the MCU has to send a connect.val=1ÿÿÿ over serial
it might as well just as easily send page 1ÿÿÿ
Code is only doing as it has been instructed to do.
Alright, so I've checked out some possibilities and this is what works:
The timer is now launched, no problem. con_nect and other variables are available for modification in between. So the documentation should state that vis also affects timers by either restricting or making them available to the interpreter.
It cannot in any way be inferred from the current description of vis, seeing how actual visibility (stuff you can see with your eye) and interpreter restrictions are two completely separate things.
Just to summarize the whole thing in case anyone has experienced similar issues and is looking for answers:
However, the developer wanted to say that the "vis" command is used to include or exclude a component from the program i.e. the component and its code becomes (in)visible to the INTERPRETOR and not the USER.
More scientifically accurate, the code above was "anticipated" that it would work
The interpretation of the vis command from the Nextion Instruction Set.
The instruction set vis command describes and states "all components"
1.The first parameter 255 means all components in current page,
vis 255,0 (hide all components in current page);
vis 255,1 (show all components in current page).
So one has to ask what is a hide timer suppose to do
- timers are definitely components, and thus inclusive to a hide all
So when the observed effect of hiding a timer is event code doesn't trigger
it's not too far of a stretch visibility is from the interpreter on not the just the eye.
I don't think it is a failure of the Instruction Set documentation.
but it would definitely be an human interpretation where visible can also
mean visible (eyesight visually) since many components are visual components.
From an MCU perspective with limited resources, it is less likely to bloat the firmware
to make distinctions between component types and exclusions for others on "all".
So academically, hide all will toggle all components
its behaviour now having been observed, one can again program purposefully.
I would still argue that vis and tsw 0 is effectively an empty page
I would also still argue for purposeful programming, and away from such shortcuts.
The firmware that must fit within 4608 bytes can not possibly guard against all
I can indeed brick a Nextion with a non purposeful HMI design (until another is loaded)
so maybe this will help explain why I advocate so strongly for purposeful programming.
In purposefully ensuring visibility of specific components needed for functionality
there is no error, and all runs as expected
Short cut to toggle all
well, we see it can have undesired side effects, as such was the experience.
You later interpretation would be more accurate.
- what happens in a resource rich HTML, CSS, Java
is not the same as what is possible in a resource limited MCU
(such as what drives the Nextion)
We do not have the ability to alter or augment the Nextion Instruction Set.