In my application, the field of focus displays a descriptive help line at the bottom of the window along with two audit fields: mod-date and mod-id.

Starting a fresh session, all fields are empty, I type in an existing record ID.

When I tab, the help text is changed, and the associated audit record (screen*record ID) is retrieved and displayed.

This is where the problem starts. Shifting Focus fires a few things:

1: Yield() on LostFocus to fetch the record "record ID" (see 6)

2: the Help Line is cleared

3: the audit file is opened and the associated record is displayed in the audit fields

4: the help line associated with the second field is displayed

5: the second field gets focus

6: the record is retrieved (record ID) - at fld 2 only, GotFocus triggers a Read Row Quick Event (I assume the user comes from the record ID field) *I don't like this!

(finally, this is one problem)

7: the changed script fires

While the behavior is generally ok, how can I have all the fields display before a check is done for "changed"? (I don't want the changed script to fire on record retrieval.)

Secondly, the changed script fires once for each subsequent keystroke – How can I suspend the changed script until the focus changes?

Additional info:

Each field on the form has GotFocus, LostFocus and Changed events associated with them.

LostFocus generally, clears the help line; GotFocus displays the help line; Changed (if it were to act correctly) should only update the Audit fields when a change has occured on any of the fields (but not at each keypress).

I hope this is enough information, I can provide additional information if necessary.

Thanks for your input!

Jeremy

Jeremy,

I'm a bit confused by your approach. It seems a bit too complicated for what I think you are trying to do. For instance, why do you need to clear anything during the LOSTFOCUS events when you can do this in your GOTFOCUS events just prior to updating the help display?

I also don't understand the purpose for the Yield() statement in your LOSTFOCUS event. What other process are you trying to allow to execute at this stage?

This is a databound window, correct? If so, then you shouldn't need a READ QuickEvent on the GOTFOCUS event of the second control. That would force the window to read the record every time you looped through the form. OpenInsight automatically reads the record for you during the LOSTFOCUS event of the Key ID control…unless you are doing something to suppress this (such as returning a 0 in the script event).

We would also recommend not using script events unless absolutely necessary. We favor using QuickEvents to call commuter module style stored procedures or (even better) promoted events. So far I haven't seen anything you are doing that requires script events.

As far as detecting changes in each field, that is best done during the LOSTFOCUS event. You can check the MODIFIED property or do your own comparison with the TEXT and GOTFOCUS_VALUE properties.

[email protected]

SRP Computer Solutions, Inc.

Jeremy,

Although I disagree with Don's promoted events (more later) he is very right about the complexity of what you appear to be doing VS what might be needed.

The help should be handled with the GOTFOCUS event.

You really don't need the Yield on lost focus as the read should happen by itself unless your LOSTFOCUS event is not completing.

#4 .. not sure what this is doing. Simple read and display fields for the window or reading from secondary file? If from secondary then a quickevent (script) on READ would handle this

#5 .. yep .. focus moves to next control. do help here

#6 .. what don't you like? the event chain has been triggered

#7 .. change event because you have changed the data in the control.

What specifically are you checking on change? Similar to the CHAR event … every time you change the TEXT of the control the event gets fired. To change the behaviour .. don't use CHANGE use either lostfocus or gotfocus to check

Scripts VS QuickEvents and Promoted Events

Scripts:

Scripts give, to me, the best flexibility. It is a Pre / Post processing location. You can either do all the work in the script or simply forward to a 'Commuter Module'. I prefer to use the 'Commuter Module' when using scripts.

I used to use scripts religiously but have moved to more QuickEvents because they are a little cleaner. Simply have the QE call the commuter module as most processing can be done POST.

The down side is that the 'build' process of rdk makes using scripts much harder than it should be. Each script is an individual record unlike Delphi (against which all tools should be measured) which creates a single routine (its own commuter module). So during the RDK build you have to remember and tag all event scripts that you want included. been complaining about this since day one but still falling on deaf ears.

But remember .. if you want PRE processing you only have Scripts and Promoted Events.

QuickEvents:

QEs are all POST event process. The system has done what it will .. write, read, focus etc and you are just tagging on after words. For a lot of processing this works quite well.

It is much easier to build with QEs as they come along free in the RDK .. you just have to remember to add the commuter module.

Downside is that they are POST event only. Until RTI implements a PRE quick events, this can be insufficient to your development needs. In those cases you would use a Script .. but remember to include on the build.

Promoted Events:

PEs really are quite brilliant. Because of the naming convention in OI you can create and EVENT that ALWAYS happens regardless of application or ALWAYS happens in a specific application regardless of the window or ALWAYS happens for a specific window.

An example is your HELP display. If you always are going to display help the exact same way in all applications you ever build, you could create a PE for GOTFOCUS which would always fire for any app, window, control. It becomes the top of the event chain for GOTFOCUS. with good naming convention etc you can really save a lot of work for processes that are very repetitious. I look at PEs as the MFS for events (you can put the MFS in the filesystem chain in various locations to perform differently).

With this power .. and there is nothing like it in any other tool I have used .. comes some degree of complexity. You have to *KNOW* what is going on and what event chain is being used. May sound easy right now but what about maintenance etc. If you are ready to document extensively the processes then go for it. It really is a great process. The biggest drawback is there is no OI support of PEs. Good docs are available only from sites other than RTI and there is no 'proper' creation process of PEs.

If you want to learn more about PEs you will need to go to SRPs site or Sprezzatura's site. I believe both of them have white pages on the subject.

Since I haven't seen you name up here much and because of the event issues I *guess* you are fairly new to OI (?) and if this is the case I would strongly suggest that you first get the event chain down .. understanding all the docs and what is happening before you go to PEs.

Any other questions etc .. feel free to ask away ..

dsig_at_sigafoos.org

DSigs Radio Free Oregon

Phone: 971-570-2005

DSig,

With this power .. and there is nothing like it in any other tool I have used .. comes some degree of complexity. You have to *KNOW* what is going on and what event chain is being used. May sound easy right now but what about maintenance etc. If you are ready to document extensively the processes then go for it. It really is a great process. The biggest drawback is there is no OI support of PEs. Good docs are available only from sites other than RTI and there is no 'proper' creation process of PEs.

With all due respect to the honorable Sigafoos, these comments are somewhat overstated now. The online Programmer's Reference guide *DO* document Promoted Events and provide instructions on how to create and maintain them. Admittedly this documentation came from both Sprezz and SRP articles but nonetheless it is there now.

I'm not sure why there has to be an effort to "document extensively the processes". Perhaps PEs are unsupported by Revelation (i.e. you can't call them for help), but that is really isn't as big of a deal as is suggested. The fact is: 1.) Promoted Events work, 2.) OpenInsight is designed around the foundation of Promoted Events, 3.) If you start by designing Promoted Events into your system you will thank yourself for all the increased flexibility and functionality later. IMHO, I honestly don't know how anyone could stick with scripted events when you have to close your window, drill into the event script through the Form Designer to edit the event, recompile the window, and then relaunch the Window to test again. Promoted Events only require you to recompile a stored procedure…done (and normally you don't have to recompile or re-launch your window).

As I mentioned, the online Programmer's Reference Guide to document how to create Promoted Events. However, that doesn't mean this is the only or best way. Therefore, DSig is correct in his point about "no 'proper' creation process". However, I would again suggest that this is a very minor point. As long as you have *a* process that is all that matters. Once a good set of Promoted Events have been created…that's it! They don't have to be created over and over again. This is why we stress that people become familiar with Promoted Events as early as possible in the lifecycle of their application (or OI programming experience). If their Promoted Events are in place they need not worry about them again other than simply using them when needed.

I might hasten to add that there are no standardized ways of using scripted or QuickEvents either. I know people who still use QuickEvents to call the OMNIEVENT as a commuter module. Others call stored procedures. Same with scripted events. Some put all of their logic inside the script while others call stored procedures.

Finally, no one has yet mentioned the difficulties associated with deploying scripted events. Remember each scripted event adds a new entity to the Repository that has to be tracked. Thus, a typical window might require 5-10 entities to be deployed. If you strictly used a mixture of QuickEvents, promoted events, and a stored procedure for a commuter module then you only have to deploy 2 entities (assuming the promoted events have already been deployed with the base application). Then you have to worry about deploying a form that has had a scripted event removed. This can be problematic because you will want to remove the orphaned event from the target system otherwise OI might still call the event.

Well…that's my 8-1/2 cents.

[email protected]

SRP Computer Solutions, Inc.

Thank you to each who responded. As my question belies, I am semi-new to OI. (I worked with AREV from AREV-G forward.)

I am not up to par on the terminology, so please bear with me. I created a compiled procedure called "FlashMessage", it is in the general system architecture. To display the "Help" information, I just issue a call to my FlashMessage procedure with the appropriate parameters from my script event. I am mentioning all this in order to ask my question: is this, therefore, a PE?

—

I think the concept of what I am doing is fairly simple – I do not want to confuse myself or add complexity. The window is a single form that works with two tables. One main table, the other table (audit) only indirectly. If any of the fields for the record on the main table are changed, then I want to update the audit table with a timestamp and the current User ID.

—

I buried yields() into the lostfocus events because it worked… I also use the default RETURN 0 at the end of the event, so I will try to change that and see if that changes the behavior of my application.

I do not know how to check any MODIFIED variable to determine if a field was changed – from the sound of it, I'd prefer that method. If you can refer me to any material dealing with that I would be very appreciative!

Thank you for your very helpful assistance and comments!

Jeremy

Jeremy,

As my question belies, I am semi-new to OI. (I worked with AREV from AREV-G forward.)]

