{{tag>category:"OpenInsight 32-bit" author:"Donald Bakke" author:"bob carten" author:"Carl Pates"}} [[https://www.revelation.com/the-works|Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community]] ==== UDC and MV Position (OpenInsight 32-bit) ==== === At 21 DEC 2020 02:27:58AM Donald Bakke wrote: === 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? [url=mailto:dbakke@srpcs.com]Don Bakke[/url] [url=http://www.srpcs.com]SRP Computer Solutions, Inc.[/url] ---- === At 21 DEC 2020 11:46AM bob carten wrote: === 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 ... ---- === At 21 DEC 2020 12:11PM Donald Bakke wrote: === 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. [url=mailto:dbakke@srpcs.com]Don Bakke[/url] [url=http://www.srpcs.com]SRP Computer Solutions, Inc.[/url] ---- === At 21 DEC 2020 01:26PM Carl Pates wrote: === 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. [email=cpates@revsoft.co.uk]Carl Pates[/email] ---- === At 23 DEC 2020 10:48AM Donald Bakke wrote: === 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: [list] [*] 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. [/list] [url=mailto:dbakke@srpcs.com]Don Bakke[/url] [url=http://www.srpcs.com]SRP Computer Solutions, Inc.[/url] ---- === At 23 DEC 2020 11:09AM bob carten wrote: === 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. [[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&SUMMARY=1&KEY=DE0F8298CE0B5B4CB395E93E74ADE6CF|View this thread on the Works forum...]]