Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 17 JAN 1998 09:37:55AM Bill BUell wrote:

I am looking for a way to programatically determine the event currently processing. E.G. let's say OI has a function called WHAT_EVENT such that in the procedural code of (lets say) a CLICK event that the statement

THIS_EVENT_NAME=WHAT_EVENT() would return the value "CLICK"


At 17 JAN 1998 09:53AM Bill Buell wrote:

The reason I would like to programatically determine the current event is that I am writing a "COMMUTER ROUTINE" for an application, i.e. one monolithic routine which is called from every procedural event. The arguments passed to the COMMUTER ROUTINE are WINDOW_NAME, CLASS_NAME CONTROL_NAME, EVENT_NAME, AND AN (OPTIONAL) Argument List (which is seldom needed, but its there). WINDOW_NAME, CLASS_NAME, and CONTROL_NAME may be determined programatically from CtrlEntID and CtrlClassID. At present, I must explicitly pass the EVENT_NAME. If I could determine it programatically, then I could just key a $insert statement to copy the code which invokes the COMMUTER ROUTINE into the procedural event in question. I notice there are functions such as IsEventContext() and GetEventStatus(), so perhaps there is a function to return the CURRENT EVENT.

I am also curious to hear any opinions concerning the pros and cons of using a large COMMUTER routine. Are there any performance issues. It seems advantageous to have all the code for an application in one program, if only for the sake of documentation. One can easily toggle back and forth between the SYSTEM editor and the Form Designer to modify the routine. Also, if the Named COMMON needs modification, it is not necessary to recompile many little snippets of code.

This is my first COMMUTER routine, as an experiment, and I am still very new to OpenInsight, so forgive me if I am "barking up the wrong tree" or overlooking something very obvious. Thanks.


At 17 JAN 1998 10:55AM DSig (SigSolutions) wrote:

1) Using a commuter modules makes a lot of sense.

2) Since all events get put on the stack the 'Retstack' routine which came out in 3.4(?) should give you the information you need. Below is a snippet of information on retstack.

*The new RETSTACK function returns an @fm delimited list of the currently executing procedures as

                  seen in the debugger's Call Stack window (SYSOBJ/$RETSTACK). Syntax is:
                  declare function RetStack
                  List=RetStack()
                  CurrentProc=List
                  CallingProc=List
                  ...

Dsig

David Tod Sigafoos ~ SigSolutions

[email protected] cis: 70302,77 voice: 503-639-8080


At 17 JAN 1998 12:42PM Cameron Revelation wrote:

Bill,

The reason I would like to programatically determine the current event is that I am writing a "COMMUTER ROUTINE" for an application, i.e. one monolithic routine which is called from every procedural event.

See the Knowledge Base article Using QuickEvents with Stored Procedures for some related information.

Cameron Purdy

Revelation Software


At 17 JAN 1998 11:31PM Don Bakke wrote:

It seems advantageous to have all the code for an application in one program, if only for the sake of documentation.

If you can do it, wonderful. However I'm skeptical that an entire application can share a single commuter module. We just write commuter modules for every window, and even then we sometimes hit a size limit.

Different people will either use code stored as a procedure or contain everything within a window's OMNIEVENT. The former is easier to make modifications to while the latter (IMHO) is easier to track for deployment/check-out purposes.

[email protected]

SRP Computer Solutions


At 19 JAN 1998 05:48AM Jeff Hostetter Word Enterprises wrote:

Your question about knowing what event you are in is one that I am interested in also. So far no one who responded has addressed this part of your question. We could not find a way to do this and resorted to hardcoding it in everywhere.


At 19 JAN 1998 06:49PM BILL BUELL wrote:

Thanks, David Sigafoos. Your LIST=RETSTACK() was exactly what I needed. I will mention that the first thing I did was to search for the RETSTACK function both in the MANUALS and in Online Help, and it seems to be undocumented. Perhaps I am looking in the wrong place? It does make me wonder how many wonderful useful UNDOCUMENTED functions and commands a lurking around in OpenInsight.

This Online Discussion seems like a great place for a developer to get help. Im certain I got the quickest and best solution to my problem by posting a question here and reading everyones' contributions.


At 20 JAN 1998 07:39AM Cameron Revelation wrote:

Bill,

It does make me wonder how many wonderful useful UNDOCUMENTED functions and commands a lurking around in OpenInsight.

The RetStack function is not in the printed documentation because it was added to a more recent version of the product than the manuals reflect. If it isn't in the latest online help, then it will be in an upcoming release.

Given the choice between providing the feature or not providing it until the printed documentation and online help are in sync, we will always provide the feature. For information on new features, read the README.WRI file and the "What's New" printed documentation that comes with each release – there's a ton of information in each.

Cameron Purdy

Revelation Software


At 20 JAN 1998 11:54AM Andrew P McAuley wrote:

This was in the 3.4 read me and is on this site at 3.4 Readme

[email protected]

Sprezzatura Ltd

World Leaders in all things RevSoft

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/8846435b9e57bd9b8525658f00506060.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1