Visual LANSA Forum

Is there a way to open a command that is not associated with the Framework, Application or Business Object?

This is related to my question on presenting reports here http://vlforum.lansa.com.au/viewtopic.php?f=3&t=1367.

Basically all I am trying to do is present the user with a list of available reports, they select one, and I open the command that presents the report.

What I am running into is that I have to associate the command (that displays the criteria and results of the report) with either the Framework, Application or Business Object otherwise I get the error that the command cannot be found. That means that when I view that object, all the reports (represented by tabs) show up and I don't want them to.

Ideally I would be able to "Hide" other tabs as shown in the Command the properties, but these don't work for VLF-ONE. The same problem happens regardless if I attach it to the Framework, an Application or a Business Object.

So if I could open a command without it being associated with anything, it just opens, these problems would be solved.

The only other way I can think of doing this is with a popup window, unless there are some other ideas out there.

Thanks,
Joe

A hidden VLF command handler, talking to a PRIM_PPNL would probably do this job, but you have to hide it when the user changes application tabs.

Given the need for many different report formats and may different reporting criteria inputs I don’t think your report displayers should be VLF command handlers. If you had just one framework level VLF Reports command, like the shipped example dashboard, you could make it into the ‘orchestrator’ of a set of VL-Web reusable parts. Maybe something like this:
Every report might have an associated reusable part to input selection criteria (selectors) and another to visualize the report (displayers). They key to implementations like this is that the all the selectors have a common ancestor. That allows common code/visualizations to be shared, but more importantly it allows the VLF command handler ‘orchestrator’ to control them all generically. Another key is to know about using SET_REF *CREATE_FROM, as opposed to the more common *CREATE_AS, so that you can dynamically load the reusable parts by using their identifiers.

In the picture reports A, B and C would each have a selector and a displayer associated with them, probably identified by simple text hidden columns in the report selector part (that’s where using *CREATE_FROM comes into play).

If you need to put buttons on the VLF tool bar, or in other VLF command handlers, to act as short cuts to specific reports that quite doable as well. Using symmetrical Initialize/Terminate methods in the reusables to make sure nothing leaks is also important.

I guess that you using the same individual report/selector/displayer reusable part approach you could create a business object called Reports.
It would have a single filter and a single custom instance list, both of which managed a set of report selector and displayer resuable parts.

This classic filter/instance list ……… Could become ………… Doing that might save you some plumbing code (eg: the ability to move the filter to top, left, bottom or right).

If used this way the VLF's instance list construct would probably not be used at all ......... or maybe used for some internal exchanges between the selectors and the displayers.

Hi Mark,

I think I understand what you are suggesting. Using a "main" object/panel to coordinate other panels is how I did our last non-VLF application. Taking that concept into a "Report" object where it is acting as the coordinator to display the criteria and results seems doable.

Will try it out.

As always thanks a ton for the help, advice and suggestions. I could not do half of what I have done so far without your input.

Thanks,
Joe