Hate to sound like a commercial, but we are starting an Intro to OpenInsight training class this coming Monday. The Intermediate class will be in the following week. All of this stuff is covered very thoroughly.

I am mentioning all this in order to ask my question: is this, therefore, a PE?

No, what you are doing is exactly the way you described it. That is, a scripted event that is making a call to a stored procedure. If you are seriously interested in promoted events then I would recommend reading the Promoted Events section of Chapter 10 "Programming Techniques" of the online Programmer's Reference Guide. Additionally, I would recommend these third-party resources:

The X Events

Creating a Custom Event

If any of the fields for the record on the main table are changed, then I want to update the audit table with a timestamp and the current User ID.

Do you want this to happen as each field gets changed or when the record is saved? It appears as if you are doing the former but what happens if the end user never saves the changes? Seems like something that would best be done during the WRITE event…i.e. simulating what you would have done during the pre-Save process in AREV.

I do not know how to check any MODIFIED variable to determine if a field was changed – from the sound of it, I'd prefer that method. If you can refer me to any material dealing with that I would be very appreciative!

Remember, the Programmer's Reference Guide is your friend. Just press F1 from within the System Editor and it will come up for you. I assume you know how to get and set properties. MODIFIED is just a property you can check for any control.

[email protected]

SRP Computer Solutions, Inc.

