Locking records on databound forms

prattspets · January 2016

I am looking for some ideas on a better way to lock records when using a databound form. I am using an edit line for the Key with the default being SEQKEY. The OI databound form is handling the locking as follows, as far as I have observed. The edit line is populated with the next default key and the record will be locked when you lose focus from the editline as well as changing the caption of the form to include . If the record becomes locked on another station on the network between the time that the default sequence key is populated and the edit line loses focus, OI sends a message to the user that the record is locked and sends a message to find out the user wants to continue or cancel (default on the YES to continue with the locked record that cannot be modified).

In the form I am working on, I would like the Key generated from the sequence key and locked automatically, without the user having to tab out of the editline to make it lock. I am finding this to be a little more difficult than I originally thought it would be. If I try to lock the next sequence key to use on the form programmatically, I still have to unlock the key, put it in the edit line and send the READ event to have the form handle the locking as it is designed. In the period of time that I unlock the record to get the OI databound form to handle the locking, there is a risk of another station getting that record locked.

Does anyone have some suggestions on ways to handle the locking programmatically and still working with the OI databound form handling the locking?

BarryStevens · January 2016

Any forms that require a sequential key I name the field on the form as ID
In a promoted gotfocus event I do:

if CtrlentId[-3,3]=".ID"  then
	if get_property(CtrlEntId,"DEFPROP") = "" and not(ISITQBFINITMODE(Window)) then

		set_property(CtrlEntId,"DEFPROP","<<NEW>>")
	end
end

then in a promoted lostfocus event I do:

if CtrlentId[-3,3]=".ID"  then
	Id=get_property(CtrlEntId,"DEFPROP")
	if ID = "<<NEW>>" or ID ='' then

		locate keyMap@<1,1> in controlMap@ using @fm setting pos else
		    return 0
		end

		tableName = controlSemantics@ <pos, CS_TABLE$>

		Id=get_next_sk(TableName)
		set_property(CtrlEntId,"DEFPROP",Id)
	end
end

The code for get_next_sk is:

function get_next_SK(File)
declare function lock_record, RowExists

open File to hFile else return 'ERROR'
open 'DICT.':File to hDict else return 'ERROR'

SK = '%SK%'

loop until lock_record(hDict,SK) repeat
readv Key from hDict,SK,1 else
	Key = 1
end
OrigKey=Key

if Key <= 0 then Key = 1

loop
	gosub CheckIt
until  OK
	Key+=1
repeat
if Key >= OrigKey then
	writev Key+1 to hDict,SK,1 else null
end
unlock hDict,SK else null


return Key

Checkit:
	Status = 0
	Ok=0
	RowExists = xlate(File,Key:Suffix,"","X")
	
	If RowExists else
		lock hFile,Key:Suffix then
			OK=1
			unlock hFile,Key:Suffix else null
			
		end  
	end
return

DonBakke · January 2016

Not what you asked for, but why do you need the locking to work this way?

That question aside, you might see if setting the "Ignore self-locks" flag for the Form Designer allows you to avoid the need to unlock your Key ID before the READ event.

prattspets · January 2016

Thanks Barry and Don for the help. I wasn't aware or had forgotten about the options that the form designer had for locking on the form. That solves my dilemma perfectly.

Don: To answer your question about why I am trying to have the locking work this way.... It's a POS form that I am trying to limit the number of keystrokes for the user as much as possible for efficiency at the cash register. It is a redundant step for the user to tab or enter the default ID every time, when the ID is really no concern for the cashier. I also have found that the cashier will miss the internal warning message that OI gives when attempting to start a new transaction with a record that is already locked by another user, and they will hit enter to continue with the transaction, not knowing that they unsuccessfully modifying a record that cannot be saved.

Any thoughts on perhaps a better way to achieve my goal is always appreciated! :)

Thanks!

DonBakke · January 2016

Dan,

One way to handle this is to automatically force the LOSTFOCUS event to trigger when the Key ID control gets focus and the GOTFOCUS_VALUE property is different than the TEXT property. This would make use of the following behavior:

The SEQKEY logic will trigger before your GOTFOCUS event handler (if using QuickEvent)
The SEQKEY logic only defaults a Key ID if it is new and unlocked. So, at that moment the Key ID is safe.
The LOSTFOCUS event will automatically trigger the form's READ event handler because the GOTFOCUS_VALUE and TEXT properties will be different.
Hence, the form puts the lock on the Key ID automatically and the user did not have to make any additional keystrokes.
If the user cycles through the form and goes back into the Key ID control, the GOTFOCUS_VALUE and TEXT properties will be identical so no special logic will execute.

If you wanted to add something extra, then after sending the LOSTFOCUS event set the FOCUS property to the next control in the tab order which would save yet another keystroke. Your code would look something like this:

GotfocusValue   = Get_Property(CtrlEntId, 'GOTFOCUS_VALUE')
Text            = Get_Property(CtrlEntId, 'TEXT')
If GotfocusValue NE Text then
    Send_Event(CtrlEntId, 'LOSTFOCUS')
end

Locking records on databound forms

Comments