LV_EVENT_CLICKED not generated when it is supposed to be. about lvgl HOT 31 CLOSED

I did see something in the MicroPython code that leads me to think that I should be able to convert a python object to a C object and then have that c object passed back to a python function as a parameter. The trick here is it is going to be a pointer to a memory address when it makes it back to Python code. I believe it is going to be stored in a structure and That structure has a function associated with it called __dereference__ and from what I am seeing that function should convert it back to the original python object using the memory address...

I have to test it to see if it actually works. In all reality the name of that function should have been called __cast__ and the object that you want to cast the pointer to should be passed and in the case of an array the length would be the second parameter.

from lvgl.

I am now looking at this and I am thinking that "CLICKED" means a press and release has occurred.

from lvgl.

A Click is really a Press followed by a Release. Is there any issue with that?

from lvgl.

Docs should be updated to say that. I realized that after I made this issue but I left the issue because the docs need to be updated.

PRESSED gets fired on mouse button down or touch
RELEASED gets fired on mouse button up and touch release
CLICKED is fired on mouse button up and touch release

CLICKED is redundant to RELEASED because you cannot have a RELEASED unless there was a PRESSED which infers CLICKED.

If PRESSED and RELEASED can occur if any part of a widget is touched or clicked on and CLICKED only occurs on a part of the widget that is supposed to allow user interaction.. That would make sense, I don't think this is the case tho.

As an example say we have a slider and the only part of the widget that has any kind of user interaction would be the knob and nothing else. If I clicked on the indicator there would be a PRESSED and RELEASED event but no CLICKED event. Now if touch the knob all 3 events would get fired.

I know that the slider doesn't work like that but if it did work like that...

Another example is an image. an image doesn't have any user control so it should never generate a CLICKED event if it is touched. It should generate the PRESSED and RELEASED events.

CLICKED should only get fired if what is being touched has some kind of mechanics to it for user interaction.

from lvgl.

CLICKED is redundant to RELEASED because you cannot have a RELEASED unless there was a PRESSED which infers CLICKED.

They are almost the same, but e.g. if you scroll a list, by dragging a button and release it, RELEASED will be triggered but CLICKED won't.

The user can attach any kind of events to the widgets, They can do something image click too. Why not?

from lvgl.

I get what you are saying. The documentation needs to be updated to explain the CLICKED event better. It needs to describe when the CLICKED event get fired. So when dragging no clicked event occurs only when it is a press and release with no position change.

from lvgl.

It's documented here and here too.

from lvgl.

It should be a little more explicit. Something to the effect of "This event on differs from the RELEASED event in that it will not get triggered if anything was scrolled." This tells us that all aspects of the event will work the same as the RELEASED event except for not being triggered if scrolling occurred.

I personally think this even should only get triggered if a user controllable part of a widget is what got clicked on. If a user wanted to react to an lv_image being clicked on they can use the RELEASED event for that purpose.

Question tho. If there a function that can be used that takes an event as a parameter to determine if any scrolling has occurred? For the purposes of the RELEASED event if any scrolling has taken place from the time the PRESSED event occurred and the RELEASED event occurred the function would return true

I know that it would not be something you would want to change the behavior of but it does make more sense to have it function in this manner. It is something that the user would be able to use when using lv_obj_t as a container to build a kind of custom widget. It would allow them to react to user input that matters for all of the children in that container without having to target specific objects.

Example:

void event_cb(lv_event_t *e) 
{
    if (lv_obj_has_class(lv_event_get_target(e), lv_button_class)) {
        // CLICKED EVENT OCCURRED
        // If the CLICKED event only happened on things that were able to be interacted with by the user
        // The above test would not need to take place. 
    }
}


lv_obj_t *create_widget(void) 
{
     lv_obj_t * container = lv_obj_create(lv_screen_active(NULL));

    lv_obj_t *text = lv_label_create(container);
    lv_obj_t *button = lv_button_create(container);
    lv_obj_t *label = lv_label_create(button);
    lv_obj_set_text(label, "BUTTON");
    lv_obj_center(label);
    lv_obj_center(button);
    lv_obj_set_text(text, "THIS IS SOME TEXT");
    lv_obj_align(text, LV_ALIGN_CENTER, 0, -25);
    lv_obj_add_event_cb(container, &event_cb, LV_EVENT_CLICKED, NULL);
    
    return container;
}

lv_obj_t *widget = create_widget();

from lvgl.

The logic of the CLICKED event wasn't criticized so far, so wouldn't touch it now.

You can use lv_indev_get_scroll_obj(lv_indev_active()) to get scrolled object in an event if any.

from lvgl.

I know it was done how it was done a long time ago..

I know that LVGL tries to model it's behavio inline with what is seen in a web browser. Are there clicked events that get triggered when a user clicks on an object that isn't "clickable".... Even if that object has a callback registered to the clicked event??

Take a look at the DIV object. It is an HTML object, You can set it's size and apply styles to it. for all intents and purposes it is the equivalent of an lv_obj_t. There is something it doesn't do, it doesn't generate clicked events. You cannot even force it to programmatically, it will give you an error. That is because it is not an object that the user can interact with. Now I am not saying to lock it out all together. There should be a way for widgets to define what can and cannot be clicked and the areas that cannot be clicked when clicked on don't generate the clicked event.

from lvgl.

It seems an onclick event can be added to a div without any issues: https://codepen.io/kisvegabor/pen/oNRvGEJ

from lvgl.

I misread. a div element doesn't have the click function.

Let me try and attack this from a different angle...

If I remove the LV_OBJ_FLAG_CLICKABLE flag from an object does it stop the following events from getting triggered??