Jeremy,

As my question belies, I am semi-new to OI. (I worked with AREV from AREV-G forward.)

Hate to sound like a commercial, but we are starting an Intro to OpenInsight training class this coming Monday. The Intermediate class will be in the following week. All of this stuff is covered very thoroughly.

I am mentioning all this in order to ask my question: is this, therefore, a PE?

No, what you are doing is exactly the way you described it. That is, a scripted event that is making a call to a stored procedure. If you are seriously interested in promoted events then I would recommend reading the Promoted Events section of Chapter 10 "Programming Techniques" of the online Programmer's Reference Guide. Additionally, I would recommend these third-party resources:

The X Events

Creating a Custom Event

If any of the fields for the record on the main table are changed, then I want to update the audit table with a timestamp and the current User ID.

Do you want this to happen as each field gets changed or when the record is saved? It appears as if you are doing the former but what happens if the end user never saves the changes? Seems like something that would best be done during the WRITE event…i.e. simulating what you would have done during the pre-Save process.

I do not know how to check any MODIFIED variable to determine if a field was changed – from the sound of it, I'd prefer that method. If you can refer me to any material dealing with that I would be very appreciative!

Remember, the Programmer's Reference Guide is your friend. Just press F1 from within the System Editor and it will come up for you. I assume you know how to get and set properties. MODIFIED is just a property you can check for any control.

