Hello again,

There's got to be something simple (?) I'm missing here, maybe those of you with more OI experience can shed some light.

Here's the current problem (OI development version 3.61.):

I am developing an OI based Human Resource Information System (HRIS).

I have a form bound to a database table. The user either enters the key directly into a drop down combo box, or chooses the key from an index lookup that is called when the user clicks the dropdown arrow. So far so good. However, BEFORE the controls on the form are populated with data, I want to trap the key value (don't need the rest of the record) in a stored procedure to check to see if the user has access to the specific record (as reflected in a custom OI security table).

I've coded the procedure, but no matter where I hook it, it DOES NOT execute until AFTER the data is presented in the panel (i.e. too late). I have tried hooking it to the window's READ event and the key field's LOSTFOCUS and CHANGED events. In all cases, the procedure runs fine - AFTER the data is populated.

I discovered that the same code placed in a LOSTFOCUS quick event script on the key field works just fine. However, I have many forms that will use this code, and would prefer to call it generically from a stored procedure.

I have read some of the postings here and the OI documentation that suggest using SEND_EVENT to simulate AREVs pre/post read processing - but I have not found the example code clear enough on how to implement (i.e., substitute my READ processing for window READ…). Is this what's required here? I have browsed the WORKSHOP/CUSTOMER/EXAMPLES applications but did not run into anything similar enough.

Thanks in advance for any and all help with this.

Gene Sorbo

Employee Management Systems

gsorbo@ziplink.net

Gene:

In my READ event I have:

]DECLARE SUBROUTINE EMPLOYEE_BMP,AUDTRAIL, CHECK_ACCESS

]DECLARE SUBROUTINE FORWARD_EVENT

]DECLARE SUBROUTINE SET_EXEMPT_VIS

]declare function msg,SET_PROPERTY,GET_PROPERTY,SEND_EVENT,REPOSITORY

]WINDOW_NAME=CtrlEntID1,'F.'

]Forward_Event()

]CALL AUDTRAIL(CtrlEntID,CtrlClassID,"R")

]ACCESS='

]CALL CHECK_ACCESS(CtrlEntID,CtrlClassID,ACCESS,S_S_N_ID)IF ACCESS=2 THEN

] retValue=REPOSITORY('EXECUTE', ]'TEST_APP*OIWINEMPLOY_1_INFO',S_S_N_ID ) ]END Note that in the CHECK_ACCESS subroutine I have: ]IF ALLOW_CHECK=0 THEN ] VOID=SEND_EVENT(@WINDOW,"CLEAR") EMPLOYEES",S_S_N_ID,2,"X") ] AGENCY_DESC=XLATE("AGENCY_CODES",AGENCY_LOC,1,"X") ] GOSUB DisplayMSG Note that I immediately CLEAR the window if the person does not have access to the information. I then open a substitute form that allows no editing and more security. Hope this helps… Steve C. </QUOTE> —- === At 23 FEB 1999 04:50PM Gene Sorbo wrote: === <QUOTE>Steve, From what control are you calling the stored procedure from (READ event of the entry form/window)? Does what I stated in my previous message about the quick event processing while the stored procedure does not make sense to you? Thanks. Gene </QUOTE> —- === At 23 FEB 1999 04:59PM Steve C. wrote: === <QUOTE>Gene, ]From what control are you calling the stored procedure from (READ ]event of the entry form/window)? YES, I'M CALLING IT FROM THE FORM'S/WINDOW'S "READ" EVENT. Does what I stated in my previous message about the quick event processing while the stored procedure does not make sense to you? YES, MY PROGRAM ALSO READS THE RECORD AND POPULATES THE FORM… BUT MY SUBROUTINE I CALL AFTER THE "FORWARD_EVENT()" "CLEARS" THE FORM QUICKLY IF THE PERSON IS NOT ALLOWED ACCESS. . . Steve C. </QUOTE> —- === At 23 FEB 1999 06:01PM Tony Lillyman wrote: === <QUOTE>Guys, What I generally do with READs on Bound Forms is I put my event code as a LostFocus on the Key Control If the key passes whatever tests I want to impose then I return "1" from the event passing control to the next event (normally the READ) If it fails my tests, in your case a security check, Set the Focus back to the KEY Control with Set_Property() and then return "0" (zero) from your event code. Hope this is what you are looking for. Regards Tony this will stop the event processing. </QUOTE> —- === At 23 FEB 1999 06:25PM Gene Sorbo wrote: === <QUOTE>Tony, I assume you store the code in a quick event script vs a stored procedure? Gene </QUOTE> —- === At 23 FEB 1999 06:55PM dsig@teleport.com wrote: === <QUOTE> as seen in the works section Gene, ]]]I discovered that the same code placed in a LOSTFOCUS quick event script on the key field works just fine. However, I have many forms that will use this code, and would prefer to call it generically from a stored procedure. To me the LostFocus event is the best place to put this code. If you want to make your routine into a stored procedure great. Write your routine as a function then execute it from the key of your controls. In Lostfocus Event .. Declare Subroutine Forward_Event Declare Function SecurityFunction If SecurityFunction(pass what you need) Then Forward_Event(Flag,FocusId) End Return 0 By having your RETURN 0 then the forward event will continue processing if your 'securityfunction' return true. We have a subroutine in each of our Got/Lost focus events which performs a specific function for every control and then branches as needed for special processing. Does this hit what you need? If not could you further define why you don't want to use the LostFocus Event. dsig@teleport.com onmouseover=window.status=you have seen the rest .. now try the best!;return(true)" David Tod Sigafoos ~ SigSolutions voice: 503-639-8080 </QUOTE> —- === At 23 FEB 1999 06:57PM dsig@teleport.com wrote: === <QUOTE>Steve, Do you set property REDRAW to false before the read? If not don't you get flicker on the screen? dsig@teleport.com onmouseover=window.status=you have seen the rest .. now try the best!;return(true)" David Tod Sigafoos ~ SigSolutions voice: 503-639-8080 </QUOTE> —- === At 23 FEB 1999 09:41PM Dave Pociu wrote: === <QUOTE>Hi Gene, If you're going to use this on a consistent basis in multiple forms I would hook it to the READ event. If you will use it in EVERY window in your app, I would put the code as a promoted READ event that executes every time a READ is issued. I do something similar in my apps, however I do it on WRITE and CREATE events of every window. Assuming you're only going to do this for selected windows, here's how it would work in your case: Assume the name of the window is WIN1. I normally create a subroutine called WIN1 that handles all the code for the window. In the READ event of your window: call win1( "READ" , CtrlEntId ) return 0 ;* ) end case return ; main subroutine return statement

