Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community

At 18 JUN 2008 08:33:00AM Charlie Engler wrote:

At the risk of seeming as stupid as I was in my last post, I have another question about locking.

When we retrieve a record using any form the record is automatically locked. If we save the record or clear the screen, the record is automatically unlocked. All is well at this point.

If, on the other hand, the user does not save or clear the record but uses the red "X" to close the form, the record remains locked until they either close the application or retrieve the record again and then save or clear the form.

I've been able to duplicate this on every form and any workstation.

I've instructed our users to properly clear the record before closing a form but on busy days, this doesn't always happen.

This problem does not occur in RBasic…only on forms.

I installed UD 4 on Monday but this problem has been around for a couple of months or so.

Any ideas??

Thanks,

Charlie Engler


At 18 JUN 2008 10:02AM Dave Harmacek wrote:

I just checked this in 8.0.6 and found that both Alt-C and the X executed the form's CLOSE event. I just put a call msg( @window, 'close event') in the script of the form CLOSE event and a return 1.

I suspect the CLOSE event of a form has the UNLOCK logic.

I doubt your problem is at the network driver level.


At 18 JUN 2008 11:13AM Sean FitzSimons wrote:

Charlie,

Are the forms databound or are they populated from an event/routine on the read event of the form? If the records are locked programatically on the READ and the CLEAR and SAVE are unlocking the file properly is it due to explicit UNLOCK calls on those events that are somehow bypassed when the "X" is clicked.

Do you have code on the CLOSE event that is not being executed when the "X" is encountered.?

Sean


At 18 JUN 2008 11:43AM [email protected]'s Don Bakke wrote:

Charlie,

This is indeed strange behavior. I would be interested to see your responses to Sean's questions. This is also reminiscent of another problem someone reported last December relating to the way a form was closed.

[email protected]

SRP Computer Solutions, Inc.


At 18 JUN 2008 02:00PM cr engler wrote:

All the forms are databound.

Some of the forms contain non-databound fields that are filled with additional reads/xlates from tables other that the one bound to the form.

I use to alert the user of various status conditions relating to the customer/orders. I don't perform any programatic locks on any of the "other" tables/records before retrieving this data.

I inserted test code in the close event of several tables and the close event does fire when the "X" is used.

I did find a couple of seldom used tables that never contained any code in the close event. Those forms release the locks ok when the "X" is used. I think I'm going to clear the close event on one of the problem forms and recreate the event from scratch and see what happens.

Thanks, Charlie


At 18 JUN 2008 02:44PM cr engler wrote:

I did some additional testing and found the following….

We use the F8 key to clear the form. When F8 is pressed the clear event is called properly and the form is cleared and the lock released.

We use the F9 key (Yes, we used to use AREV) to save the record. When F9 is press the record is written properly, the clear event is called, the screen cleared and the lock released.

When I "X" out, the clear event is not called. Is this normal behavior and could it be part of the problem? We've not had this problem until recently.


At 18 JUN 2008 03:25PM cr engler wrote:

Yet another chapter in the continuing saga of record locks…

I created a new form and it worked properly so it appears that it's only my existing forms that manifest the problem.

Charlie


At 18 JUN 2008 09:48PM Barry Stevens wrote:

]]I inserted test code in the close event of several tables and the close event does fire when the "X" is used.

Did you have return 1

Check your other forms have not had the close event compiled with the return 0. Try clearing the event (Menu option) save then save the form and test again.


At 18 JUN 2008 10:09PM [email protected]'s Don Bakke wrote:

Charlie,

This certainly sounds like event script interference somewhere. In the forms that duplicate this problem, I am wondering if you notice a difference when the data record is unmodified versus modified. In the former situation there would be no SaveWarn flag but in the other there would be. There might be a connection here.

You might need another pair of eyes to look at this. If you are willing to package this up and upload to me I would be happy to look at it for you.

[email protected]

SRP Computer Solutions, Inc.


At 18 JUN 2008 10:10PM [email protected]'s Don Bakke wrote:

Did you have return 1

I thought of that, but then surely the form wouldn't even close if this weren't the case. Correct?

[email protected]

SRP Computer Solutions, Inc.


At 19 JUN 2008 08:22AM Sean FitzSimons wrote:

Is there conditional logic based on the CancelFlag parameter, such as if CancelFlag=1 then ….

The "X" close passes a null as the parameter to the Close Event.

Sean

View this thread on the Works forum...

  • third_party_content/community/commentary/forums_works/ce0c80f778315d0e8525746c0044f093.txt
  • Last modified: 2023/12/30 11:57
  • by 127.0.0.1