[email protected]

SRP Computer Solutions, Inc.

Don,

I have paid especial attention to your tips, but my window seems to be degrading.

At this point, for all but the first field (key ID) there are no LostFocus events. That is a cleaner way of doing this too!

In the lostFocus event I do have, I read the ID and then immediately open the Audit table to retrieve the record with that key (in combination with the screen name).

If present I grab the audit field values, otherwise, I generate new ones… (I will eventually move that to the Save section, as was suggested.)

The LostFocus Event does a RETURN 0 at the end. Other values seem to drop me into the debugger or not let me leave the Key field. What value should I do my RETURN with?

Of equal importance, none of the fields in the form are getting populated. Does opening the Audit table interfere with the normal chain of event and "confuse" OI?

Jeremy

1) .. nothing honorable about me .

2) I mentioned '..The down side is that the 'build' process of rdk makes using scripts much harder than it should be. Each script is an individual record ..'

So yes Scripts do have a downside. This is the biggest problem with scripts.

3) '.. I'm not sure why there has to be an effort to "document extensively the processes" ..'

Unless you are writing the PE and you are the only one who will ever be maintaining the app then documentation would be very handy.  Like a MFS, the PE is pretty invisible to the application.  If the PE has not been documented (at least noted it is there) and the client calls in a  different developer .. how will they *know* it is there?  It isn't obvious.  

Of course as consultants we should expect that we are the only ones who will be working on the app. why would they ever need someone else?

4) ' .. I might hasten to add that there are no standardized ways of using scripted or QuickEvents either .. '

True .. nor is there a 'standardized way' of looping through a MV list of keys (use loop or for/next .. use or remove .. oh the humanity

5) ' .. As I mentioned, the online Programmer's Reference Guide to document .. '

I am very glad to hear this. Will check out the docs again.

Finally ..

All kidding aside .. you seemed pretty defensive and that was by no means my aim.

PEs are a great feature of OI and should be 'promoted' by integrating the creation and maintenance of them into the system.

I think we should get rid of QE and Scripts .. simply have PE. Then there will be no confusion about pre/post .. the developer just handles it in 1 place ..

Each form would automatically generate a 'commuter module' which would be called for all event processing. You simply add/fill in the bits you want. No wait .. that would be delphi

dsig_at_sigafoos.org

DSigs Radio Free Oregon

Phone: 971-570-2005

Jeremy,

It is important that you study and understand event flow. This is a basic requirement in order to develop applications of any level of complexity. If you are unable to attend a training class then at least read the chapter called "Understanding Standard Event Handlers and Processes" in the online Guide to Application Development. You can access this by clicking on the "?" button in the Application Manager's toolbar.

The reason your prompts aren't getting populated is because you are doing a RETURN 0 in your LOSTFOCUS event. In my first post I made a reference to this being a problem for you. Events move forward or not based on whether you RETURN 1 or RETURN 0. In your case, the RETURN 0 is stopping the event flow from moving forward to the READ event and therefore your record is not being read. Thus, this is somewhat analagous to setting WC_VALID% to 0 during the pre-Read process. Again, read the online chapter that I referred to above.

[email protected]

SRP Computer Solutions, Inc.

DSig,

.. nothing honorable about me .

Oh don't sell yourself so short (er…I guess that was not the best word for me to use!).

I mentioned '..The down side is that the 'build' process of rdk makes using scripts much harder than it should be. Each script is an individual record ..'