Read:

if CheckPermission(…) then

 forward_event()  ;** actually do the read

end else

 msg( @window , "You don't have permission to access that record!!!")

end

return

Hope this answers your question… Let me know if you need more help

Dave Pociu

d.pociu@snet.net

If READ is denied, you'll probably also want to send a CLEAR event to the window, so anything the user entered gets cleared.

I also just realized that my grammar is not exactly perfect in the previous posting… I's sorry

Dave

David,

No, my screen/ form does not "flicker" and I don't

use REDRAW. The form does fill with info. but is

quickly CLEARed and I popup a message box so the

user has a choice to see the information available to

them in a more secure form. This may not be acceptable

if you are selling you application, but mine is for

in-house use only and is still very adequate and user

friendly…I get to tease them with the info… then

poof… I take it away.

Steve C.

Dave,

Thanks for the info - works great on the window READ event when called from a script as well.

I agree, it makes more sense to have it there than on the key field's lostfocus.

Thanks.

Gene

It's late, and I've been answering things for hours, so I didn't read throught the whole thread, so appologies if this has been answered already, but you have two options.

Option one is to place code in the actual event handler, not on a quick event. The event handler is essentially a pre-read. You'll have to set Return True$ to finish the read or Return False$ to abort.

Option two is almost the same, but more generic. Check out an old SENL where Andrew talks about promoted events.

akaplan@sprezzatura.com

Sprezzatura, Inc.

View this thread on the forum...