I am just learning OI. Lots of fun! I have an extensive system in Arev 3.12 and am trying to migrate the system to OI. Symbolics in Arev calculate on @record and in IO, I want them to calculate on the 'TEXT' property of the control. Is there any way to make the Symbolic respond to which system it is operating in so that I do not need a seperate Symbolic, or should I just create a new Symbolic for OI?

L-

You can try having your symbolics call a subroutine which has the IFDEF logic init. Search on IFDEF in this forum to see answers from Cameron Purdy and Andrew McAuley posted previously.

Hope it helps-

Mike Ruane

WinWin Solutions Inc.

WWW.WinWinSol.Com

Can you post an example of your AREV symbolics? Normally one should never create a symbolic that operates on the property of a control, especially because this symbolic would be useless in a report. I just want to make sure there is a compelling reason for approaching your symbolics this way.

If so, you can do as Mike suggested. Personally, especially if I was just learning OI, I would create a second symbolic for simplicity. The downside is having to maintain two symbolics (assuming your AREV application will continue to be supported) instead of one.

[email protected]

SRP Computer Solutions

A simple example of my problem is, I am using a Symbolic in an Arev Window. It is set in a GMV Data Set of Address, CityState, ZipCode. I Have a second Table, not attached to the Window that contains:

@id =ZipCode

@record=City, State (Text)

The Symbolic works (Slick as a whistle) to Display the CiyState from the ZIP Table based on the ZipCode data that I enter in the GMV.

@ans=xlate('ZIP', @record, 1, 'X')

In OI, trying to duplicate the same process I have to use the following logic in the "Calculated Column". It works to display the MultiValue Data in an Edit Table, but is clumsey as it calculates off of @record rather than using the 'TEXT' property from the corresponding "ZipCode" control so it does not update as it should as ZipCode data is Changed.

equ null$ to ''

CityState=null$

ZipCodes=@record ;* Should use Get_Property()

convert @vm to @fm in ZipCodes

nz=fieldcount(ZipCodes, @fm)

for j=1 to nz

CityState=xlate('ZIP',ZipCodes, 1, 'X')

next j

@ans=CityState ;* Should use Set_Property()

It appears that "@mv" does not work the same in OI as it does in Arev.

Since I posted my original question, I have experimented with displaying the same data in a Column in my OI Edit Table that is not associated with any database. I can then manipulate and display the data through the same Stored Proceedure that I am using to operate the rest of the Window. I seem to like this approach better and do not use the Arev Symbolic at all in OI.

Am I on the right track?

Thanks for the help.

Larry Deibel

Larry,

You are right in that @MV does not work as well as it does in AREV. This makes it necessary to write symbolic code the way you did.

Now let me make sure I understand what else you are saying. The longer code you posted works in OI, correct? But did you also say that it doesn't work when you change a ZipCode, that is, it doesn't seem to trigger a change in the symbolic? This ought to work since you are referencing @RECORD which allows the dependencies to be correctly determined. How are you changing the values in the ZipCode column? Are you manually changing them or programmatically changing them? If you are programmatically changing them then you should use the DEFPROP or INVALUE property so the underlying database column gets updated and you might also need to send a CALCULATED event to the edittable with the symbolic.

[email protected]

SRP Computer Solutions

Don,

Yes, the second Symbolic does update properly in OI! I am imputing data (driving the Symbolic) manually and it works well. I am amazed at the extra code I need in OI to do what I could do so simply in Arev and I do not like haveing duplicate Symbolics. I see a lot more horsepower available in OI than Arev. I have written so many versions of this Symbolic that I lost track of which ones work and which ones do not. Sorry!

I have an extensive Auto Dealer System in Arev that I intend to convert to OI. I want to establish some basic organizational techniques to keep the system coherent as I convert it. I consider a little extra time spent schooling at the beginning of the project should pay off in the finished product and probably save time overall.

I am using a few Windows (or Forms) as well as some reports and print jobs and am working and reworking them to see what works the best for me, before I plunge into the full project. I am leaning toward the elimination of most Symbolics and Event User Code in favor of calling logic in a Stored Procedure form the QuickEvent Handler. This seems to put most of my logic for a Form in a single place that I can edit and digest more easily and eliminates some repetitious coding. It also seems to run a little faster in the Form.

I fear I am reverting to my Arev programming techniques, but it does work. Is this a bad habit to get into? I know this technique bypasses some of the Chain of Event Processing capabilities of OI. I see a lot of sample code that seems to have been written using this technique. What would you suggest?

Thanks for your help!

Larry Deibel

Larry,

You say you use quickevents and stored procedures and have most form logic in a single place. That's generally a good thing. Some of us do this the following way:

Let's say you have a window XXXX with a couple of pushbuttons B1 and B2 and a couple of edit controls E1 and E2. Let's say you need event handling for the following:

- window CREATE

- button CLICKs

- GOTFOCUS for E1

- some special character checking and handling while the user keys data into E1 (CHAR event).

Then make a function Xxxx with the following structure:

function Xxxx( Event, CtrlEntID, Param1, Param2, Param3, Param4, Param5, Param6, Param7 )

. $insert Logical

. begin case

. case Event=CREATE"

. . CreateParam=Param1

. . (code for CREATE event)

. case Event=CLICK"

. . begin case

. . case CtrlEntID=@Window : ".B1"

. . . (code for pushbutton B1)

. . case CtrlEntID=@Window : ".B2"