Mea culpa…somehow missed that whole paragraph.

Unless you are writing the PE and you are the only one who will ever be maintaining the app then documentation would be very handy. Like a MFS, the PE is pretty invisible to the application. If the PE has not been documented (at least noted it is there) and the client calls in a different developer .. how will they *know* it is there? It isn't obvious.

This is a point well taken. We recommend that promoted events primarily be used to call the commuter modules themselves. Hopefully, then, no extensive documentation will be necessary…assuming the commuter modules are designed well enough.

Of course as consultants we should expect that we are the only ones who will be working on the app. why would they ever need someone else?

Easy for you to say. I have a full staff that I have to work with. Of course, they have learned to do things *my* way.

All kidding aside .. you seemed pretty defensive and that was by no means my aim.

Not at all. I did not mean to sound defensive. I was probably *aggressive* in my response but only because I didn't want Jeremy (or anybody else) to walk way from Promoted Events without giving them a chance.

[email protected]

SRP Computer Solutions, Inc.

Re: Commuters - have you looked at ZZ_Skeleton from the conference CD?

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Unless we're badly missing the point there may be some wheel reinvention going on here. OI can happily update multiple tables from one form as long as the key to the other table can be defined on the original form. See http://www.revsoft.co.uk/Downloads/multitablewindows.pdf for a tutorial.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Jeremy,

JH]] I created a compiled procedure called "FlashMessage", it is in the general system architecture.

? not sure what 'general system architecture' is.

JH]] To display the "Help" information, I just issue a call to my FlashMessage procedure with the appropriate parameters from my script event. I am mentioning all this in order to ask my question: is this, therefore, a PE?

No. This is a stored procedure.

JH]]I think the concept of what I am doing is fairly simple – I do not want to confuse myself or add complexity. The window is a single form that works with two tables. One main table, the other table (audit) only indirectly. If any of the fields for the record on the main table are changed, then I want to update the audit table with a timestamp and the current User ID.

Cool ..

if the audit info is critical (eg .. governmental/financial audit information needs to be tracked and reported) then an MFS is a better way to do this. The reason is that once put on a file any Read/Write access to that file HAS TO go through the MFS (unless a developer actually uses the lowest level to get to the data (bfs rtp57))

This is not critical to our discussion .. just wanted you to know. better to learn how AFTER you are feeling good with OI.

JH]]I buried yields() into the lostfocus events because it worked… I also use the default RETURN 0 at the end of the event, so I will try to change that and see if that changes the behavior of my application.

Just so you know .. this indicates to me that there is something wrong with the basic logic and use of Events. yield() is great handy tool but normal event processing doesn't really need it (normally)

JH]]I do not know how to check any MODIFIED variable to determine if a field was changed – from the sound of it, I'd prefer that method. If you can refer me to any material dealing with that I would be very appreciative!

Here is a simple way.

On the GOTFOCUS event something like

* get the current value of the field

origVal=get_property(ctrlEntId, 'DEFPROP')

* set the value to your 'created' property in the control

set_property(ctrlEndId, '@ORIGVAL',origVal)

At this point the control (editline etc) has the current value placed in a 'created property'. So when you lose focus you could

* get the ORIGINAL value of the control

origVal=get_property(ctrlEndId, '@ORIGVAL')

* get the CURRENT value of the control

curVal=get_property(ctrlEndId, 'DEFPROP')

* compare them ..

if curVal # origVal then

• ** do what you need to do

end

There are some short cuts you could take with the previous code but this shows all that is happening and might give you some ideas

JH]]Thank you for your very helpful assistance and comments!

You are very welcome. More questions just put them up here.

As mentioned elsewhere .. there are a lot of ways to do similar things .. first learn the basics of the event chain, how OI behaves, stored procedures and the filing system. Once that is all under your belt then spread your wings and have fun with the additional power available through other features.

dsig_at_sigafoos.org

DSigs Radio Free Oregon

Phone: 971-570-2005

