Could someone give me some advice?

My table processing is getting a bit complicated!

In GOTFOCUS I fire the POSCHANGED event to set the cursor position and

take a copy of the table to MISC property, in case of reseting some

values/rows to its previous value (also done in INSERTROW, DELETEROW).

In the CHANGED event I'm using PREVSELPOS to handle previous cell processing.

The first function within a change manually checks validation since ordinarily

it is down the chain. In case the user makes a single change then moves to

another field, the PREVSELPOS is dependent on the current focus, ie.

if different to the table then SELPOS is used.

I'm using POSCHANGED to set the cursor position and RETURN 1 to do conversion.

This is working ok, but seems congested? One brilliant thing about OI is its

flexibility, but in this case I'd be interested in how I'm SUPPOSED to be doing

it!

Finally, the one instance I haven't got working is should the user make a single

change, then immediately save (my focus check obviously doesn't work so CHANGED is

looking at PREVSELPOS and nothing updates), so what I was hoping to do was to set the

PREVSELPOS variable to SELPOS on the firing of the LOSTFOCUS event, so the CHANGED

event processes correctly. (I guess I could (should?) recode the CHANGED event in

GOTFOCUS, so is there a way to know the current event being processed?)

2. Incidently, why is the validation performed after any scripting? Can I FORWARD_EVENT

just the validation and conversion first thing in the CHANGED, rather than my manual check.

I'd appreciate any ideas, or ways other people are handling tables!

Regards,

Chris.

Chris,

I am not sure if this answers your question, but here is how I usually handle what I think you are asking about:

1) On GOTFOCUS and I fake a POSCHANGED so that my POSCHANGED always is notified when entering a cell:

<code>
* GotFocus
declare subroutine Send_Event, Forward_Event
declare function Get_Property

Forward_Event(PrevFocusID)

Pos=Get_Property(CtrlEntID, "SELPOS")
Send_Event(CtrlEntID, "POSCHANGED", Pos, Pos)

return 0

</code>

2) On LOSTFOCUS and I fake a POSCHANGED so that my POSCHANGED always is notified when leaving a cell:

<code>
* LostFocus
declare subroutine Send_Event

* next column/row are zero to signify lost-focus
Send_Event(CtrlEntID, "POSCHANGED", 0, 0)

return 1

</code>

3) On POSCHANGED, I check the new position, only act if it is different from the old position, and store the new position.

<code>
* PosChanged
declare subroutine Set_Property, Forward_Event
declare function Get_Property

CurPos =NextColumn: @fm: NextRow
PrevPos=Get_Property(CtrlEntID, "@PREVPOS")
if CurPos # PrevPos then
  if PrevPos and PrevPos then
    * do leaving cell processing here
    * ...
  end

  if CurPos and CurPos then
    * do entering cell processing here
    * ...

    * update last-processed position
    Set_Property(CtrlEntID, "@PREVPOS", CurPos)
  end
end

if NextColumn and NextRow then
  Forward_Event(NextColumn, NextRow)
end

return 0

</code>

Hope it helps,

Cameron Purdy

Revelation Software

Thanks muchly Cameron,

I certain this is exactly what I'm after.

Chris.

Thanks again Cameron for the sample code - that @PREVPOS property is exactly what I was after.

1. I am running OI3.4 but couldn't find @PREVPOS documented, so I'd just like to make sure its logic won't be changed before I implement it everywhere?

2. As a matter of interest, do you do ALL your cell processing within POSCHANGED and manually check a value change? I've been using CHANGED within tables, and it seems fairly efficient. Is using POSCHANGED a better way?

3. On leaving a table normally, CHANGED fires and with @PREVPOS all goes well. On a WRITE however, the LOSTFOCUS fires but not the CHANGED - hence I can code it, but that means it will fire TWICE normally on every ocassion except a WRITE (ie. CHANGED fires before LOSTFOCUS, then again because of my code), which leads to my next question:

Is there a way to check the events currently queued? eg. if the user saves and the LOSTFOCUS event fires, can I know that the WRITE event is being processed? Or maybe I'm way off-base here?

Thanks again for any input,

Chris.

Chris

1. I am running OI3.4 but couldn't find @PREVPOS documented, so I'd just like to make sure its logic won't be changed before I implement it everywhere?

PMFJI, but @PREVPOS is not a property per se, but a custom property that Cameron defined. One of the coolest features of OI is the ability to define your own property for any control just by prepending the "@" symbol before the name.

So, while PREVPOS may one day become an official property it won't be called @PREVPOS so you won't need to worry about it. BTW, this is why Cameron also had to manually update the contents of this property since a true property would have updated itself.

dbakke@srpcs.com

SRP Computer Solutions

Chris,

1. I am running OI3.4 but couldn't find @PREVPOS documented, so I'd just like to make sure its logic won't be changed before I implement it everywhere?

As Don said, I just made the property up by prefixing it with "@". Similarly, you could add another property called "@PREVDATA" which you set on cell entry to the INVALUE from the cell and check on cell exit for comparison to see if the cell changed.

2. As a matter of interest, do you do ALL your cell processing within POSCHANGED and manually check a value change? I've been using CHANGED within tables, and it seems fairly efficient. Is using POSCHANGED a better way?

Yes, I do all my processing on POSCHANGED. I believe it is a preference, not a necessity, but I can't say for sure why it is better because it is all I do.

3. On leaving a table normally, CHANGED fires and with @PREVPOS all goes well. On a WRITE however, the LOSTFOCUS fires but not the CHANGED - hence I can code it, but that means it will fire TWICE normally on every ocassion except a WRITE (ie. CHANGED fires before LOSTFOCUS, then again because of my code)

Combine the "@PREVDATA" from answer #1 with answer #2 and you won't have that problem.

Is there a way to check the events currently queued? eg. if the user saves and the LOSTFOCUS event fires, can I know that the WRITE event is being processed? Or maybe I'm way off-base here?

You are way off base … your processing should not rely on what triggered an event. That said, there will be times to break the rule but do everything you can to avoid having to know.

Cameron Purdy

Revelation Software

Thanks again,

Using those definable variables works perfectly (so far!) in all situations that I've tested. What a brilliant concept these @properties are.

I probably (definitely!) should have noticed that the @properties were being defined, but at the time I was overcome with enthusiasm and chucked some code in my validation and then got all excited when I saw it updating!

Thanks again.

Chris

View this thread on the forum...