Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Using Ctrl-Z with two OI sessions and the SRP editor

I have had a couple of interesting events in the last couple of days. I am using Version 3.3.1.0 and the OCX version is 3.3.8.2. Using an RDP session I start two copies of OI from the same folder. I start my current work copy first and then start a reference copy. I am doing a lot of work where I have to refer back to calling programs . I also have to open some AREV2 programs as they are being converted. Generally all of those are in the reference copy. I am also careful to always close the reference copy first at the end of the day to keep from getting my favorites out of whack.

The problem occurred when I was switching back and forth between the same program. Let me call the program SR_123. So I open SR_123 in the development session. I then start up the SRP Editor in my reference session and open SR_123 there also. It properly shows locked but does announce a change if I accidently make a change to SR_123 in the reference session.

What I think happened was that I did a bunch of work in the SR_123 development session and then went over to the reference session and accidently bumped a key making a change to that SR_123. I then selected Ctrl-Z to correct the typo in the SR_123 reference version. I have some testing to do but I think that what happened next was that I clicked back over to the development version and I must have saved it. Later when I went back to SR_123 in the development session all of my recent code was gone and I was looking at what had been showing in the SR_123 reference version. I think this has happened to me before but I was blaming it on just being forgetful or distracted and not saving my code.

I am going to spend some time to see if I can duplicate the sequence. But I would be interested to know if anyone else has seen that behavior or anything similar?

Comments

  • edited July 2022
    I think it might be simpler than that. There is a long-standing bug I've been aware of--one that is very difficult to duplicate--where the Undo Buffer gets "stuck" such that pressing Ctrl+Z undoes everything instead of just your last change. I think you lost more than you thought when you did Ctrl+Z and saved it.

    It is a rare bug, but very annoying. I want to find and crush this bug, and I have some ideas on how to trace it down, but I need to just find the cycles to do it.

    That's my current theory, though I'm not ruling out your theory altogether. Your use case is also uncommon, so perhaps that could lead to a strange interaction. I will say that the SRP Editor checks once for a lock (when the record is first opened). Once it knows something is locked, it will not allow it to be saved, even if the record unlocks elsewhere during that session.
  • Thanks Kevin, I will do what I can to watch for this and see if I can offer up any clues.
  • This isn't a work around or fix for the Ctrl-Z issue, but when I know I'm working on a stored procedure that is locked, I don't Ctrl-Z to "undo" the change that can't be saved. Rather, I move it to the Favorites section (Ctrl+F8), close it (Ctrl+W), ignore the savewarn, and click it to re-open it. It will also get the latest changes that way.
Sign In or Register to comment.