hmm .. have to admit that I didn't. Andrew mentioned that they were going to release one but I didn't 'grok' that it was on the CD .. will look.

I wish that it was part of the system .. integrated in as noted before .. but then that is me

thanks for the heads up

dsig_at_sigafoos.org

DSigs Radio Free Oregon

Phone: 971-570-2005

DB]]Not at all. I did not mean to sound defensive.

cool ..

DB]]I was probably *aggressive* in my response but only because I didn't want Jeremy (or anybody else) to walk way from Promoted Events without giving them a chance.

I too think that PE, *FS etc are great tools and hold great power. I just think that the Basics of the system should be learned, used and understood first.

Of course they could always come to your two week class

promotion off]

dsig_at_sigafoos.org

DSigs Radio Free Oregon

Phone: 971-570-2005

Yes .. good catch. OI does multi table update .. and would work here with some bodging .. but as he only wants to update the audit table on specific changes (at least that is my reading) and actual check at write time and update additional table might be easiest.

Of course, you link is something he should become familiar with so he knows all the options .. so many ways .. so little time

but will check the doc you mentioned in case I missed something .. has happened before

dsig_at_sigafoos.org

DSigs Radio Free Oregon

Phone: 971-570-2005

Don't you just love a happy ending…

That's a novel idea…oh wait…I had one of those for Arev even before OI had been released. I thought *everyone* had one…

Of course you did Tim - we released it in about 1990 with REVMEDIA to which you (generically) were subscribers at the time :)

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

lol

I realised that after I'd posted…but I'm sure I had to change it to make it work properly :~S

Not convinced we released source…. but could be wrong ;)

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Don & DSig,

Thank you for your very helpful tips and pointers. I looked a little more into the on-line documentation and found, indeed, I am supposed to do a Return 1 at the end of my event. Evenso, my form is not progressing as I would like it to. Here is the snippet from my LostFocus event:

Declare Function Set_Property, Get_Property

Entry=Get_Property(CtrlEntID,"TEXT")

ReadAud=CUSTOMER*":Entry

open "AUDIT" to AUDIT_TABLE then

 read AudRec From AUDIT_TABLE, ReadAud then

   UpdateDate=oconv(AudRec,"DT/^3H")

   UpdateID  =AudRec

 end else

UpdateDate=OCONV(Date(),"D4/"):" ":OCONV(Time(),"MTH")

UpdateID  =@USERNAME

end

RetVal=Set_Property(CtrlEntID1,'F.':'.MOD_DATE',"TEXT",UpdateDate)

RetVal=Set_Property(CtrlEntID1,'F.':'.MOD_BY' ,"TEXT",UpdateID)

Return 1

(I am excluding the Help msgs that I flash for each field – that is not drawn from a table, though I do have a notion to eventually grab that from the dictionary.)

When I run this form, I enter the key I want to retrieve. When I shift focus to the next field, this script (LostFocus) does execute, and the screen is updated as indicated above with the audit table values. The screen does nothing beyond that, and the focus does not effectively shift to the second field – the key field gets selected, but I cannot tab out of it.

Is my record retrieval from the Audit Table somehow ruining the event stream?

jh

Jeremy,

testing in 4.3.1a

I created a form with keyfield and 3 data fields. I also put 2 NON bound controls (MOD_DATE AND MOD_BY). i put your code in the script for LOSTFOCUS of theKEY field.

Changes Made:

1) changed name of table from AUDIT to TEMP

At this point ran the form and it updated the controls, read the data and moved to the next control

*NOTEs

1) in the code example you show there is a missing END which i assumed went after the set properties .. it did compile and run without but ..

2) it was not clear if AUDIT was the same table your form was going against .. but I assumed it wasn't.

My guess is the problem is in the bits you cut out. Sometimes funny things happen with focus etc when working with messages.

Have you tried this snippet of code?

dsig_at_sigafoos.org

DSigs Radio Free Oregon

Phone: 971-570-2005

View this thread on the Works forum...