Event Processing - which will come first (OpenInsight 32-Bit) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
{{tag>category:"OpenInsight 32-Bit" author:"Martin Drenovac" author:"dsig@sigafoos.org" author:"[url=http://www.srpcs.com]SRP[/url]'s Kevin Fournier" author:"dbakke@srpcs.com's Don Bakke"}}

[[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]]


==== Event Processing - which will come first (OpenInsight 32-Bit) ====
=== At 20 SEP 2007 06:46:54AM Martin Drenovac wrote: ===
 
 
<QUOTE>
Scene -  have a form with a control, defined as 'validate for numeric'.

I also implement / catch promoted events, lostfocus lets say or changed.



Which will happen first, the control's own internal validation against numeric or the raising of the promoted event, followed by the numeric validation? If the promoted event is first and I undetake to do the validation, do I return a 0 to stop the cascade into the controls own validation?


</QUOTE>
----

=== At 20 SEP 2007 09:06AM dsig@sigafoos.org wrote:  ===

<QUOTE>The promoted processing should always happen first.  Though I havent tested this specific scenerio i would go with it.



What you might want to do is create a test window with promoted event shell which simply displays information in the status "here" or some such.  Then when you have a question like this you can simply test it

</QUOTE>

----

=== At 20 SEP 2007 10:52AM [url=http://www.srpcs.com]SRP[/url]'s Kevin Fournier wrote:  ===

<QUOTE>Martin,



If it helps, we have a white paper on [url=http://www.srpcs.com/articles/Promoted_Events.pdf]Promoted Events[/url], including a very thorough discussion on the event change.



kfournier@srpcs.com

[url=http://www.srpcs.com]SRP Computer Solutions, Inc.[/url]



[img]http://www.srpcs.com/srpicon1.gif[/img]

</QUOTE>

----

=== At 20 SEP 2007 05:35PM dbakke@srpcs.com's Don Bakke wrote:  ===

<QUOTE>Martin,



In addition to the advice Kevin gave for reading the white paper, you really need to understand where in the event chain validation gets called. This is easy to figure out by debugging a UDC. By playing with the SSN_FORMAT I get the following:



 
   
<code>
  
  
  
  
  
  [/color][/size]     
<code>
SSN_FORMAT 
RTP26 
IN.VALUE 
DATA_VALIDATION 
[b]$$$SYSPROG*LOSTFOCUS..OIWIN*[/b] 
RUN_EVENT[/color][/size] 
           
               

The item in bold is the actual system level event handler (which is itself a type of promoted event) that manages validations. We see in this case that this is what we refer to as an [i]event type specific[/i] promoted event. To know whether or not this will get called before or after your promoted event depends on what kind of promoted event you created. If it is a [i]control type[/i] or [i]event type[/i] specific promoted event then your logic will get called first. If it is a [i]generic[/i] promoted event then it will get called last.

Hope this didn't confuse matters too much.

dbakke@srpcs.com
[url=http://www.srpcs.com]SRP Computer Solutions, Inc.[/url]

[img]http://www.srpcs.com/srpicon1.gif[/img]

</QUOTE>

----

=== At 21 SEP 2007 08:12AM Martin Drenovac wrote:  ===

<QUOTE>Don - thanks very much. Please confirm to Kevin that I've read this document many a time.



I'm currently taking the OI way in creating and using promoted events in that I'm kicking off my own commuter module via the PE_event code generated by OI's own Event Designer.

As you'd be aware it has 3 kick off (GOSUB) points, and I was just asking which of these I don't want to do, and it sounds like the 2nd which is not to forward_event(self), in the case of where I want my own commuter to do the validation.



I will though work your example also - so thanks for taking the time out to assist.

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&SUMMARY=1&KEY=A4F985A76C1C6B0A8525735C003B39CE|View this thread on the Works forum...]]