Start a new topic

vis 255 strange effect

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:

[Preinitialize event]:

vis 255,0

tsw 255,0


[tm_init timer body]:

if(con_nect==1) //con_nect is a variable which is initialized to 0



vis 255,1

tsw 255,1


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

Do you?

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:

vis 255,0

tsw 255,0


vis img_connect,1

vis tm_init,1


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:

The name of the "vis" command, which, mostly likely, is a shortened version of "visible" and its description in the documentation ("vis: Hide/show component") made me think that the command only affected the physical visibility of components on-screen. It is fairly easy to make this mistake, as similar "visible" tools in HTML, CSS, JavaScript...etc mean exactly the same thing.

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,

    for example:

            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.

Login or Signup to post a comment