Page 1 of 1

VLF-ONE Listening for Events in Commands

Posted: Wed May 17, 2017 8:03 am
by jyoung
I have an object that has 5 filters and 6 commands in VLF-ONE.

I've been asked to "close" the command window when the user clicks on the "Search" button in the filters.

This is because they are getting confused with the stale data on the command window after searching with a filter. Meaning that they search with a filter and have selected an instance from the instance list, and the view the commands. Then they click on another filter and search again. BUT instead of selecting an item on the instance list, they are going directly to the already shown command.

I am thinking I will signal an event in the filter and use avCloseForm in the command to close the window. However I don't what is the best way to "listen" for the event.

Does the event have to be listened to in ALL the commands? Can I just listen for it one, perhaps the default, command? Is a command only "listening" for events if it is the active command?

Re: VLF-ONE Listening for Events in Commands

Posted: Wed May 17, 2017 10:14 am
by MarkDale
I would listen for the event on all the command handlers.

So the filter would signal like this:

Code: Select all

Evtroutine Handling(#Search_Button.Click)
#Com_Owner.uSelectData

#Com_Owner.avSignalEvent To(BUSINESSOBJECT) Withid(CLOSECMH)

Endroutine
and each command handler would listen like this

Code: Select all

Evtroutine Handling(#Com_Owner.avEvent) Withid(#uWithID)
If (#uWithID = CLOSECMH)

* #sys_web.Alert Caption('Received signal - closing')

#Com_Owner.avCloseForm

Endif
Endroutine

Re: VLF-ONE Listening for Events in Commands

Posted: Wed May 17, 2017 11:18 am
by MarkDale
Another way to do it is to change the filter to force the command handler to automatically display for the first entry.

Re: VLF-ONE Listening for Events in Commands

Posted: Thu May 18, 2017 1:50 am
by jyoung
I got this to work by listening for the event in a "base" command.

I have a base command that all my command handlers inherit from. It does a couple things like listen for design changes and highlights/clears validation problems etc.

By listening to the for the event here, I don't have to touch any of my other commands. It also has the added benefit that I can send the event to just the business object or the application and have it picked up to have all the business object or application commands closed.

I may be wrong here, but it "seemed" like the first command was always the one to pick up the event. I say that because in the trace messages, the component would be identified as CMGCCPC01 (the first Command) even though the second command was active.

I still had to signal the event in all the filters though, would like to find a way to clean those up some.

As MarkDale mentioned, handling the event is easy enough

Code: Select all

evtroutine handling(#COM_OWNER.avEvent) withid(#eventId) withainfo1(#info1) sender(#sender)
#avFrameworkManager.avRecordTraceAValue component(#COM_OWNER) event('VLFCommand - Event Picked Up') avalue(#eventId)
case of_field(#eventId)
when (= 'CLOSE_COMMAND_WINDOW')
#avFrameworkManager.avRecordTraceAValue component(#COM_OWNER) event('Closing Form') avalue(#eventId) avalue2(#info1)
#COM_OWNER.avCloseForm
endcase
endroutine
Publishing the event from the filter

Code: Select all

#COM_OWNER.avSignalEvent withid(CLOSE_COMMAND_WINDOW) to(BUSINESSOBJECT)

Re: VLF-ONE Listening for Events in Commands

Posted: Thu May 18, 2017 9:09 am
by MarkD
Sometimes developers automatically select the first instance list entry after any search and execute a command, usually the default command.
That forces any open command handler to change to that display that instance.
That might save the overhead of continually destroying and recreating the pane that contains the command handler tabs.

To do that put Select(true) SetasCurrent(true) on the first AddToList only.
Then when the list has been completely built execute a switch like this:

Code: Select all

#AVFRAMEWORKMANAGER.avSwitch Caller(#Com_Owner) ToObjectNamed(<This business object's user name/type>) execute(<The chosen command's user object name/type>)
That should execute the chosen command against the current business object instance.