Regression: Information provided by event.value changed in 3.2 #99102

New Issue

Julien Blervaque · 2022-06-23T09:04:43+02:00

Julien Blervaque commented

2022-06-23 09:04:43 +02:00

System Information
Operating system: Windows 10
Graphics card: GeForce GTX 970

Blender Version
Broken: 3.2.0
Worked: Every versions before 3.2.x

Short description of error
When doing a modal operator and checking for the value of the event the returned value is now "NOTHING" and not the state of the keys anymore.
This is really blocking for current scripts in production.

Exact steps for others to reproduce the error

On the default startup file go to the Script tab and run the code below.
Then open the terminal to see the printed outputs
Run the script
In the 3D viewport press F3 to get the list of the operators
Search with "3.2", find the operator named "Modal Operator - Event Regression on 3.2" and run it
Then click in the viewport on the mouse left button, move the mouse around and release the button

# This script illustrates a regression in Blender 3.2.0

- During a modal execution the event information is not filled as it used to be in previous versions
- which is now leading to a blocking situation to handle the state of the keys (keyboard or mouse) from events 

- Repro:
- - Open the terminal to see the printed outputs
- - Run the script
- - In the 3D viewport press F3 to get the list of the operators
- - Search with "3.2", find the operator named "Modal Operator - Event Regression on 3.2" and run it
- - Then click in the viewport on the mouse left button, move the mouse around and release the button

- In Blender BEFORE 3.2 the output in the terminal was;
#
- >event: type: MOUSEMOVE, value: RELEASE
- >event: type: LEFTMOUSE, value: PRESS
- >event: type: MOUSEMOVE, value: PRESS
- >event: type: MOUSEMOVE, value: PRESS
- >event: type: MOUSEMOVE, value: PRESS
- >event: type: LEFTMOUSE, value: RELEASE
- >event: type: MOUSEMOVE, value: RELEASE
- >event: type: ESC, value: PRESS

- In Blender 3.2 the output in the terminal is now;
# 
- >event: type: MOUSEMOVE, value: NOTHING
- >event: type: LEFTMOUSE, value: PRESS
- >event: type: MOUSEMOVE, value: NOTHING
- >event: type: MOUSEMOVE, value: NOTHING
- >event: type: MOUSEMOVE, value: NOTHING
- >event: type: LEFTMOUSE, value: RELEASE
- >event: type: MOUSEMOVE, value: NOTHING
- >event: type: ESC, value: PRESS

- Example adapted from Modal Execution of operator
- https://docs.blender.org/api/current/bpy.types.Operator.html

import bpy

class ModalOperator(bpy.types.Operator):
    bl_idname = "object.modal_operator_event_regression"
    bl_label = "Modal Operator - Event Regression on 3.2"

    def execute(self, context):
        return {'FINISHED'}

    def modal(self, context, event):
        
        if event.type not in ["TIMER"]:
            print(f"event: type: {event.type}, value: {event.value}")
        
        if event.type == 'MOUSEMOVE':  # Apply
            pass
        elif event.type in {'RIGHTMOUSE', 'ESC'}:  # Cancel
            return {'CANCELLED'}

        return {'RUNNING_MODAL'}

    def invoke(self, context, event):
        self.execute(context)

        context.window_manager.modal_handler_add(self)
        return {'RUNNING_MODAL'}

# Only needed if you want to add into a dynamic menu.
def menu_func(self, context):
    self.layout.operator(ModalOperator.bl_idname, text="Modal Operator - Event Regression on 3.2")

# Register and add to the object menu (required to also use F3 search "Modal Operator" for quick access).
bpy.utils.register_class(ModalOperator)
bpy.types.VIEW3D_MT_object.append(menu_func)

- test call
- bpy.ops.object.modal_operator('INVOKE_DEFAULT')