• LV_EVENT_PRESSED
• LV_EVENT_PRESSING
• LV_EVENT_LONG_PRESSED
• LV_EVENT_LONG_PRESSED_REPEAT
• LV_EVENT_SHORT_CLICKED
• LV_EVENT_CLICKED
• LV_EVENT_RELEASED

or does it only stop only these events from occurring?

• LV_EVENT_SHORT_CLICKED
• LV_EVENT_CLICKED

from lvgl.

From the indev's point of view the object will be invisible. So none of the touch related events will be fired.

from lvgl.

Essentially what you are saying is if CLICKED gets disabled the PRESSED event which could be for the purposes of scrolling would not get triggered?

from lvgl.

True. Something is either touchable or not.

from lvgl.

I am going to have to run some tests to see what the behavior is.

from lvgl.

OK so if I clear the clickable flag I am not able to scroll. hover events stop, pressing a dragging stops. That is not correct. A click is defined as pressing and releasing without changing position. It has nothing to do with scrolling, or hovering or pressing and dragging. Those events should not stop when the CLICKABLE flag has been removed.

from lvgl.

I think the root of the confusion is bad naming of CLICKABLE. I think it should be TOUCHABLE.

from lvgl.

if it stops the object from being touchable at all then yes that is what it should be named. But there still should be a clickable flag so that say a button cannot be "click" but it can be touched, something like say scrolling. This would be a handy thing to use to control the scrolling of something like say a spinning list where the only thing you want to be clickable would be a button that is directly in the center. the rest that are visible you would unset the clickable flag so those buttons cannot be pressed but a user would still be able to do things like touch it to scroll or touch it to move it.

It would be a good way for a user to disable the ability to press something but still allow the ability touch to move an icon or something along those lines.

from lvgl.

If we added the CLICKABLE flag like this we needed to add PRESSABLE, LONG_PRESSABLE, etc too. Therefore I think the logic that you have described should be handled in the event callback instead. E.g.

void button_click_event_cb(lv_event_t * e)
{
  if(is_in_right_position(lv_event_get_target(e) == false) return;

  printf("Clicked\n");
} 

from lvgl.

The issue is when you turn off the clicking it turns off all interactions including hovering. All events stop not just the click event.

if clicking gets turned off I should still be able to scroll as that is not a click. a click is defined as a press and release without any movement. Scrolling is a press and drag which means it is not a click.

Clicking is the correct event name for what is occurring but it is like the parent event and all other events are a child of it so when the parent is disables the children also are disabled. It should not be that way. Click should be the parent of long click, double click, left click, right click, etc... It should not be the parent of click and drag or scroll up, down, left or right. Even tho the name click and drag infers a click is taking place that's not really what is happening. It should be called "press" and drag but that doesn't sound as good as click and drag.

from lvgl.

I don't understand what is the problem with just not adding an event callback for the event that you want to "disable"?

from lvgl.

When dealing with things in C code it is easy to make things globally available like a callback function. This is not always the case in something like Python. While there can be the ability to access a specific child through LVGL form anywhere where in the code that callback function might not be easily accessible so if the function happens to be removed instead if disabling the event there might not be a way to add the function back if the events are wanting to be processed again.

As an example.. If you have 2 modules and in one module you have the callback function and that callback function is added to an object from inside of that module. that same module imports the other module In that other module is the code to disable the event or as you are saying to do would be removing the callback. Problem is that second module is not going to be able to import that first module because the first module is already importing the second one. You end up with a looping import which causes the program to crash. The only thing that is wanting to be done is simple, stop the clicked event from occurring but still allow things like scrolling to work. There is no way to collect the python callback function from the object either. There is no way to solve this kind of an issue without having to do some import hacking to get it to work. That is just going to make things prone to problems.

from lvgl.

I see your use case now. However I think the solution still shouldn't be to add flags for all possible events.

Isn't there a way to store a flag in the widget's class that you can set and ignore the event based on that. E.g.

btn.my_flag = 1;

def event_cb(e):
   obj = e.get_target() 
   if obj.my_flag: return
   ...

from lvgl.

You can't access fields directly like that in the structure because lv_obj_t is private. You have the user_data that you can use for something like that provided it is not being used to hold callback information like what is done in the MicroPython binding. There is really no way to go about handling this other than changing the click event so it only gets fired when a click (press and release without changing position) occurs. The rest of the events would continue to take place if the clicked flag gets unset because after all a click is not the same thing as a click and drag or any other event that would occur due to a touch or or "click"

from lvgl.

Wait, isn't there a way to dynamically add fields to a class? E.g.

class MyClass:
   x = 5
 
a = MyClass()
print(a.x)    #5

a.y = 10
print(a.y)   #10

from lvgl.

can't do that with C modules. and I can't pass any python objects other than primitives to C functions unless it is something that is expected.

As an example. I am not able to pass a python class instance as user data. I can pass primitives like int, str, bytes, float, etc....

The adding of attributes to a class or a class instance in micropython cannot be done with the binding because the classes are custom made and they have specific getter and setter functions that look for pre defined names. if you set an instance variable and the variable is not in the list of already defined names you will be met with an exception.

from lvgl.

According to this you can set self as user_data where you can store any data. What do you think?

from lvgl.

Does it mean that it can be a solution to this issue? 🙂

from lvgl.

We need some feedback on this issue.

Now we mark this as "stale" because there was no activity here for 14 days.

Remove the "stale" label or comment else this will be closed in 7 days.

from lvgl.

As there was no activity here for a while we close this issue. But don't worry, the conversation is still here and you can get back to it at any time.

So feel free to comment if you have remarks or ideas on this topic.

from lvgl.