Visual LANSA Forum

I am trying to switch from one object to another in VLF-ONE and execute a command. When I do I get an "avSwitch" failed error. If I don't include the execute parameter the switch occurs fine and the other object's (Time Cards) filter is displayed. In this instance however, I have a specific time card identified and and I want to show the details.

Here is my object definition and the command definition The command shows that the COMMAND_DETAILS is enabled.

I am trying to execute it as such, eventually passing a "caller reference" that contains the required identifiers. The docs are not specific on "which" user object name / type name to use. If I use CMG_TIME_CARD_DETAILS (from the object command) then I get the error shown above. If I use COMMAND_DETAILS I get an error saying its not enabled.

The trace output shows its trying to invoke the command What am I missing? How do I switch to an object and execute a command?

EDIT
Following the examples in DF_DET54O it uses the user object name defined in the command definition not in the object's commands. So use COMMAND_DETAILS instead of CMG_TIME_CARD_DETAILS an I get the error

avSwitch failed. The command named COMMAND_DETAILS associated with the object named CMG_TIME_CARDS is not currently enabled.

EDIT
Further comparison with the example shows a difference between my command being an "Instance" command and the example being a "Object" command. Changing my command to be an "object" command fires up the details command, but breaks my Time Card object as its filter no longer triggers the details command.

So it looks like one has to be an instance command while the other has to be an object command.

Which means that I cannot reuse commands and I will effectively have two commands that do the exact same thing!
I can make that work and still keep my maintenance overhead low, just want to make sure that is how it is "supposed" to work.

Is that right?

The user object name/type on avSwitch is of the command definition.

That the global name assigned to the Details command’s definition.

The 3rd screen shot you have is not of the command’s definition – that is just one place that the command is allowed to be used. It is called a command reference, and potentially confusingly, it can also can have a user object name/type for arcane security reasons that elude me at the moment.

Use the Command Definitions option in the Developer’s Workbench and you should see that the Details command has user name/type COMMAND_DETAILS.

That’s the one to use.

A timesheet instance level command is only enabled when one or more time sheets are selected in the timesheet instance list. An object level command is enabled if the business object is open.

“New” is a classic object level command – as in you don’t have to select a timesheet to create a new one.

“Details” and “Copy” would be classic instance level commands – as in you must select a timesheet before executing them makes sense (ie: they are enabled for execution).

It’s worth knowing that object level and instance level commands execute in different command panels. That’s done so that you can create a New thing while looking at the Details of another thing.

A single command cannot be both instance and object level. However, you can certainly have two command definitions captioned “Details” with different user object name/types. They can share the same command handling program, but that might be confusing to users to see 2 options with the same caption?

You are getting the not enabled message because there is no “current” timesheet in the timesheet instance list.

I not sure of the dual usage context here for the “Details” command here, so the rest of this might be wide of the mark ….

Are there two different types of “Details” requests? Is the programmatic command any different to a user displaying an instance list of timeseheets and clicking on one to see its details?

Have you considered sending a signal to the timesheet’s filter that says “Please put timesheet 1234 into the instance list, select it, and then execute its Details (default?) command”? Assuming that there is a filter, this might be a structurally simpler solution to program.

Finally, there is an option on the avSwitch to ignore the Details command’s enablement state – but that might be brute force and cause other issues and complexities in your command handler’s code such as there being no current timesheet instance.

I also forgot to mention this capability that exists in VLF-ONE, but not in VLF-WIN.
It allows you to programatically alter the enablement state of commands.

Intended use is to enable/disable command tabs for reasons other than authorization - but it's an option here I guess.
For example the Map tab is disabled for customer with no address supplied.

The command name used here is the command definition's name, same as avSwitch, not the reference name.

Hi Mark,

There is no difference in the two commands, only how they get executed and how they receive the identifiers required to lookup the data. The lookup and display of the data is all identical.

The use case is allowing "drill down" capabilities from different parts of the application. From one "object" I can flow from credit information -> invoices -> individual timecards on the invoice. In another object, I can an go from how much a client has paid in federal unemployment tax -> transactions that make up that tax -> individual time cards that had the tax applied.

The way I have been thinking of this is that the "instance" command would use the avAssociatedInstance whereas the "object" command would use the uExecute CallerReference.

My thought then was to take the current command and turn it into a "Base" command and have two other commands extend it, one for the instance and one for the object. Each child command would only have to retrieve the reference object from the Framework and then use the base to handle the lookup and display. I think that if I uncheck "Show on Instance List Toolbar" the object command is effectively hidden from the user.

I think that will work, but ran into another problem trying at add a new command. viewtopic.php?f=3&t=1509

I did not think about trying to add to and select the instance list programmatically. That may be the last option.

Thanks,
Joe

It just dawned on me that I don't need multiple handlers.

You eluded to this

They can share the same command handling program, ...

I just need different command definitions and tweak the execute logic a bit.

The 'other' command might not even be part of the Timesheet business object - even though it might share some command code with it.
The 'other' command might belong to the Customer/Employee/whatever business object that is what is referencing it?

With regard to the missing command, that's a defect we need to look into ASAP.
Can you try this:

-> Reopen framework in workbench.
-> Check the command is still defined in Command definitions.
-> Check the command reference still exists in the business object.
-> Force a save or make a dummy change and resave to regenerate the VLF-ONE dat file.

Does that make the command missing problem go away?