|
I have done quite a lot programming in C#. I just wanted to know about developing kiosk applications. Anyways thanks for your response.
|
|
|
|
|
Member 3657007 wrote: I just wanted to know about developing kiosk applications.
Did you try this[^]?
I must get a clever new signature for 2011.
|
|
|
|
|
I've been using the Mediator pattern for a while in MVVM - specifically using the MVVMFoundation implementation mostly.
So this pattern allows you top broadcast a message that can be subscribed to by one or more classes (usually ViewModels) and handled by them.
What I am trying to do at the moment is extend this pattern as follows (an example is worth 1K words)
Customer Lookup allows user to select a customer, and will open an 'Edit' window for that customer. The window is not opened modally.
The user, then, can select the same customer again for editing (because the user is daft).
So I would like the Customer Lookup Vm to send out a 'This customer has been selected' message, to which the Customer Edit VM would subscribe.
If , as a Customer Edit VM I receive the message, and I am currently editing that same customer, then I can take some action (show a 'Silly User' message for example).
If I receive the message and I am not editing that same customer, I can ignore the message.
But if the message is sent and ignored by all VMs out there (because there isn't one editing this particular customer) then I need to get a new Customer Edit VM created to go edit this customer.
Now, I'd like to do this reasonably generically, so I started looking at the Messanger class, to see if I can't add to it, to enable 'IsHandled" type properties. And it works well.
Except!
My Customer Lookup is the first VM instantiated, and so is the first Vm to register to receive the message - and so handles it immediately - without giving he other ViewModels a chance!
Obviously, sending the messages is handled in a loop - so I could reverse the order - but it may not be the last instantiated View Model that I want to handle a message.
Or I could add a 'priority' to the message registration process - and sort the responses in priority order, so that my Edit VMs see the message first.
Or, I could change the messaging into a two-step process - the first stage asks who can handle the message, and the second stage decides who to give the message to.
I guess what I'd like is to hear some discussion on this. Have you done something similar (is there some code out there I can steal look at for inspiration? Have you overcome similar problems some other way?
___________________________________________
.\\axxx
(That's an 'M')
|
|
|
|
|
Sounds like you would need a blocking "broadcast to everybody but x" and if e.Handled = false afterwards, send to x. Listener registeration is in indeterminate order, so you can't really depend on order to know who the fallback listener is.
|
|
|
|
|
If customer lookup is VM that is raising the message, why is it subscribing to it? The whole point is to allow disparate VMs to communicate with each other, so the originating VM doesn't need to be a listener. Perhaps I have misunderstood your scenario, but it seems like the fix is to remove the listener from the originating VM.
|
|
|
|
|
Hi Pete
The issue is (and bear in mind this is not a real application as yet):
If my VM Customer Lookup sends a message out to say "HEy, the User just selected Customer 123" then something needs to handle the message.
I possibly have not yet instantiated a Customer Edit VM, so don't know if there's anyone out there listening for the message.
My idea was to send the message, then if nobody handles it, handle it myself by getting a CustomerEdit VM instantiated to edit this Customer.
So the only reason the listener is there in the lookup is to handle the instantiation of a VM to handle the event.
I could (of course) have the VM keep a list of all the CustomerEdit VMs it has had instantiated, and compare any new selection against that list, only instantiating a new one should I need to - but that would require my Look UP VM having references to all of the Edit VMs.
___________________________________________
.\\axxx
(That's an 'M')
|
|
|
|
|
No it doesn't. The change you need to make to your messenger class is to see if there are any listeners for that message. Presumably it's in a dictionary internally, so all you need do is check the count of references against that message and react accordingly. In fact, that's such a useful modification that I am going to change my implementation accordingly. Thanks for the idea.
|
|
|
|
|
I don't know how to express my gratitude. It's so obvious now I don't know how I didn't think of it!
___________________________________________
.\\axxx
(That's an 'M')
|
|
|
|
|
Actually, I owe you gratitude. I didn't think of doing this, but now that I've put it in I can see how useful it is. You gave me the inspiration, so thank you.
|
|
|
|
|
Well, you know what they say about Inspiration and Perspiration...
Incidentally, I am also passing a Message object around with my messages. This object (amongst other things) allows each Message handler to report whether it has handled the message (and gives it the option to stop the message being sent to any other handlers.
so my implementation rather than returning an effective boolean, returns
MessageHandled,
MessageNotRegistered,
MessageAborted,
MessageRegisteredNotHandled
So , for example, I can send out a message to perform some action, but all of the potential handlers may be too busy, so I get a MessageRegisteredNothandled return value.
This is very much a work In Progress, so I haven't worked out all the ins and outs, but it seems to solve some of the potential issues I was worrying about.
___________________________________________
.\\axxx
(That's an 'M')
|
|
|
|
|
_Maxxx_ wrote: MessageAborted,
That's interesting. Something I've been struggling with myself for a while is whether the Mediator should wrap exceptions up, or just fail at the first instance. There are arguments for and against this, and I've been toying with the idea that the mediator should have a WorkResult object which includes this information. If I do this, then the status would be the enumeration, and the exceptions would be stored in there as well.
|
|
|
|
|
Great minds ... etc.
When I started looking into this sort of thing, the problems started to grow. For example, if a Message Handler throws an exception, and catches it, then stores it in the WorkResult object there are two choices - the Mediator aborts as soon as one handler throws an exception, or it continues to try any other handlers - and if they throw exceptions, do you start keeping collections of the damn things?
If the mediator itself gets an unhandled exception, then returning it to the sender might be a good idea - but then why not just leave it unhandled? it is, after all, an exception?
___________________________________________
.\\axxx
(That's an 'M')
|
|
|
|
|
Well, I've changed my implementation and I'm busy testing it out now. The reason I've been toying around with this idea is that in some cases I've wanted to have some VMs continue processing even when one has failed due to a SQL exception because I can handle this later on. This change could be useful.
|
|
|
|
|
It'll be interesting to see how it works out.
In these sort of cases are you trapping the exception in the VM and adding the info to the Mediator object, or do you leave the exception for the mediator to trap and log?
The reason I;m looking at all of this right now is that I'm writing an article (I say AN article, it's likely to be a series of about twenty the way I'm going!) about they way I'm doing MVVM
As usual with this sort of thing, as soon as I start to describe the whys and wherefores, I think of additional things I'd like to do, and the whole thing expands and expands...
The good thing is that I end up with a good, well thought out "framework" - I just will have to draw the line in the sand somewhere!
___________________________________________
.\\axxx
(That's an 'M')
|
|
|
|
|
_Maxxx_ wrote: In these sort of cases are you trapping the exception in the VM and adding the
info to the Mediator object, or do you leave the exception for the mediator to
trap and log?
It really depends. I'm a great believer in trapping and handling errors where you can. In some cases though, I want the exception to bubble upwards - but because of the loose coupling between the VMs, I want to still allow the others to continue. In this case, the result is acting almost like a mediator message in its own right - the mediator becomes aware of the exception, but it can still continue.
|
|
|
|
|
To give you an idea, this is my implementation now:
public NotificationResult NotifyColleagues<T>(T message, object args)
{
NotificationResult result = NotificationResult.Successful;
lock (SyncLock)
{
if (internalList.ContainsKey(message))
{
if (internalList[message].Count == 0)
result = NotificationResult.NoListenersForMessage;
foreach (Action<object> callback in internalList[message])
callback(args);
}
else
{
result = NotificationResult.MessageNotRegistered;
}
}
return result;
}
|
|
|
|
|
Awesome!
If I keep giving you ideas will you write my whole App for me?
___________________________________________
.\\axxx
(That's an 'M')
|
|
|
|
|
So I have a silverlight app. The page can be referenced with arguments so when someone click on a link in another html page it starts up the silverlight app web page and works according to the arguments.
The problem is that the link on the other html page can be clicked again and it will also start up the silverlight app in *another* web page and work according to the arguments. Basically I can have two or more of my silverlight app running.
Is there a way to tell that second click that the silverlight app is already up and running and to accept these new arguments - without having to reset the entire silverlight app? I made it work where the existing app starts over again (it doesn't look good that way), but I just want the app to respond to the new arguments passed in by the link clicked on the html page. Is that even possible?
Thanks
Brent
|
|
|
|
|
As there is no method for an SL app to receive data from an aspx page (except the initial parameters) then I don't think this is possible.
Caveat, I'm fairly new to SL so don't take this as a definitive answer.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: there is no method for an SL app to receive data from an aspx page
Pretty sure that's not correct. See my answer below.
|
|
|
|
|
AspDotNetDev wrote: Pretty sure that's not correct
Therefore the caveat, interesting looking article, it does imply there can be an interaction between the 2 spheres after the SL app is created.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Would you want a browser plugin that could hijack the default behaviour of your browser? I wouldn't. If the app opens up in a new window, then how is this any different from having a hyperlink with a jump target on it? The SL runtime has to behave itself like any other browser component, so it has to respect the same airspace issues.
|
|
|
|
|
Not sure what you mean by "hijack the default behavior". Seems to me the OP is just building a web application and would like to have the second click act differently than the first click. More specifically, the first click should open a new window and the second click should interact with that opened window. Sounds both reasonable and possible to me (see my answer below).
|
|
|
|
|
So, sounds like you want the first click to open the Silverlight application in a new window, but you want the second click of that same link to cause the Silverlight app to change in some way. If that is correct, then that should be doable. I'm pretty sure you can pass variables from one window to another window opened by that first window using JavaScript. I am also fairly certain that you can interact with a Silverlight control using JavaScript, even after the Silverlight control has been created.
See here and here (note: I didn't read those fully, but they seem like what you are looking for).
|
|
|
|
|
Here's what I have tried.
I created another silverlight "application" which is merely a control that looks like a hyperlink. Then I can use the LocalMessageSender to talk to my main app and also talk to the web page that my "control" app lives on.
The only problem left is that typically when a page changes, the tab in the browser flashes or goes red (at least this is the behavior in IE). This doesn't happen here. The user has no clue that anything happened until he goes to the main silverlight app page and everything shifts. It appears that the main app doesn't run the Message Received event until AFTER the tab becomes active again.
Brent
|
|
|
|