Changing code text, reverting, and visiting another event causes the reverted state to be restored #2

Closed
IsmAvatar opened this Issue Jan 23, 2012 · 1 comment

Comments

Projects
None yet
1 participant
@IsmAvatar
Owner

IsmAvatar commented Jan 23, 2012

Steps to reproduce:

  1. Open LGM
  2. Create Object
  3. In an event, drop a piece of code
  4. Populate the code with something (e.g. "Hello world") and we'll call this State 1. Save it, and reopen it
  5. Change the text, we'll call this State 2
  6. Close the code without saving (X button, No)
  7. Visit another event, and then return to your event with code
  8. Open the code to observe its contents

Observed behavior: Contents reflect State 2
Desired behavior: Contents reflect State 1 (e.g. "Hello world").

This seems to be caused by the wrong state being chosen despite the revert, and further seems to depend on the ActionList being flushed.

IsmAvatar added a commit that referenced this issue Apr 21, 2012

@IsmAvatar

This comment has been minimized.

Show comment
Hide comment
@IsmAvatar

IsmAvatar Apr 21, 2012

Owner

Fixed in ff5628a. The issue was caused by rejected action frames being kept in memory and then committed during ActionList context switch. The solution was pretty much to only commit actions whose windows are still open. I'm not sure when it sprang up, but it may have been when I made ActionFrames part of the modular frame system.

More interesting, however, is that there seems to be a lot of code to allow ActionFrames to float around simultaneous of other ongoing modifications of other actions and objects, even though ActionFrames are modal. This is a lot of extra code that isn't being put to use, and this should be investigated - either to put the code to use (by making AcitonFrames non-modal) or by eliminating it. I digress, though - this bug is solved, I got what I came here for.

Owner

IsmAvatar commented Apr 21, 2012

Fixed in ff5628a. The issue was caused by rejected action frames being kept in memory and then committed during ActionList context switch. The solution was pretty much to only commit actions whose windows are still open. I'm not sure when it sprang up, but it may have been when I made ActionFrames part of the modular frame system.

More interesting, however, is that there seems to be a lot of code to allow ActionFrames to float around simultaneous of other ongoing modifications of other actions and objects, even though ActionFrames are modal. This is a lot of extra code that isn't being put to use, and this should be investigated - either to put the code to use (by making AcitonFrames non-modal) or by eliminating it. I digress, though - this bug is solved, I got what I came here for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment