Is it possible to use RoutedCommands such as ApplicationCommand.Copy, ApplicationCommand.Paste, etc in Silverlight 4 beta version ?
No, RoutedCommands are not supported in Silverlight although the primitive ICommand is. Silverlight 3 had ICommand but never used it anywhere. Silverlight 4 adds support to button controls to have an ICommand associated.
However, the full featured routed commands are not supported. They were not particularly useful in WPF anyway because they placed the burden of handling the command logic on the UI control that handled them. As it turns out, it is far more useful to have an ICommand exposed from the ViewModel.
Check out http://www.codeplex.com/compositewpf for the Prism project which includes some very useful classes such as DelegateCommand.
Having said that, commands like Cut/Copy/Paste are different from most commands because they are a generic command that usually applies directly to the control upon which it's executed. This is much different from a Save command for example which has a very specific meaning to the application behind the UI. For these clipboard related commands I'd say it's fine to break from the traditional separation patterns and write some UI-specific code in the code behind and use FocusManager.GetFocusedElement() to figure out which control you need to operate on.
Related
using Windows Forms it is possible to synchronize incoming data (like from events) which runs on another thread as that one which has created the form. However it is not allowed to update the form directly, therefore InvokeRequired and Invoke are used. Works great for me.
Now I want to move the logic part of my application (contains serial, networking, ... hence the threads) into a library. Also I want to have the synchronization in there, so there is no need to take care about that externally.
For now I create and pass a dummy form to my library, which is ugly, but works. At least some kind of. .Net Core has no Windows Forms. (3.0 has, but Windows only).
Even after reflecting the Form class I was not able to reproduce the synchronization process, so I could add it to my classes.
Does anyone know how to archive the same behaviour without Windows.Forms?
I use .Net Framework 2.0 and VB.Net, but C# examples are welcome as well
My question is about concept (I need some recommendation how to implement it right).
I've use MVC pattern when I build the UI,currently this UI serve two plug-in since the UI they should use are identical. so both plugin call to this UI and this is working fine.Now there is third(and four :)) plugins which should use some of the UI control and logic so instead of build new UI for this plugin's I want to provide some mechanism to enable to the user to decide which control he want to draw in the screen. so currently I need to break the view to sections but my question is what it the best way to do that ?
(from design and concept aspects)
The view is build from 6 controls that all the plugin must by default use two from them and the rest are optional . for example new plugin can use the mandatory two and provide in addition two more control.
Hard to answer without knowing the language and platform.
Each of your 6 controls you will have a view and controller. Each view/controller needs a reference to a model that exposes the data and methods appropriate for the view to display and the controller to call. So the question is how to connect up each plugin to the subset of the 6 possible controls.
In your case I would create 6 interfaces that expose the data and methods relevant to each of the 6 controls. Each plugin implements just the interfaces that are possible for that plugin. In addition it would expose a standard interface that all plugins implement. This standard interface would provide a list of the mandatory interfaces it requires shown, as well as the list of optional interfaces it allows to be shown.
Your master view then takes a plugin and asks for the list of mandatory interfaces. It creates those child controls and passed the relevant plugin interface to each of the child controls. It then looks at the optional ones are creates just two of them for display and hooks them up.
Hard to be more precise without more details.
You can try to use MVVM(Model,View,ViewModel) pattern, it's more convenient for shearing code, you can search in google 'MVVM', there are tons of articles about that.
I am working on a silverlight project and I am using MEF to download xap file of other silverlight project and use its pages and functions in my main Project.
I can do the same thing using referencing dll of that project into my main project.
So I want to know what is the difference between using MEF to reusing components and Simply Adding Reference to the DLL of another project in current project? I mean that we also add reference to the project we import in our current project. Then how it is different from conventional form of component use?
Thanks,
First, we need to separate MEF and PRISM (since you used it in your tags).
MEF is primarily used to provide inversion of control (IoC). It makes it easy to manage dependencies your viewmodels and other classes to separate concerns and improve testability (amongst other benefits).
PRISM however is primarily designed for the following scenario: You don't know, what view goes into a specific container at compile time, and want ViewA for CustomerA, ViewB for CustomerB and so on. PRISM helps you to losely couple your regions and views in a way, so that the application can decide at runtime, what view will be displayed. Another scenario, is that administrators get one view, other users another etc. PRISM also has other features (like the event aggregator), but I'd say the former is the most important one.
Now, I'd say MEF is never a bad thing to use for a bigger project. But I'd only use PRISM, if you really need the functionality it provides, since it can be very limiting. If you don't, simply add the references as you explained and let MEF know about those assemblies with the AssemblyCatalog.
So for MEF, I'd suggest you learn about Depdendency Injection and IoC. I found this blogpost by Martin Fowler quite good. As for PRISM, get familiar with what it does, and decide if you really need it.
Hope this helps.
Let me complement Lue's answer on the difference between MEF and referencing dlls a bit:
The two things are orthogonal activities, meaning that if you reference a dll directly you might still want to use MEF to detect the types in it - and vice versa you might grab a specific type in a dll you dynamically loaded directly (without MEF).
MEF basically finds types in dlls according to certain criteria and has a bit of convenience stuff in it to automatically populate properties and collections with such types. It can be used to make a system more decoupled and thus more maintainable. For example, a video editing software may look for all types implementing a certain interface in all known dlls to use as filters. Whether you include the filters directly as a dll or let the user download them on demand: In both cases your application becomes slightly cleaner by using MEF, since there is no hard-coded list of filters anywhere. Still, in the presence of dynamic library loading MEF is especially useful.
I intend to add a COM interface to an existing application (which, by the way, is written in C++ using Win32). I have some experience using COM objects, so I know the basic COM concepts of interfaces, etc., but this is the first time I'm actually implementing a component.
Ultimately I want to be able to use the COM interface to automate my application from scripts such as VB. I understand that there are two steps:
My application must act as an out-of-process server (i.e. I have to use MIDL and generate code for a proxy DLL and a stub DLL).
Once I have the server I can add automation capabilities by implementing the IDispatch interface.
Since the server-in-an-EXE thing with MIDL and what not is already a bit steep, I wanted to get a grasp on all that first before moving on to IDispatch.
I am reading the book "Inside COM" by Dale Rogerson and have completed the chapter on servers in EXEs (the following chapter will cover Automation).
The "Servers in EXEs" chapter provides example code that implements a server and a client. But it is necessary to start the server manually. This confuses me. Obviously, when my application (= server) is used by a client process, this extra manual step should not be necessary. Is there no mechanism to start the server automatically? Or is automation necessary to achieve that? At the moment, the prospect of having to start my server manually (once I even have one) makes me doubt I am moving in the right direction.
Hopefully someone with more knowledge of this can see what information I'm missing and point me in the right direction.
No, COM servers are not normally started by hand. Not sure why the book proposed it, possibly because it wanted to avoid talking about the registry keys you need to allow COM to automatically start the EXE. It isn't otherwise very complicated, you register the Application coclass of your app with the LocalServer32 key value giving the path to the EXE.
It is however not completely uncommon, especially with an existing program. One design decision to make is whether you let the client code completely control your program. Or if your program already has an existing user interface but you also want to expose services to other code. In the latter case it makes sense to let the user start the app by hand, like she'd normally does.
When your application is registered as LocalServer32, it will be invoked with the commandline specified there if no running process has registered a factory object for your CLSID yet.
This way, you can get the best of both worlds -- if the application is running already, this instance can provide the server side, and if it isn't, it will be started.
Automation is completely orthogonal to that -- your component becomes Automation compatible by implementing IDispatch.
I'm used to winforms development, haven't done any WPF and I'm starting a Silverlight project. I understand xaml and all (and I've got some resources for learning it) but I'm wondering if there's any resources available that shows what controls are used in what kinds of situations.
For instance, if you look at the BusinessApplication template in vs2010, they use a border or a grid in cases where I would think of a panel. Things like that.
I'm looking for more of a 'tips' kind of thing than a tutorial or reference. References normally just say what a control is; not when, where or why you would use a particular control.
These two should help you out...
http://samples.msdn.microsoft.com/Silverlight/SampleBrowser/#/?sref=HomePage
http://www.silverlight.net/content/samples/sl4/toolkitcontrolsamples/run/default.html