I'm creating a UDC that will be added to a MV column. However, the validation rules will vary based on position in the column. It would appear that @MV is not set so I cannot determine which position the user is currently entering data in.

Is there a solution that I'm overlooking or should I just move this into an event handler?

Don Bakke

SRP Computer Solutions, Inc.

AFAIK OpenInsight only sets @MV with the select cursor (somewhere in Cursor.IO / External sort), so you will need to determin the MV position in code.

FWIW, I often route user defined conversions through the commuter module. I then put a call to the commuter module plus the control name in the valid property.. This lets me use get_property to get the selpos, and test the value of other controls for complex validations. If you set status() to invalid then the control does not fire changed/poschanged, so I don't have to backtrack. In effect, I create a "validation event". OI10 has a cellchanged event which accompllishes similar effects.

The validation property look like

[MYWINDOW_EVENTS,MYCONTROL]

The top of my commuter module looks like

Begin Case

          Case CtrlEntId _eqc 'ICONV'   ; Gosub onIconv

          Case CtrlEntId _eqc 'OCONV'   ; Gosub onOconv

          ....

The onInconv section looks like below.

onIconv:

     //parms are ( CONV, ANS, BRANCH, RETURN_DATA)

     winName = @window

     ans    = If Assigned(event) Then event Else null$

     branch = If Assigned(P1) Then p1 Else null$

     p2     = ans ; * return data



     status() = valid$



     Begin Case

          Case ans = null$

               * do nothing

          Case branch == "ACCT_TYPE"



               * See if this part of the key is ok



               * We loaded a list of the valid types in the create event

               valid_types = Get_Property(WinName, udp_valid_acct_Types$)



               If inlist( valid_types, ans, @fm) Then



                    * this piece is ok, do we have the whole account

                    acct_Type = ans

                    acct = .Acct->text

                    link = .Link->text

                    Gosub validate_account_key



               End Else



                    entry_error = quote(ans) :" is Not a valid  acct type"

                    Gosub onValidationError

                    .acct_Type->Focus = true$



               End

              ...

AFAIK OpenInsight only sets @MV with the select cursor (somewhere in Cursor.IO / External sort), so you will need to determin the MV position in code.

Hi Bob. Thanks for the advice. My UDC already calls a commuter…albeit a non-form commuter. Your implementation keeps the UDC but manages the code in the form commuter, which is clever.

However, I was really hoping to avoid any form based logic in my UDC (or any extended logic it might call). I am a proponent that UDCs be completely table/record dependent.

However, if I have no way of getting the position then I'm forced to rely upon the form anyway, so I'll give your implementation a go. It shouldn't be too difficult to extend my logic to call a form commuter in addition to my non-form commuter as needed.

Don Bakke

SRP Computer Solutions, Inc.

Don,

Quick FYI - the next version of v10 has @MV tracking re-implemented so it will be valid in UDCs and the CALCULATE event:

GOTFOCUS/POSCHANGED events

[list]

  updates @mv based on current row-position for EditTables, or null for other controls.

[/list]

LOSTFOCUS event

[list]

  sets @mv to the row being validated, ensures this is set before any calls to iconv/oconv so it can be picked up in UDCs

  sets @mv to the row being validated for a recalc on a col in the [i]same[/i] EditTable

  sets @mv to "" for a recalc on a [i]different[/i] control

  restores original @mv

[/list]

CALCULATE event

[list]

  if @mv is set uses that for calls to calculate

  if @mv is set uses that for the oconv after calculate (for UDC)

  sets @mv to the same value for a recalc on a col in the [i]same[/i] EditTable

  sets @mv to "" for a recalc on a [i]different[/i] control

  restores original @mv

[/list]

The VALID/CONV property is also being expanded to accept "@" tokens like @COMMUTER and @EVENT so, for example you can just write "[@COMMUTER,@SELF]" for a UDC.

The default (DefValue) property also supports "@" tokens.

Carl Pates

Don,

Quick FYI - the next version of v10 has @MV tracking re-implemented so it will be valid in UDCs and the CALCULATE event…

These all look like very nice enhancements.

For v9, do you think this would work:

• Set the CHANGED event handler to be synchronous for my edit table controls via a promoted CREATE event.
• Create a promoted CHANGED event handler that sets @MV properly.
• Now I can write my UDC to be dependent upon @MV.

Don Bakke

SRP Computer Solutions, Inc.

I agree that the validation rules should bind to the data ( the model ) rather than the form (the view )

I think if using the udc syntax to call the commuter as creating as a workaround to create a pseudo 'validation' event. In your case you would then have the commuter set @mv and call your real UDC. Thank';s to Carl's changes, the next release of 10 the form designer will accept [@commuter,@self] as a validation token to more clearly specify what is happening.

If your technique works it will certainly be cleaner than my workaround.

View this thread on the Works forum...