Mike et al,

I'd really like to see a 'Default Value' property that I could pass as a parameter in the Quick Events Parameters in form designer. I've got a procedure that I'd like to call from various different controls and don't want to have to go through the hoops of working out what type of control called it and then what property I need to retrieve.

What's the chances?

TIA

Tim

OK - I (Andrew) am missing something. Where does the case statement come from? DefaultValue=Get_Property(CtrlEntId, "DEFPROP"). The whole point of DEFPROP is that is does the Case for you.

Aaron - you're there - chip in

The Sprezzatura Group

World Leaders in all things RevSoft

The idea isn't as much the saving of the call, but in the passing of parameters.

For example, suppose you have an archive routine that archives a record from place to place. You already have a routine that takes the key and performs the archive.

ArchiveMe( SomeKey )

By having @DEFPROP, one could have the quickevent do a subroutine call to ArchiveMe, and then have the param be @DEFPROP, which is the param to the file.

Currently, one you have to call a commuter, then get the defprop, then call archiveme.

This could be used with various system routines, like LIST_VOLUME and so forth.

I'd even take this one step further to allow for the DEFPROP of a qualified control.

'@WINDOW.CONTROL1', '@WINDOW.CONTROL2' and so forth, which would trigger obtaining the defprop values of each and passing them down the chain.

Though to be fair, I wasn't really involved in the discussions on this, so I'm not sure the actual context :)

The Sprezzatura Group

World Leaders in all things RevSoft

Being the Borg we naturally all agree on everything - except when we don't .

Ultimately there is a definite requirement for promoted events - the system itself relies upon them. Having said that promoted events DO lend themselves to misuse especially when promoted to an inappropriate level.

An example of a GOOD use of a promoted event would be one that implements a CHAR event on a coded field to display lookups. As this will apply wherever the code UDC is used, it makes sense to do it at a promoted level or by adding a call to the appropriate routine using an MFS on SYSREPOSWINEXES.

The use of a promoted event coupled with commuters capable of enumerating supported functions allows a style of object oriented development, and the use of "place holders" to call the main promoted commuter minimises the complications caused by recompilation. Most failings of promoted events are actually failings of the underlying toolset to recognise them and deal with them correctly.

The point about regression analysis is however very valid especially in a tightly controlled environment.

The Borg Queen - One of Four - Puffy Shirt

The Sprezzatura Group

World Leaders in all things RevSoft

You little tinkerer you ..

dsig@sigafoos.org

DSigs Radio Free Oregon

Don't forget @event, too. To get the current event.

These are great ideas.

The quick event caller is part of Formdes code, not going to get major surgery yet.

However, I tried something like the following:

I made a window to edit the Quick-Events, let me add my own quick_events

Added a new quick event:

 Call Commuter Module

 It executes a program named obj_call_event

 With parameters of

 '@Self', '@Event', '@Param1', '@Param2', ... '@Param6'

 obj_call_event looks up commuter module for the window, resolves @Event, calls the commuter module.

 Does it make sense to have a quick_event called Quick_Catalyst that calls a soft_coded program named rev_ide_catalyst in which we provide some of the behavior described in this thread, which any of you could override or extend by changing the cfg_quick_catalyst record to call your own version?

OY]That caused problems e.g with international characters like the Norwegian "ø" in captions.)

.. i am not saying anything

dsig@sigafoos.org

DSigs Radio Free Oregon

Dsig,

In Norway cows say "Møø".

- Oystein -

PS. It's Øystein, really.

Other good examples are if you want record searching to go through a common dialog (suppose this is a similar example), or if you want to check for user rights, identify windows based on system, or have an option or help based system which was stored as window.control name, or dictionary driven. So, for example, help would find the control, and if a dictionary, display the dictionary description, or if not, read a record based on the control name.

Matter of perspective, really. If a drone wanted the same thing to happen on all (or most) situations (READ, CREATE, Lost focus on an edit line) then yes, promoted events are the best, if not only, way to code this. With the ability to interupt any portion of the event chain was an act of inspired genius that's probably not found in any other product.

This drone's original comments were based on the idea that pre-reads, for example, belong in a promoted event. They would, but only if they were doing basically the same thing. If it's just a pre-read because this drone happen to need a pre-read, then it belongs attached to the specific form.

This drone's view of promoted events is that they are meant to perform identical actions at specific times when called from specific controls or events.

Three of Four Three is a magic number, yes it is

The Sprezzatura Group

World Leaders in all things RevSoft

One could also use the pre-read promoted event to CALL the window specific commuter as per Don's original suggestion

The Sprezzatura Group

World Leaders in all things RevSoft

Suppose so, in the short term, but in the long term it would be best to allow all this to cascade through, so we'd have an event builder, with mutiple pages, or tabs, or whatever the current word for page/view is. Have this loop through execnphandler in a loop. Each event would be @STM delimited down for multiples in the chain.

