Is there any event that I can listen for that gets fired when an instance in the instance list is selected?
If I have multiple windows open and the user selects a different instance in the instance list, I need to update the display of another window.
VLF-ONE Instance List Selection Event
Re: VLF-ONE Instance List Selection Event
Can you elaborate on what the multiple open windows are?
eg: VLF command handlers and their containers - or something else you have created.
eg: VLF command handlers and their containers - or something else you have created.
Re: VLF-ONE Instance List Selection Event
I have two objects (Client and Time Card) open at the same time, so I have 4 windows displayed at once. The client object is your typical VLF-ONE object that is selectable from the navigation menu, the Time Card is not selectable from navigation menu. The only way to get to the Time Card is via the Client.
The user searches for clients using the appropriate filter and clients are displayed on the instance list.
The user selects a client from the instance list to view commands (summary, details etc.). One command is a list of invoices for the client.
When the user selects an invoice, I switch to the time card object. It has a single hidden filter that displays a list of time cards for the invoice. When the user selects a time card the time card details command is shown.
So I end up having four windows that are displayed all at once.
The problem the users were having however, is that when they selected a different client from the instance list, the time card windows are still open and displaying data that is not for the newly selected client. When the user selected another filter to use the client command window and the time card windows where still open. The open windows were confusing the users as they are now displaying stale data (i.e. data not related to the action they just performed)
So I need to either update the windows or close them and closing the windows seems a lot easier then updating them.
There are a couple problems to deal with here; first close the other windows when a filter changes and second, close the time card windows when the client selection changes.
Dealing with the filter change was easy enough to deal with using avSignalEvent.
Dealing with the list change is not so easy. What I was trying to do, is detect when the user selects a different client from the client instance list.
It would have been relatively simple if the avListManager exposed a "ItemGotSelection" event, but it looks like it only exposes a "ListCleared" event. With an ItemGotSelection event, I could pick it up the change in selection and broadcast another event in the "APPLICATION" scope with avSignalEvent. Each object in the application could listen for that event and handle it accordingly.
I was able to solve the problem be creating a custom instance list which could propagate the "ItemGotSelected" event and a custom framework manager to coordinate the business objects within the application.
This leads me to a couple suggestions that I will post in the suggestions forum.
The user searches for clients using the appropriate filter and clients are displayed on the instance list.
The user selects a client from the instance list to view commands (summary, details etc.). One command is a list of invoices for the client.
When the user selects an invoice, I switch to the time card object. It has a single hidden filter that displays a list of time cards for the invoice. When the user selects a time card the time card details command is shown.
So I end up having four windows that are displayed all at once.
The problem the users were having however, is that when they selected a different client from the instance list, the time card windows are still open and displaying data that is not for the newly selected client. When the user selected another filter to use the client command window and the time card windows where still open. The open windows were confusing the users as they are now displaying stale data (i.e. data not related to the action they just performed)
So I need to either update the windows or close them and closing the windows seems a lot easier then updating them.
There are a couple problems to deal with here; first close the other windows when a filter changes and second, close the time card windows when the client selection changes.
Dealing with the filter change was easy enough to deal with using avSignalEvent.
Dealing with the list change is not so easy. What I was trying to do, is detect when the user selects a different client from the client instance list.
It would have been relatively simple if the avListManager exposed a "ItemGotSelection" event, but it looks like it only exposes a "ListCleared" event. With an ItemGotSelection event, I could pick it up the change in selection and broadcast another event in the "APPLICATION" scope with avSignalEvent. Each object in the application could listen for that event and handle it accordingly.
I was able to solve the problem be creating a custom instance list which could propagate the "ItemGotSelected" event and a custom framework manager to coordinate the business objects within the application.
This leads me to a couple suggestions that I will post in the suggestions forum.
Re: VLF-ONE Instance List Selection Event
It sounds like the Client more or less ‘controls’ the Time card objects?
If the Client object was to broadcast a TimeCardClose event and a TimeCardShow events, either via VLF event or via your custom manager, in these situations:
• In the filters uTerminate method – signal TimeCardClose
• In the filters, when any client search is done – signal TimeCardClose
• When the default command handler’s uExecute method is run, signal TimeCardShow. This means that when the user clicks on new client in the instance list any active time card details would display the appropriate related details. Or maybe just TimeCardClose.
• In all command handler uTerminate methods (maybe) – signal TimeCardClose
If the Client object was to broadcast a TimeCardClose event and a TimeCardShow events, either via VLF event or via your custom manager, in these situations:
• In the filters uTerminate method – signal TimeCardClose
• In the filters, when any client search is done – signal TimeCardClose
• When the default command handler’s uExecute method is run, signal TimeCardShow. This means that when the user clicks on new client in the instance list any active time card details would display the appropriate related details. Or maybe just TimeCardClose.
• In all command handler uTerminate methods (maybe) – signal TimeCardClose