. . . (code for pushbutton B2)

. . case true$

. . . debug

. . end case

. case Event=GOTFOCUS"

. . begin case

. . case CtrlEntID=@Window : ".E1"

. . . (code for GOTFOCUS event of edit control E1)

. . case true$

. . . debug

. . end case

. case Event=CHAR"

. . begin case

. . case CtrlEntID=@Window : ".E1"

. . . VirtCode=Param1

. . . ScanCode=Param2

. . . Ctrl=Param3

. . . Shift=Param4

. . .*STPROCEXE**XXXX

(- Message: EXECUTE)

- Parameters: see below.

The quickevent parameters depend on the event. For the ones in my example use:

'CREATE','@SELF','@PARAM1'

'CLICK','@SELF'

'CHAR','@SELF','@PARAM1','@PARAM2','@PARAM3','@PARAM4','@PARAM5'

To find out how many @PARAM… parameters you need, and what they mean, you can check with the user event editor, or the help docs.

I assume this way to do it qualifies as a commuter module. I never used commuter modules in my Arev days, and it's a fairly new term to me.

- Oystein -

Øystein Reigem,

Humanities Information Technologies,

Allégt 27,

N-5007 Bergen,

Norway.

Tel: +47 55 58 32 42.

Fax: +47 55 58 94 70.

[email protected]

Home tel/fax: +47 56 14 06 11.

Larry,

Your approach is just fine. You are correct that many of us (including our developers) use this technique for coding all form related logic. Hey, if it was good for AREV it should be good for OI as well. Overall it sounds like you are taking a good approach.

Just allow yourself to be a little flexible. There were be times when calling your logic from a QuickEvent won't be adequate because by the time the QuickEvent calls your code it will be too late. For instance, in AREV you could abort the saving of a row in a pre-save row process (WC_VALID%=False$). In OI, however, since the system's WRITE logic takes place before your QuickEvent call, any code you call from the QuickEvent effectively works like a post-save process instead…i.e. the record as already been written. In these situations you need to use the event script. You would then Return a 0 to prevent the writing of your row. Of course, your event script can also make a call to your stored procedure commuter module thereby still keeping most of your code in one place.

When you think you have a really good handle on the above then you might want to look into Promoted Events for maximum efficiency in your code. It might be a little heavy to discuss this topic now, but if you are interested then do a website search for Promoted Events. I'm sure you will find many posts. If you have any more questions after that then please ask them.

[email protected]

SRP Computer Solutions

Don,

Thanks for you ?INSIGHT?:ful comments! I will need to remain flexible. I wish I had a little more of the understanding of OI that it is evident you have. I?m sure I will be calling on you and your expertise in the near future.

Larry Deibel

Deibel Jeep

2608 N. West Street

Flagstaff, AZ 86004-3421

Oystein,

Thanks a lot for your time and effort! The sample code offers a lot of help. I am sure you will hear from me again soon.

Larry Deibel

Deibel Jeep

2608 N. West Street

Flagstaff, AZ USA 86004-3421

I know I am running the risk of sounding like a commercial, but since you are in Arizona we might be able to offer direct assistance if you need it. We are in Southern California.

[email protected]

SRP Computer Solutions

Larry,

You're welcome!

As a bonus here are some more commuter quickevent parameter sets - to save you some keying. These events are the ones I have used myself so far. Keep them available somewhere so you can copy and paste when you define quickevents.

For each event there's also a hint to what the individual parameters mean - taken from the user event editor.

Good luck!

- Oystein -

'BUTTONUP','@SELF','@PARAM1','@PARAM2','@PARAM3','@PARAM4','@PARAM5','@PARAM6','@PARAM7'

1=xDown

2=yDown

3=xUp

4=yUp

'CHANGED','@SELF','@PARAM1'

1=NewData

'CHAR','@SELF','@PARAM1','@PARAM2','@PARAM3','@PARAM4','@PARAM5'

1=virtcode

2=scancode

3=ctrl

4=shift

5=alt

'CLEAR','@SELF','@PARAM1','@PARAM2','@PARAM3'

1=bsavekey

2=bsuppresswarning

3=bmaintainfocus

'CLICK','@SELF'

'CLOSE','@SELF','@PARAM1'

1=CancelFlag, hva nå der er for noe!!!???

'CREATE','@SELF','@PARAM1'

1=CreateParam

'DBLCLK','@SELF','@PARAM1','@PARAM2','@PARAM3'

1=CtrlKey

2=ShiftKey

3=MouseButton

'DELETE','@SELF'

'GOTFOCUS','@SELF','@PARAM1'

1=PrevFocusID

'LOSTFOCUS','@SELF','@PARAM1'

1=Flag

2=FocusID

'OMNIEVENT','@SELF','@PARAM1','@PARAM2','@PARAM3','@PARAM4','@PARAM5'

1=Message

2=Param1

3=Param2

4=Param3

5=Param4

'OPTIONS','@SELF'

'PAGE','@SELF','@PARAM1'

1=PageAction

'READ','@SELF'

'SIZE','@SELF','@PARAM1','@PARAM2','@PARAM3','@PARAM4'

1=x

2=y

3=Width

4=Height

'WINMSG','@SELF','@PARAM1','@PARAM2','@PARAM3','@PARAM4'

1=hWnd

2=Message

3=wParam

4=lParam

'WRITE','@SELF'

View this thread on the forum...