The current behavior of closing a ticket in Ticket View is that on the close command Samba reverts back to the POS Entity Screen (I did not check what it does for select/create ticket departments).
This is a semantically not correct behavior in the case that the ticket view has been invoked from a separate entity screen. A modal dialog should always revert back to the origin.
I was going to write this out in that thread but didn’t as it wasn’t really on-topic.
You have to understand the underlying infrastructure. The only modal dialog that exists (outside display message action, and framework dialog boxes) is the main presentation window.
Everything from actions to views are loaded on startup with their dependencies injected and resolved (sometimes lazily).
The presentation window has regions. When a view is activated it is presented in the specified region. The view never gets disposed. Show() and ShowDialog() are never called and as such, no way to specify an owner.
It’s not a WinForm application that just spawns a whole bunch of forms all over the place. I can’t imagine how sluggish SambaPOS would be if it had to build the view each time it was requested.
Thanks for the explanation and of course don’t make it sluggish :-). Anyhow I got it to work and always revert back to the originating Entity screen. There are now of course 2 ‘EntityScreenChanged’ events but mine prevails as it is luckily later. The only issue remains the TicketType but that’s only one scenario and can be resolved. I tried ‘SetActiveTicketType’ but this did not have the desired effect.
That is not always the case. I have a situation for my reservation setup where I have a booking (entity) screen. When the reservation is created (via the POS screen) I want it to return to the reservation screen to verify the info is correct. I do not want it to go back to the booking screen. But there are other entity screens that I do want to go back to the originating entity screen. And I have it set up to do that.
Please keep in mind that Samba is very flexible, to suggest a ridged expectation, would take away from some of Samba’s flexibility. It sounds like you have found solutions to your requirements. Believe me, I understand it can be frustrating at times when you expect it to work one way but in reality it does not. Then you spending allot of time (some nights staring at the ceiling) trying to figure out how to make it work the way you like. Because of the flexibility, usually a solution can be found.
Hehe … well I don’t look at the ceilings - I just use to miss the right junction when driving in my car thinking about a Samba implementation issue. Maybe I should phrase it differently to ‘Samba should provide the choice on which screen to show next’ before making its decision. The added complexity was that the screen shown was mine but the ticket type set was the one of the table entity screen. I tried then to set the ticket type with the ‘Set Active Ticket Type’ action but this action seems to be an inaction with no effect wherever you use it. Then I tried to create a ticket with a particular ticket type in a rule but this failed bc (as far as I know) there is no way to create such a ticket programmatically. I need this while it is created bc there are many rules fired when a ticket is created depending on the ticket type.
What I resorted to now is that I do the following in the 2 scenarios where the correct ticket type associated with the entity screen matters. I send 2 navigation actions. The first one immediately in the Ticket Closed event. This one is just cosmetic to make sure the table screen does not get shown. Then I invoke another navigate action in a delayed automation command action and with this I finally get the correct ticket type associated with the entity screen.
I know but I cant change it resp. set it before the ticket is created. I have rules which are dependent on the ticket type when the ‘Ticket Created’ event is fired. But it woks now using the above described scenario.
I wanted to share here the following a while ago but I have been enjoying an Internet free zone on a Philippine Island for a while.
I got the navigation without entity tabs working despite the strong desire of Samba to jump on screens that you don’t want to jump on.
I prefer this out of 2 reasons:
The user interactions follows always the same paradigm.
The entity screens only have one size (Full Screen versus Tabbed View).
Issue 1:
One of the issues is the ‘create new customer/edit customer screen’ which is neither an app screen nor an entity screen and thus you don’t get an event.
Thus if there is a customer search widget on the entity screen including the ability to edit and create then Samba will go back to Customer Search and in one case it went back to the Tables screen.
I solved this problem as follows:
I added an Entity Screen with the customer search capability and named it ‘Manage Customers’ (I added some capabilities).
The old one is still there including the mapping and I have put this on top of the sort order (the sort order is important bc Samba bases its navigation decision also on this criteria) before Tables. Only 2 of my entity screens still have a mapping - Tables and Customer Search. You need these 2 bc otherwise the select customer/select tables buttons on the TicketView are not enabled.
Bc of this I know that there is no possible way to get from another Entity Screen to ‘Customer Search’ and so if Samba tries to do this I catch the EntityScreenChanged Event and lead Samba back to where I want it to go. Issue2:
The next thing I did was that I set a local variable whenever a TicketView is invoked from an Entity screen. On ticket close I then navigate back to the screen stored in this variable - well you need 2 variables - one to know that there is an active navigation and one to store the name of the Entity Screen. Issue 3:
The next issue was related to departments. I would love to use only one but you need 2 if you need both the ‘Select Entity’ method as well as the ‘Select Ticket’ method. The 2nd department is associated with a different ticket type and so I want to get out of this department in order to stay consistent as soon as the user clicks on the ‘Main’ button. Thus I catch the AppScreenChanged event to change the department back to the first. But by doing this Samba will go straight to the Tables Entity in my case. You can’t prevent this but you can force Samba to automatically jump from this screen to the main navigation that the user wanted - thus the Tables view is shown quickly before the Main Navigation.
with no effect wherever you use it. Then I tried to create a ticket with a particular ticket type in a rule but this failed bc (as far as I know) there is no way to create such a ticket programmatically. I need this while it is created bc there are many rules fired when a ticket is created depending on the ticket type.