Harder work to implement inside formdes for now, but would appear to have a smaller footprint if an external tool would do the work of creating the events (especially since you're well on your way), and would seem to require only a small change to system code.

Would require some additional work on the developer's end, since they'd have to modfy their code external to formdes, and I can forsee problems in formdes during load and compile when it finds the weird quick events, but there could be ways around that through alternate file storage and swapping during form load in start_window.

Perhaps even ship on a new OI DUDS series…not that I'm suggesting that the old DUDS program be revived…well, no, actually I am… :)

Just thinking out loud……..

The Sprezzatura Group

World Leaders in all things RevSoft

So do I Bob, but I just wanted to have an @Defprop to pass into those routines……didn't realise it was such a big can of worms!

And don't forget to allow stuff like @@Defprop so DEFPROP can contain the name of a different property which will be retrieved.

- Oystein -

Only when every single window in the system requires it. However, it's been this drone's experience that promoted events are not used very often, and when they are, are usually misused.

I've seen more systems with promoted events with READ code with things like

Case @Window=WINDOW1'

// bunch'o'code

Case @Window=WINDOW2'

// bunch'o'code

Case @Window=WINDOW3'

// bunch'o'code

and that's the extent. That's not a promoted event, that's just a global commuter. It's not like you want the same thing to happen on every event, you just something specific to happen. In that case, it should be tied to the window. Be just as easy to jam something into the event or quick event. At least it's all in one place, and I don't have to jump around compiling promoted events and ensuring all the pointers are in place, then regression test just in case my small bit of code placed in for window X causes problems when a read in window Y comes along.

Three of Four

The Sprezzatura Group

World Leaders in all things RevSoft

Agree that I am proposing a half-step.

Our long-term goal is to implement Formdes in Basic+.

I regard whatever I / we do with quickevents as prototyping for that.

Also, quite honestly, lots of you make better use of quickevents than I do. My default style is to use the quickevent to delegate to the options event of a control or the omnievent on the form, have the omnievent be the commuter module. I have not pushed the quickevent technology to get the 'magic' leverage that it offers as well as to understand the shortcomings. In short, I want to make sure I fully understand the problems before I try to solve them, lest I do more harm than good.

Doesn't DEFPROP do this for you?

The Sprezzatura Group

World Leaders in all things RevSoft

Confused - you will be

Guess I'm not seeing how

DefaultValue=Get_Property(CtrlEntId, "DEFPROP")

is any different that @DEFPROP?

The Sprezzatura Group

World Leaders in all things RevSoft

OK I now see what you want. I'd suggest an improvement on this, namely if the parameter BEGINS @ the system first checks for Reserved Words (@SELF et al) and if not one of those does a Get_Property for the current control using the value after the @ then passes this value.

While we're on improvement requests - the ability to STACK quick events so that I can EXECUTE a POPUP and then send a LOSTFOCUS to the control. Gives us back catalyst

The Sprezzatura Group

World Leaders in all things RevSoft

It is a convenience ..

Because the routine being called from the quick event may be dealing with a large number/type of controls .. it would be simpler if the routine could simply receive the 'data' from the quick event call instead of creating a case structure etc to find the process/control then strip out accordingly.

So having an @variable which has the current control 'defaultprop' data would just be handy. Just like @Record is/was handy .. yes we can read all the controls and then build the data .. but just a little handier

A single line of code in PS (or where ever) setting something like @CtrlData (or whatever) would then remove the same line of code from 40billion kagillion programs and that is a lot

dsig@sigafoos.org

DSigs Radio Free Oregon

Very rarely will we use event code. We only use event code when event chain rules require it (pre-read, pre-write).

Ah…but even then don't you simply have a promoted event handle this? Hence, you ultimately have a commuter (of a sorts) handle this for you.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Hey!!! This is my thread. Get off my Land!!!

While we're on improvement requests - the ability to STACK quick events so that I can EXECUTE a POPUP and then send a LOSTFOCUS to the control. Gives us back catalyst

Okay, that would be so sweet!

dbakke@srpcs.com

SRP Computer Solutions, Inc.

To be fair, we do almost everything with quickevents. Very rarely will we use event code. We only use event code when event chain rules require it (pre-read, pre-write).

Since we're talking about enhancements, it would also be really cool to have a quickevent that runs before the event chain as well as the one that runs after.

So, the ideal world (at least as of 09:41GMT) would be

Multiple QE calls

Event chaining logic

Multiple QE calls

One of the reasons we avoid event scripts is to keep all our code in single commuters. While this is possible with the omnievents, you can't really call the omnievent from outside the window for some code reuse.

Conceptually, I have no problem calling a commuter to a window that is not loaded, but I do have a problem doing a send_event to a window that is not loaded.

The Sprezzatura Group

World Leaders in all things RevSoft

The answer is a definitive and emphatic "sometimes"

The Sprezzatura Group

World Leaders in all things RevSoft

Each event would be @STM delimited down for multiples in the chain.

Read this very quickly. Don't understand all of it. Just want to warn in general against using delimiters below @STM.

(I remember some years back when a new version of OI suddenly stored data about forms with more levels of delimiters (10 instead of 6???). That caused problems e.g with international characters like the Norwegian "ø" in captions.)

- Oystein -

Not in a Quick Event…

I had thought of that

View this thread on the Works forum...