**System Information** Operating system: Windows 10 Graphics card: GeForce GTX 970 **Blender Version** Broken: 3.2.0 Worked: Every versions before 3.2.x **Short description of error** When doing a modal operator and checking for the value of the event the returned value is now "NOTHING" and not the state of the keys anymore. This is really blocking for current scripts in production. **Exact steps for others to reproduce the error** - On the default startup file go to the Script tab and run the code below. - Then open the terminal to see the printed outputs - Run the script - In the 3D viewport press F3 to get the list of the operators - Search with "3.2", find the operator named "Modal Operator - Event Regression on 3.2" and run it - Then click in the viewport on the mouse left button, move the mouse around and release the button ``` # This script illustrates a regression in Blender 3.2.0 - During a modal execution the event information is not filled as it used to be in previous versions - which is now leading to a blocking situation to handle the state of the keys (keyboard or mouse) from events - Repro: - - Open the terminal to see the printed outputs - - Run the script - - In the 3D viewport press F3 to get the list of the operators - - Search with "3.2", find the operator named "Modal Operator - Event Regression on 3.2" and run it - - Then click in the viewport on the mouse left button, move the mouse around and release the button - In Blender BEFORE 3.2 the output in the terminal was; # - >event: type: MOUSEMOVE, value: RELEASE - >event: type: LEFTMOUSE, value: PRESS - >event: type: MOUSEMOVE, value: PRESS - >event: type: MOUSEMOVE, value: PRESS - >event: type: MOUSEMOVE, value: PRESS - >event: type: LEFTMOUSE, value: RELEASE - >event: type: MOUSEMOVE, value: RELEASE - >event: type: ESC, value: PRESS - In Blender 3.2 the output in the terminal is now; # - >event: type: MOUSEMOVE, value: NOTHING - >event: type: LEFTMOUSE, value: PRESS - >event: type: MOUSEMOVE, value: NOTHING - >event: type: MOUSEMOVE, value: NOTHING - >event: type: MOUSEMOVE, value: NOTHING - >event: type: LEFTMOUSE, value: RELEASE - >event: type: MOUSEMOVE, value: NOTHING - >event: type: ESC, value: PRESS - Example adapted from Modal Execution of operator - https://docs.blender.org/api/current/bpy.types.Operator.html import bpy class ModalOperator(bpy.types.Operator): bl_idname = "object.modal_operator_event_regression" bl_label = "Modal Operator - Event Regression on 3.2" def execute(self, context): return {'FINISHED'} def modal(self, context, event): if event.type not in ["TIMER"]: print(f"event: type: {event.type}, value: {event.value}") if event.type == 'MOUSEMOVE': # Apply pass elif event.type in {'RIGHTMOUSE', 'ESC'}: # Cancel return {'CANCELLED'} return {'RUNNING_MODAL'} def invoke(self, context, event): self.execute(context) context.window_manager.modal_handler_add(self) return {'RUNNING_MODAL'} # Only needed if you want to add into a dynamic menu. def menu_func(self, context): self.layout.operator(ModalOperator.bl_idname, text="Modal Operator - Event Regression on 3.2") # Register and add to the object menu (required to also use F3 search "Modal Operator" for quick access). bpy.utils.register_class(ModalOperator) bpy.types.VIEW3D_MT_object.append(menu_func) - test call - bpy.ops.object.modal_operator('INVOKE_DEFAULT') ```

Julien Blervaque commented

2022-06-23 09:04:43 +02:00

Added subscriber: @Werwack

Campbell Barton commented

2022-06-23 09:36:49 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2022-06-23 09:36:49 +02:00

This was intentionally changed, 52af3b20d4.

Since the purpose of the value is to represent the state of the current event - it's not correct to leave this set to the previous value, which was an oversight as far as I can tell.

As it's possible for the modal operator to set values based on previous events it doesn't seem like there should be any issues updating scripts that relied on the previous behavior.

Otherwise, could you elaborate on why you need this functionality?

This was intentionally changed, 52af3b20d4. Since the purpose of the value is to represent the state of the current event - it's not correct to leave this set to the previous value, which was an oversight as far as I can tell. As it's possible for the modal operator to set values based on previous events it doesn't seem like there should be any issues updating scripts that relied on the previous behavior. Otherwise, could you elaborate on why you need this functionality?

Campbell Barton commented

2022-06-23 09:37:36 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Sybren A. Stüvel commented

2022-06-23 17:42:44 +02:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2022-06-23 17:42:44 +02:00

This change should have been mentioned in the release notes, as it introduces a change that add-on developers need to take into account.
Even worse, 52af3b20d4 is marked as "Cleanup", which implies that it should not make any functional changes.

