Hello all -

A 'call forward_event()' has all of a sudden stopped working in our code and we cannot figure out why. A 'send_event(ctrlentid,"LOSTFOCUS")' in the same spot seems to replicate the lost functionality though. Any caveats to simply using send_event instead of forward_event?

TIA,

Mike O.

Mike,

I assume your Forward_Event was called from within the script LOSTFOCUS event, correct? If that is the case, then calling Send_Event from the same code would likely put your LOSTFOCUS event into a infinite loop unless you added some special flags to prevent this.

Can you give a bit more detail on what you are trying to accomplish? Specifically, what was the purpose of the Forward_Event? Normally, one puts a Forward_Event in the script handler so that pre and post processing can be managed in one place. Is this what you are trying to do?

[email protected]

SRP Computer Solutions, Inc.

Hi Don -

Yes, the forward_event is coded within a LOSTFOCUS event, which is being called from a key field. In a nutshell, we are returning a record key to the key field, doing some other things, then forcing a lostfocus to trigger a read of the record. The forward_event in this part of the code has worked fine for almost three years until recently. The send_event at first glance seems O.K. (no loop0, but still trying to determine any other implications.

Regards,

Mike

Mike,

What is the status after the Forward_Event? If you check for the status it should give you more information on any failure to process the event.

Set_EventStatus(0)

call Forward_Event()

result=Get_EventStatus(errCodes)

if result then

call FSMsg(errCodes)

end

Sean

Hi Sean -

I checked this, the status is 0 (no error).

Mike

Mike

Did you do something with the read event?

Try a debug there, see if indeed it is firing, but the read is not occurring.

Bob

Hi Bob -

After putting in a debug, READ is not firing with the forward_event but it is firing if I change it to a send_event(ctrlentid,"LOSTFOCUS")

Mike

Mike,

My next suggestions would have been what Sean and Bob have made. Virtually every scenario I can think of to explain why your Forward_Event isn't working would also prevent your Send_Event from working as well.

Did you modify the code that returns the key and populate the control? Just prior to calling Forward_Event, are the values of the GOTFOCUS_VALUE and TEXT properties for CtrlEntId different? It sounds like you are implementing some kind of search feature. Does this problem happen with every possible key that would be returned? What happens if you remove the script event (temporarily) and manually enter a new key, does the READ event fire? Did you add or modify a promoted LOSTFOCUS and/or READ event recently?

Bottom line: even though Send_Event might be working for you, I wouldn't settle for this as a solution…especially if it was working for you before. It definitely sounds like there is a problem and you don't want to leave this unresolved.

[email protected]

SRP Computer Solutions, Inc.

This is the script I normally use in the OPTIONS event of the record key control on databound forms where rkey is obtained from a popup or a "commuter" module call:

---

if len(rkey) then

@CTRLENTID-]FOCUS=1

@CTRLENTID-]TEXT=rkey

call Send_Event(@WINDOW,'READ')

CALL SEND_EVENT(CTRLENTID,'LOSTFOCUS')

end

return 0

---

This script will usually work without the SEND_EVENT(@WINDOW,'READ') but I added it to make it 100% reliable. The OPTIONS event is triggered either from a button on the form or from an accelerator key from the MDI frame. Since clicking the button sets the focus to the button, focus must be set back to the record key control

Just so we understand this,

You have a LOSTFOCUS script (not a quick-event) and in that script, you issue a LOSTFOCUS send_event to itself?

The Sprezzatura Group

World Leaders in all Things RevSoft

Hello Sprezz -

We have a quick event from the key field coded as follows:

return Function(do_event CtrlentId,'LOSTFOCUS',Flag,FocusId,'SBFK'))

The SBFK flag runs a program that retrieves a record based on user input (usually a text string) at the key field. We find the record key, then check a few things (is it a multi-key field? more than one key returned?) If a single key is returned into a single-value key field, we then do a call forward_event(), which *used* to trigger a lostfocus and read the record in the window.

Mike

FWIW I avoid sending read from a prompt.

I think of it as the window's job to know when to to read, not the prompt's job. I have seen cases where the write logic gets confused, so that it offers to save your changes but saves nothing instead. If I set DEFPROP and send Lostfocus, I always get the correct behaviour, key prompt or non-key prompt. Other than that, my standard snippet is the same as Warren's.

* Like as S= in Arev?

val=MyFunction()

if len(val) then

 @CtrlEntId-]Focus=1

 @CtrlEntID-]DefProp=val

 Call Send_Event(CtrlEntId, 'LOSTFOCUS')

 NextCtrl=@CtrlEntId-]Next

 @NextCtrl-]Focus=1

end

Mike

I ran into the same problem the other day. I found a promoted event on the application lostfocus that I did not create. When I removed it and recompiled the window it worked fine.

A quick event off of what event?

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Hi Bob -

We have two specific promoted events, LOSTFOCUS and GOTFOCUS for EDITFIELDS, which we have had for years. I checked this with the command:

select sysreposeventexes ending "oiwin*"

Mike

Off the lostfocus event.

What we THINK you are describing is

pre.code {

  background-color: #E5E5E5;

  border: 1px solid #000000;

  width: 650px;

  padding: 5px;

  font-family: courier, verdana, arial, serif;

  margin: 0px 10px auto;

}

   Lostfocus event triggers
      System runs your promoted lostfocus event
      System runs through its' lostfocus routines
         System calls QuickEvent
            QuickEvent calls your program Do_Event
              Do_Event does some logic

Have you ensured that the promoted lostfocus is returning 1? What does Do_Event do? Does it send any events?

The Sprezzatura Group

World leaders in all things RevSoft

Hi Sprezz (and all) - here's a new-found twist:

As a user is logging in we run a CALL INITIALIZE to run a program from position 32 in a SYSENV record to deal with station id's in a citrix environment.

When this CALL INITIALIZE statement is remmed out, the previously malfunctioning forward_event() comes back to life and records can then successfully be read into entry windows. If we issue the CALL INITIALIZE statement, but then remove the program we are calling from position 32, the forward_event() fails again. The success or failure of the forward_event() seems to be explicitly related to whether we issue a CALL INITIALIZE, regardless of whether we have anything on line 32 of the SYSENV record.

So… I think the question is why would a CALL INITIALIZE affect a forward_event()?

I'll have to give this a try. I think the DEFPROP vs TEXT probably makes the difference. My script without the READ event started acting flakey at some point so I added the READ event.

I think I played around with setting the focus to the next control but that usually took me back to the associated "Option" button or did odd things on multipage forms or if navigating via mouse clicks that I gave up on it :)

Mike,

OI's event handling relies on various pieces of information kept in global variables (like the event stack). It's quite possible that Initialize() nulls these out (it is the system initialization routine after all ;), thereby losing the necessary info for event forwarding.

The Sprezzatura Group

World leaders in all things RevSoft

Thanks Sprezz -

The call initialize() only happens once, as a user is logging in. The forward_event gets called over-and-over again though, which I would think would be enough to reinitialize it? And replacing it with a send_event(LOSTFOCUS) doesn't spin into a loop.

View this thread on the Works forum...