the question is....
The application maybe in Silverligth.
It's possible to implement SYNChonous WebService call?
I try to realize any application RIA, with Grids, Edits and using WebServices in SL, but I do not understand how to make it's possible without a SYNC calls.
And I also need to use MODAL DIALOGS for some tasks.
I investigated the work of Daniel Vaughan who manages to run Web service calls synchronously, within a ThreadPool, but How I can do that GUI, wait for calls to webservices?
Daniel Vaughan Web: http://danielvaughan.orpius.com/post/Synchronous-Web-Service-Calls-with-Silverlight-2.aspx
Combining these basic things for other languages, IMHO is possible to build true application.
Hear suggestions...
Cheva.
Its best to analyse the actual objective which, since you want to do this in the GUI, is to prevent user activity until approriate resources have been fetched or processed.
One way to acheive that goal would be to have a synchronous call but the would just lock the UI up in a user unfriendly way. What we realy want is to lock the UI up but in an informative way. In fact we want the UI thread free to display such "Please wait I'm busy processing your request" preferable in a rich UI manner (some animation or progress going on).
To that you can use the BusyIndicator control (inside which you place all or just part of your current UI). You'll find the BusyIndicator in the Silverligt Toolkit. If you are using VS2010 and Silverlight 4 a Similar control is now part of the Ria Services SDK and can is called Activity.
Now when you want to do something "synchronous" you set the BusyIndicator.IsBusy property to true (in SL4 you set the Activity.IsActive to true). Then make a asynchronous request, on completion of the request you set the property to false.
For better or for worse, Silverlight doesn't support synchronous calls to web services. Your best bet is to go with something similar to what Anthony proposed in order to get the desired end result in your UI without actually locking up the UI thread.
Related
I believe I read somewhere that the order of when UI events are triggered in WinRT is arbitrary. I also believe I read that it differs from Silverlight and/or WPF, and certainly WinForms. It differs in the manner that in WinForms you can know for sure that for instance the Click event of a Button fires after GotFocus and so forth (example may not be correct). In WinRT you can not. I have done some crude testing myself, and it seems to be correct. Sometimes event X fires first, sometimes Y.
Can anyone please confirm these assumptions for me, especially with regards to Silverlight and WPF where I am not very proficient? Preferably with links to official Microsoft articles.
I believe this is an important concept to grasp, since it will affect what you can and cannot do in the event handlers - especially with regards to synchronizing with databound properties.
WinRT is a complete redefinition of the opperational model. Don't let those words scare you though. What this means is that where ever there used to be synchronous actions, they've been turned into async actions.
What this means though, is that you are correct in assuming that one event may fire before another. With the prebuilt WinRT controls, there is not much that can be done to sync the async, but with custom code, you could implement a call and response pattern.
I blog about the Event Aggregator which allows events to be published and subscribed to from anywhere in the app:
http://developingzack.blogspot.com/2012/09/what-why-and-how-event-aggregator.html
By creating a set of events, where the original event subscriber, publishes a second event and the second events subscription publishes a third event ... to the Nth tier.
This would also be a de-coupled way to create the illusion (and operational order) of synchronous methodology.
Every Method that might take longer than 50ms to respond has been re-written as async.
Here is a fairly detailed explanation of Async from the MSDN blog: http://blogs.msdn.com/b/windowsappdev/archive/2012/06/14/exposing-net-tasks-as-winrt-asynchronous-operations.aspx
Im writing an application that needs to get notified when a control in another application is clicked\invoked. How can i catch the click from my application?
Here are some more related questions :
Is UIAutomation can be a solution? is it working on unmanaged applications also?
Is the Spy++ solution works also on managed applications?
i'll be happy with any help.
You need to use Global Hooks, but in managed apps you can only set up Global Hooks for keyboard and mouse events. So you will need to write an unmanaged app to do this.
Here's a blog post where a MS guy discusses the internals of Spy++ which might be useful:
http://blogs.msdn.com/vcblog/archive/2007/01/16/spy-internals.aspx
Using the Composite Application Guidance tools from Microsoft, It seems as if there is no mechanism to allow you to query your modules ViewModels and ask if any of them have unsaved data. This is a problem because, and I'm guilty of this as well, you cannot stop the application from terminating when there is unsaved data...
I had thought about creating an interface called IApplicationEvents and have an event on there called ApplicationExiting. The thought being that each module can subscribe to the event and, when fired, can send back a "Cancel=true" or "Cancel=false" to say whether or not to allow the application exiting.
Curious to find out what others may have done in this instance, and to see what possible solutions there are in the community to solve this issue.
Thx.
There are a lot of choices here.
First off, I wanted to clarify a little nomenclature... typically your Views or ViewModels contained within your Module assemblies are the things with unsaved changes, not the Module itself. The Module is responsible for instantiating any views necessary at the start and contributing back to the shell during Initialize and that's typically it, so when you attack this problem, you'll want to focus on your views/viewmodels and not the Module classes.
Options off the top of my head:
Adopt a complimentary framework like Caliburn that has support for application events like this (as well as some MDI events like ViewClosing, that kind of thing). It has builtin support for Prism (http://caliburn.codeplex.com/)
Use a composite command. Your views or viewmodels will register themselves with a composite command elsewhere (CloseCommand, which you declare statically for your application) and every open view will have its CanExecute and Execute methods fired so that you can both vote in the closing of the application and also react to it, should it happen anyway. CompositeCommands are a feature of Prism. (See: Commanding Quickstart)
I think those are probably the most elegant. There's a few more options but these live in the best harmony with existing conventions.
Hope this helps.
So I'm planning on writing an application that is largely a windowless application. There will be windows for user interaction, but only at the request of the user. Otherwise the application sits in the system tray and runs a timer, executing some logic every minute or so. My question is this: As far as I can tell, I would put all the related logic in App.xaml.cs (starting the timer, executing the logic at each interval), but for some reason this seems wrong to me.
The app will have a system tray icon that users can interact with to get details, adjust settings, etc., but otherwise the app just sits there and does what it does. Is it appropriate to put all the code in the code-behind for the App.xaml class? I don't know why, but it seems as if I shouldn't, and there should be somewhere else, but I can't really think of anything.
I've never written an app like this before, hence my ignorance. Any advice would be greatly appreciated. Thanks.
James
Even with applications where most interaction is done through windows it's usually a bad idea to put all the code in the code behind. Interactions are often initiated eventhandlers in the code behind but you can put your code in classes you create yourself.
The same goes for applications that do not show a user interface most of the time. Most of the actions will be initiated from the App.xaml.cs but that doesn't mean all the code has to live there. You can encapsulate timers in their own classes that can kick off other code to do work for example. Divide your code up along lines of responsibilities, a window class does UI stuff, domain logic goes into other files etc. That will enable you to create more maintainable applications.
It doesn't sound like the code belongs there, and at most just a call to start the timers.
What does sound like a perfect fit for your issues, is the M-V-VM (Model - View - ViewModel) pattern. As you noteded, it also will 'feel' more correct then attaching logic to your code behind. Using MVVM you can separate your sparse UI into a View, and your code can exist separately in the Model and ViewModel.
I would recomend using the toolkit here, as it also contains good overview documents and a sample you can digest as you create your own solution. Laurent Bugnion has also released a MVVM starter toolkit that you could use to get started.
Also, here is some good stuff to get you started on actually setting up your controls in the system tray.
I don't develop too many desktop / Windows Forms applications, but it had occurred to me that there may be some benefit to using the MVC (Model View Controller) pattern for Windows Forms .NET development.
Has anyone implemented MVC in Windows Forms? If so, do you have any tips on the design?
What I've done in the past is use something similar, Model-View-Presenter.
[NOTE: This article used to be available on the web. To see it now, you'll need to download the CHM, and then view the file properties and click Unblock. Then you can open the CHM and find the article. Thanks a million, Microsoft! sigh]
The form is the view, and I have an IView interface for it. All the processing happens in the presenter, which is just a class. The form creates a new presenter, and passes itself as the presenter's IView. This way for testing you can pass in a fake IView instead, and then send commands to it from the presenter and detect the results.
If I were to use a full-fledged Model-View-Controller, I guess I'd do it this way:
The form is the view. It sends commands to the model, raises events which the controller can subscribe to, and subscribes to events from the model.
The controller is a class that subscribes to the view's events and sends commands to the view and to the model.
The model raises events that the view subscribes to.
This would fit with the classic MVC diagram. The biggest disadvantage is that with events, it can be hard to tell who's subscribing to what. The MVP pattern uses methods instead of events (at least the way I've implemented it). When the form/view raises an event (e.g. someButton.Click), the form simply calls a method on the presenter to run the logic for it. The view and model don't have any direct connection at all; they both have to go through the presenter.
Well, actually Windows Forms implements a "free-style" version of MVC, much like some movies implement some crappy "free-style" interpretation of some classic books (Romeo & Juliet come to mind).
I'm not saying Windows Forms' implementation is bad, it's just... different.
If you use Windows Forms and proper OOP techniques, and maybe an ORM like EntitySpaces for your database access, then you could say that:
The ORM/OOP infrastructure is the Model
The Forms are the Views
The event handlers are the Controller
Although having both View and Controller represented by the same object make separating code from representation way more difficult (there's no easy way to plug-in a "GTK+ view" in a class derived from Microsoft.Windows.Forms.Form).
What you can do, if you are careful enough. Is keep your form code completely separate from your controller/model code by only writing GUI related stuff in the event handlers, and all other business logic in a separate class. In that case, if you ever wanted to use GTK+ to write another View layer, you would only need to rewrite the GUI code.
Windows Forms isn't designed from the ground up to use MVC. You have two options.
First, you can roll your own implementation of MVC.
Second, you can use an MVC framework designed for Windows Forms.
The first is simple to start doing, but the further in you get, the more complex it is. I'd suggest looking for a good, preexisting and well-tested, MVC framework designed to work with Windows Forms. I believe this blog post is a decent starting point.
For anybody starting out, I'd suggest skipping Windows Forms and developing against WPF, if you have the option. It's a much better framework for creating the UI. There are many MVC frameworks being developed for WPF, including this one and that one.
According to Microsoft, the UIP Application Block mentioned by #jasonbunting is "archived." Instead, look at the Smart Client Application Block or the even newer Smart Client Software Factory, which supports both WinForms and WPF SmartParts.
Check into the User Interface Process (UIP) Application Block. I don't know much about it but looked at it a few years ago. There may be newer versions, check around.
"The UIP Application Block is based on the model-view-controller (MVC) pattern."
Take a look at the MS Patterns and Practices Smart Client application block which has some guidance and classes which walk you through implementing a model view presenter patter in windows forms - take a look at the reference application included.
For WPF this is being superseced by the prism project
The software factories approach is a great way to learn best practices