As I was developing the interface for my current project, I came to the realization the WPF has built-in spellchecking available for TextBoxes, etc. I don't know why this surprised me, but it did. Perhaps because I'm quite used to Winforms, which did not include spellchecker functionality.
I was completely unaware of this, and more importantly, a little stunned that I never even noticed such a feature being loaded at runtime. You would think that loading the word list would incur some sort of startup-time limitation, given that the built-in dictionary is apparently pretty good; I tried to test it's capabilities and it offered words that I didn't even think would be within a standard dictionary.
So essentially, I'm really just wondering how such a feature is initialized at runtime. How does WPF handle loading the words? Does it defer the loading off to, say, the windows environment when the computer is started up? Does it load the dictionary every time the application is started? Is said dictionary located at some sort of accessible level on disk so that I can take a look at it?
WPF uses COM interop to take advantage of spell support built into Windows. It does depend on what version you have. For Windows 8 and up it uses documented api. The spell checker is done by ISpellCheckerFactory and friends, implemented by c:\windows\system32\MsSpellCheckingFacility.dll. And it calls in the help of a WinRT class to break up a sentence into words, Windows.Data.Text.WordSegmenter gets that job done.
Neither of those components are available on Win7 and less, it then falls back to a COM service implemented by c:\windows\system32\NaturalLanguage6.dll, ILexicon is the main interface. That one is not documented by Microsoft, but visible in the reference source.
Related
I realize someone asked a similar question here but I think my question is from a different vantage point and I hope it might help people in the future understand their options.
Basic issue: I have written a C# App (obviously managed) as a normal application (non-universal) and in order to support a quick log window above an active typing area, I initially wrote some graphics using pure .net (GDI I believe). This worked initially but it became VERY slow sometimes and I want way better control over how it looks including some specialized graphics.
What I would like to do is rework the app AND find out which of the following makes the most sense for a Windows 10 Universal Application:
Call DirectX Directly from C# (from documentation this is either not-possible or not really ideal, base project for C# does not have directX like C++ does).
Call Managed Libraries from C++ and use DirectX as the Application Foundation.
Use C++/CLI and call managed code. (I believe this is not possible anymore).
Use SharpDX (I looked and it didn't seem available based on a question here).
Use another Third Party (such as Unity) but deal with game frameworks.
Other parameters: Since everything is C# already, would like to avoid total rework, however, if it's recommended I'm 100% ok with doing so. This is not a game application, though it needs performance like one on one of it's screens, it will mostly be driven by interfaces (could be XAML) and network data coming in on a separate thread. I also have no qualms about learning extensively (say a very different language from C# or C++) in order to complete this project because learning is value. If I am missing something glaringly obvious that would be great to know about it as well.
I have been exploring reinventing the DataTable and I am wondering what the uses are for MarshalByValueComponent. I believe it is used for .NET Remoting (maybe WinForms and WebForms), but that was replaced superseded by WCF. I cannot find any notable usages of it across GitHub or Google. Is MarshalByValueComponent still used?
This is hard to answer. The entire concept of wanting to remote a component is a mystifying one. These design decisions were made 13+ years ago and clearly they had a very different idea of how remoting was going to be practical. Which didn't pan out that well, heavily re-engineered in .NET 3.0
Just noodling about this a bit without knowing the thinking behind it. MarshalByValueComponent exist as the antipode to Component. Which inherits from MarshalByRefObject. By far most components and controls are not serializable, they have way too much runtime state associated with them that can never properly deserialize in another runtime environment. Take an OpenFileDialog, the odds that a verbatim copy of it on another machine can operate correctly are zilch. Again having to suspend the wonder at why you'd want to do this at all. Same for any Control, it has dozens of properties whose value depend on the operating system state.
But MBRO isn't that desirable, the many round-trips take a heavy hit from network latency. There are a few components that don't have runtime state and still make a bit of sense in a remoting scenario. That they are a component is in itself a quirk, it's been a long time since I dropped a DataSet on a Form. But they inherit MBVC as a result. Just ignore this, it isn't practical.
I have a .NET 2.0 application. What I want to do is create a plugin that has access to the main application in some way.
My reason is that I want to be able to add things like buttons and menu items to a form dynamically instead of having a menu item called "Plugins" that I update. This is so that I can add things to the application GUI without releasing the entire application again.
Right now I can think of two ways. One, I can create the plugin in such a way that it always expects a reference to the entire application, all forms included. I can give it access to whatever items I chose in the forms and it can add controls or whatever at will. This makes me a little uneasy, but if this is acceptable let me know.
The other way I can think of is to have some sort of Interface for each form in the main app such that I can use that interface to access the current forms in the app. I am not sure how to implement this, though.
All help, suggestions, website references and comments are appreciated.
Partly this comes down to who will write your plug-ins, do you trust them, and what happens to the user's experience or data when a plug-in goes bad?
Fiddler http://www.fiddler2.com/fiddler2/ is a Web Debugging Proxy that has a plug-in model very much like your first choice - expose everything to the plug-in writer and hope they don't screw up. This makes writing extensions to Fiddler very simple, but it does mean you need to be careful.
If you're unhappy about this approach I would suggest you take a close look at 2 .NET technologies that might help.
The first is the System.AddIn namespace http://msdn.microsoft.com/en-us/library/gg145020.aspx. The types in this namespace are designed to help you create applications that support AddIns.
The second is MEF http://mef.codeplex.com/. The Managed Extensibility Framework is a very powerful API for describing an applications requirements, and allows you to build highly extensible applications.
With regard to MEF and WinForms check out this SO question:
Winforms with MEF
The second approach would be preferible, you could create an interface IApplication with all of the modifyable / pluggable parts of your appilcations and require that all plugins implement and IModifyApp interface with some method like IModifyApp.Modify(IApplication) that takes an instance of the IApplication and returns a modified instance for the application to process.
You should also check out MEF The Microsoft managed extensibility framework.
What I have done before for this kinda scenario is used AppDomain. Which is like a process inside your main process. You can load and unload assemblies in the AppDomain w.o having to stop the main process and as long as your main process knows about interfaces loaded from the "updates" dll inside the AppDomain, it can consume it no problem. If not, then there are always reflections :)
You may want to give a look to something like CAB/Prism to address your needs. A lot of the UI-y-ness (technical term) is built in to that through a series of abstractions.
http://compositewpf.codeplex.com/
Okay, I'm biting the bullet and deciding to get into the whole Microsoft/C#/.NET culture and I'm going to do this by putting together a simple (hah!) application.
It will basically be an application in which I want to store images and associate with them other optional things.
It must be able to import images from the filesystem (and hopefully camera/scanner) then allow the user to add text, audio and other information.
I plan to store the images and auxillary information into a database. What the application will do with said data isn't important (yet).
Keep in mind I know absolutely nothing about C# or .NET although, as an old codger, I know a great deal about many other things and will regale/bore you with stories and anecdotes until you quietly slip away :-)
What are the first steps to take in developing such an application? I've already set out UI layouts and likely process flows although it may be that the development environment dictates changes.
Development environment is currently XP SP3 + VS2008 (though I can upgrade if absolutely necessary).
What should I be looking at as the first step? Are there any gotchas I should be looking out for?
Have you decided for win forms or WPF? I've been doing win forms for the past 4 years and WPF was a great discovery for me, with the flexibility it affords. It might be fitted for your application and the different types of content you'll want to add and give you a flexibility that win forms can't give.
As for actually developing, I think loading images from the disk would be the first step, showing them in the UI and getting user input for them - you would get to work with the different objects and see how the framework handles things.
A tutorial about the field validation I mentioned in my comment is here - haven't done it, but something similar. You can also see the xaml code paired with the C# code there.
After looking for the differences between win forms and WPF I found that there are a few win forms controls that are missing from WPF. More on that on MSDN (compariosn chart) and a post from March with a more detailed chart.
It's also worth mentioning that you can include win forms controls in WPF applications and vice versa, but there are some limitations.
Just a couple of pointers, it would be easy to overwhelm you as you are just starting with this tech stack. First step, use SQLServer 2008 Express, it has better ability to deal with image data (images can be saved directly to the filesystem, but they are still in a table).
Apart from that, you can design your screen with the GUI, and then hook the bits up one by one to your retreived data. Create a new Windows Forms app, or a WPF one, and start from there (i'm assuming that you know about the toolbox window and just dragging components on to the designer and setting their properties in the Properties window).
If you're looking win forms you're going to have drag-and-drop UI pretty easily.
If you want to use a database than you're probably going to find MS-SQL the easiest to cooperate with. Look up LINQ-2-SQL, it lets you access your database through an object layer by simply dragging your tables onto a pane.
Fun things to use: extension methods, partial classes, LINQ (query any collection with inline lambdas) and even class/method attributes.
My $0,02:
a) Get to know the platform a bit, types, collections, events/delegates(/lambdas), etc etc
b) Dive into WPF
c) Learn about database connectivity (LINQ2SQL or NHibernate (or ....)
d) Learn about the MVVM pattern to get to deliver solid wpf applications, doing so forces you to dive deeper into the workings of WPF (routed commands, tunneling/bubbleing etc)
e) Learn more about patterns to get a more solid grasp of OO (this: http://www.amazon.com/Design-Patterns-Explained-Perspective-Object-Oriented/dp/0321247140/ref=sr_1_1?ie=UTF8&s=books&qid=1276066663&sr=8-1 is an absolute pearl for that)
f) etc
If you aren't too desperate to get your hands dirty straight away I'd suggest this book: CLR via C#.
It is written for those with programming experience on platforms other than .Net and provides a clear and comprehensive explanation of C# and how it runs on the .NET CLR.
By reading this initially you might avoid writing some of the poorly constructed applications that many of us wrote before properly understanding the technology.
Buy a book on C# & .NET FW fundamentals!
Read! :-)
Read good books about .NET for example CLR via C#.
Read this:
Hidden Features of C#? https://stackoverflow.com/questions/380819/common-programming-mistakes-for-net-developers-to-avoid
I'm trying to add plugins to my game and what I'm trying to implement is this:
Plugins will be either mine or 3rd party's so I would like a solution where crashing of the plugin would not mean crashing of the main application.
Methods of plugins are called very often (for example because of drawing of game objects).
What I've found so far:
1) http://www.codeproject.com/KB/cs/pluginsincsharp.aspx - simple concept that seems like it should work nicely. Since plugins are used in my game for every round I would suffice to add the Restart() method and if a plugin is no longer needed Unload() method + GC should take care of that.
2) http://mef.codeplex.com/Wikipage - Managed Extensibility Framework - my program should work on .NET 3.5 and I don't want to add any other framework separately I want to write my plugin system myself. Therefore this solution is out of question.
3) Microsoft provides: http://msdn.microsoft.com/en-us/library/system.addin.aspx but according to a few articles I've read it is very complex.
4) Different AppDomains for plugins. According to Marc Gravell ( Usage of AppDomain in C# ) different AppDomains allow isolation. Unloading of plugins would be easy. What would the performance load be? I need to call methods of plugins very often (to draw objects for example).
Using Application Domains - http://msdn.microsoft.com/en-us/library/yb506139.aspx
A few tutorials on java2s.com
Could you please comment on my findings? New approaches are also welcomed! Thanks!
You can define a public interface which the plugin's must implement. Then with the use of reflection you can scan a "plugin" folder for any classes implementing that interface, then create an instance of that class.
From you're code just work on the interface and call the needed method's. About crashing, always make sure that calls to the "plugin" interface are always encapsulated in a try/catch block. If an exception occurs you can always dispose the plugin
I suspect your two requirements of:
fast performance with drawing objects and
a plugin crash would not crash your app
are going to conflict.
To really ensure a buggy plugin doesn't crash your app, you have to load it in a separate AppDomain (as you've identified already). But you're going to take a performance hit, as the whole point of AppDomains is they isolate instances of objects. So you're, at minimum, going to have to serialize arguments to your plugins (possibly using MarshalByRef objects or Remoting). And I suspect that will mean serializing a good chunk of your game state (which sounds like it at least consists of some sort of image). On the plus side, AppDomains live in the same process space, so the overhead isn't as bad as cross-process communication.
Unloading plugins is as simple as unloading the AppDomain.
Because you have to serialise arguments, you can do validation of your game state after the plugin processes it.
I did some toying with AppDomains once. It takes a few seconds to construct one, in my experience. That may affect how many plugins you load into each AppDomain.
The generalized "secrect" to .NET extensibility is: Dynamic loading (to get the plugin into the AppDomain), Reflection (to verify it supports the methods/interface you specify), Attributes (to get Meta-Data for things like versioning), Late Binding (to actually use the plugin).
If your extensibility needs are very simple, or very unique, you should consider implementing it your way.
I used this tutorial as the basis for my own plug-in architecture a couple of years ago. My architecture was, I believe, a relatively simple architecture, but I hit some problems when it came to passing messages between plug-ins.
If you're intent on writing your own architecture, then fair enough, but I would warn against it. It's no small undertaking, and sooner or later you're going to run into some major design considerations, like message passing, which are non-trivial to solve (if admittedly simultaneously quite interesting and frustrating). There is a tremendous amount of value in using something like MEF that solves these problems for you, and provides a really nice API and framework upon which you can build you plug-ins.
Furthermore, MEF will end up being distributed as part of your application, so you don't need to get your users to download it separately; it's an "invisible" dependency as far as they're concerned, and a light-weight one for developers, including yourself. It's also the official plug-in architecture for Visual Studio 2010, so it has a lot of weight in the .NET community, and there will only ever be more developers able to write plug-ins for your app if you use it too.
Hope that makes some sense.