This change should have been mentioned in the [release notes](https://wiki.blender.org/wiki/Reference/Release_Notes/3.2/Python_API), as it introduces a change that add-on developers need to take into account. Even worse, 52af3b20d4 is marked as "Cleanup", which implies that it should not make any functional changes.

Campbell Barton commented

2022-06-24 03:07:09 +02:00

With the benefit of hindsight I can see it would have been good to include in release notes (done), however 3.2 included many changes to details in the event system which could technically be considered breaking-changes but in practice tend not to cause any problems. It's not always obvious is changes like these might cause problems ahead of time.

Leaving open so @Werwack can give feedback.

With the benefit of hindsight I can see it would have been good to include in release notes (done), however 3.2 included many changes to details in the event system which could technically be considered breaking-changes but in practice tend not to cause any problems. It's not always obvious is changes like these might cause problems ahead of time. Leaving open so @Werwack can give feedback.

Julien Blervaque commented

2022-06-24 15:02:07 +02:00

Removed subscriber: @ideasman42

Julien Blervaque commented

2022-06-24 15:02:07 +02:00

@ideasman42 Hi Campbell,
Thank you very much for your answer.

Well, according to what you say this is not a regression then.
Since it was intentionally changed, it should indeed very likely have been mentioned in the 3.2 changelog , which is the first place where we look when we face a strange behavior on a new release. This way it saves a lot of time to a lot of people... 🙄

I was relying on the PRESS and RELEASE flags in particular to capture some tricky events such as when the user starts a drag and then switch to another application (alt + tab for instance), release the button there and then comes back. What happens in this case is the release is not captured by the source app (here Blender) and when the user comes back you get a "sticking" effect where the object that was manipulated seems (in my case) glued to your cursor but your button is not pressed and then you have troubles to get back to the standard context.

Looking at the task you shared it looks like the PRESS state wasn't so reliable ("In some cases value of cursor motion events was set from the last event"). It seemed to work so far on my side though, at least for that... I did a fix on my issues and as for the tricky cases, well, I'll find another way to trap them as best as possible.

One way I tried again even recently is to check the state of the keys on the mouse and keyboard - outside an event I mean - but I couldn't find some code in the API for that, not in the Python libraries. Do you know if that could be introduced in Blender at some point?

Appart from this question I think you can close the issue 😉

Thanks

@ideasman42 Hi Campbell, Thank you very much for your answer. Well, according to what you say this is not a regression then. Since it was intentionally changed, it should indeed very likely have been mentioned in the [3.2 changelog ](https://wiki.blender.org/wiki/Reference/Release_Notes/3.2/Python_API), which is the first place where we look when we face a strange behavior on a new release. This way it saves a lot of time to a lot of people... 🙄 I was relying on the PRESS and RELEASE flags in particular to capture some tricky events such as when the user starts a drag and then switch to another application (alt + tab for instance), release the button there and then comes back. What happens in this case is the release is not captured by the source app (here Blender) and when the user comes back you get a "sticking" effect where the object that was manipulated seems (in my case) glued to your cursor but your button is not pressed and then you have troubles to get back to the standard context. Looking at the task you shared it looks like the PRESS state wasn't so reliable ("In some cases value of cursor motion events was set from the last event"). It seemed to work so far on my side though, at least for that... I did a fix on my issues and as for the tricky cases, well, I'll find another way to trap them as best as possible. One way I tried again even recently is to check the state of the keys on the mouse and keyboard - outside an event I mean - but I couldn't find some code in the API for that, not in the Python libraries. Do you know if that could be introduced in Blender at some point? Appart from this question I think you can close the issue 😉 Thanks

Campbell Barton commented

2022-06-24 15:22:25 +02:00

Changed status from 'Needs User Info' to: 'Archived'

Campbell Barton closed this issue

2022-06-24 15:22:25 +02:00

Campbell Barton commented

2022-06-24 15:22:25 +02:00

Thanks for the feedback, Blender stores the previous event value in events already, but they weren't exposed to Python. Committed 2580d2bab5 to address your use-case.

Thanks for the feedback, Blender stores the previous event value in events already, but they weren't exposed to Python. Committed 2580d2bab5 to address your use-case.

Julien Blervaque commented

2022-06-24 20:59:34 +02:00

Committed 2580d2bab5: PyAPI: Expose event.type_prev, value_prev to address your use-case.

That would be really nice to expose that, indeed 👍
Thanks again!

> Committed 2580d2bab5: PyAPI: Expose event.type_prev, value_prev to address your use-case. That would be really nice to expose that, indeed 👍 Thanks again!

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Regression: Information provided by event.value changed in 3.2 #99102