In my win forms C# app, I want to be able to add spell check functionality. But, I want to do it my own way, and NOT use any other components. All I need is just an online service where I can send a request or something and it tells me whether or not the word i sent was spelled correctly.
Preferred but not required: The ability for that online service to also send back suggestions.
Personally, I wonder why you want only online access...what if you lose connection? Also, most online accesses come with restrictions.. which you might hit sooner than you think during debugging.
If you were to use WPF, I'd suggest using the SpellCheck Class.
Since you specified Windows.Forms, you might try the NetSpell library for offline access. You can also try and use Microsoft Word's spellchecker, but you might not have it installed on the machine (or use Linux & Mono)
If you persist on using online access, you can use Yahoo, as Giovanni Galbo says. It's been done in C# before.
A quick google search turned up this:
Search Web Services: Spelling Suggestion
This is not c#/.NET specific. Its a simple REST service provided by Yahoo!. It looks like they do limit you to 5,000 queries per day for free and I'm not sure if Yahoo! lets you upgrade to a pay service.
Related
I would like to know how can I access some web application from my personal project in C#?
To be specific, I would like to access this website https://dictation.io/
In my console app in VS record speech from my mic then pass it to that web app and then returns in my app result as e.g. string.
If someone could give an advice, it would be really fine (not looking for exact code)
Thank you!
Typically, accessing external resources (such as Dictation.io) would require an API. As they don't offer one, there's no (legal) way to use their speech-to-text.
Instead, you can build your own using Microsoft's own libraries and APIs. An example, and probably your best bet, would be https://msdn.microsoft.com/en-us/library/office/hh361683(v=office.14).aspx
I am trying to integrate my IM-client, written in C#, with MS Outlook 2013. I would like Outlook to receive presence information from my IM-client. First shot was to use this instruction.
It worked well in the beginning (Outlook get my interface, check for version and features, abilities to start conversation), but in the chapter "Retrieving contact presence" I've got a difference. Outlook didn't call "GetContactInformation" as described. It isn't work for neither interface returned for version "15.0.0.0" nor "14.0.0.0".
I've tried to turn on logging using OfficePresenceLogging, but it appeared to be available only for previous versions of MS Outlook. So, I used this technique, which gave me binary file "Microsoft Support Engineer has the tools to analyze".
Since I use Windows 8.1, LorParser 2.2 unable to read this file, and TraceRpt.exe is only able to give me metadata (like time or Process ID). The important part of the log is hidden beneath BinaryEventData field. I could translate those hexes to ascii and see something like a methods names and garbage.
I wonder if someone could advise me something:
Is it possible to read Office 2013 logs to troubleshoot my IM integration?
Is there any hints that could I check to find a problem?
I come up with some solution, so I want to write down an answer. I hope it can be useful for someone.
Unfortunately I failed to read Outlook 2013 logs in both Windows 8.1 and Windows 7. The only solution I've found: test the application with Office 2010 (it uses text logs). You can find instructions how to turn on logs at the end of this article.
In my case the first error I've got was:
"CMsoProviderOCom::HrEnsureContactAndGroupManager !failed! Line: 3998 hr = 0x80040200"
It seems Outlook reject all further information if something went wrong at the beginning of the integration with IM.
Check your application returns all correct values for the methods Outlook uses.
Check you've implemented all events, it seems impossible to find lack of them with debugger.
Take a look at Lync SDK. It has the similar interface (Microsoft.Lync.Model) and it's documentation looks more complete.
In my case I just forgot to mark couple of my classes with [ComSourceInterfaces()].
Windows 8 store apps can register the type of protocols they can handle. This works great for apps that can handle web URLs (Http....) or email apps (mailto:...), etc.
A lot of apps also specify their special protocols. For example, the Windows store handles "ms-windows-store", and you can, for example, launch the app and search with
ms-windows-store:Search?query=hello
My question is whether anyone knows the format that the msft video app uses. It's activation protocol is "microsoftvideo:", but I haven't been able to figure out what (if any) format of inputs it takes. For example, the following does NOT work.
microsoftvideo:Search?query=hello
As a second question, does anyone know the formats available to other popular apps? I can launch Netflix with "netflix:", but haven't been able to figure out if I can search right away as well.
Thanks.
First of all, please read StackOverflow similar question: link.
Without registering any name, Package Family Name can be used to execute another app.
Please kindly read MSDN link.
And, about naming protocols which is called URI scheme, please kindly read this MSDN link.
And, about the ?query=, I think you may not intend Search Contract. In this case, you may not know unless they(developer of another app) opened the information because it is defined by own.
I want to interact with a Photoshop file and create images using its actions and smart objects.
Is there any php or C# API to can do it?
First of all, I would like you to reflect on the legality of such a thing. Would Adobe let you practically just proxy their application to the web? I see they have a lot of licenses so maybe one of them actually grants you permission to do this (however, there could still be caveats so I suggest you read up on that). As that's not the question, I won't talk about this anymore, I just wanted to to mention it as it should be relevant.
Now, for the actual question - if you look at Microsoft Office Interop, Microsoft states that it is unsupported in a server-side environment. Go to this Microsoft page and read Problems using server-side Automation of Office in the More information section.
There are several issues if you decide to run a regular client application server-side, as stated on the mentioned page, but one of the most significant issues is the following:
Interactivity with the desktop:
Office applications assume that they are being run under an interactive desktop. In some circumstances, applications may need to be made visible for certain Automation functions to work correctly. If an unexpected error occurs, or if an unspecified parameter is needed to complete a function, Office is designed to prompt the user with a modal dialog box that asks the user what the user wants to do. A modal dialog box on a non-interactive desktop cannot be dismissed. Therefore, that thread stops responding (hangs) indefinitely. Although certain coding practices can help reduce the likelihood of this issue, these practices cannot prevent the issue entirely. This fact alone makes running Office Applications from a server-side environment risky and unsupported.
While this is written by Microsoft for their product, these are more or less applicable to any regular client application. And even if you still decided to go with this approach, as Neville K already suggested, it would be a very resource-hungry task.
Considering the above, I would maybe ask a different question, along the lines of "What library or server-side app to use for doing whatever you need to do with images".
Based on this link, you can do this things with Photoshop SDK:
"With the Photoshop SDK, you can enable your apps to drive and/or communicate with Photoshop CS6 (version 13.0.0 or later) via a TCP connection. It’s now possible to create an eBook of Photoshop tutorials that allows users to drive actions in Photoshop CS6 from within the eBook"
This sound like hard but some companies seems to make it work. Xee can read PSD too (and has an epic comment about this format in the source code).
But to quote someone over at HN:
PSD was never intended to be a data interchange format: it is the
serialization format of a single program that has more individual
unrelated features that actual people rely on than almost any other
piece of software and has maintained striking amounts of backwards
compatibility and almost unbroken forwards compatibility during its
over two decades of existence. This product's "file format" needs to
be critiqued in this context, along with similar mega-programs like
Office. I am thereby having a difficult time fathoming why anyone
would think that a PSD file is thereby going to be some well-organized
file format that they should easily be able to parse from their own
application is just naively wishful thinking: even other products
from Adobe have limitations while opening these files; to truly
manipulate these files you really need to be highly-compatible with
Photoshop's particular editing model (hence the conceptual
difference between these two classes of file format).
I would recommand to look at Xee for a server side utility.
Good luck.
You can use the scripting interface to kick off "Shell" tasks from any web language if you really want to.
However, I'd seriously worry about this approach - the memory requirements for Photoshop are such that you could only support a couple of users, and you'd need a fairly complex polling mechanism to check for the results of the "shell" task. Photoshop was simply not designed to power web sites in this way.
Consider using graphics libraries instead - I've used ImageMagick with great effect in the past.
Heed the warnings that you really can't process more than 1 or 2 images at a time with photoshop without crashing your server, so just putting it on your webserver is a non-starter. A lighter weight image library is much better for most tasks.
But you could queue up jobs from your web application and then process them on another computer, or limit it to just one at a time.
Adobe has macros and a full action/javascript based scripting environment that you could kick off from commandline or com.
Adobe Scripting Guide
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/photoshop/pdfs/photoshop_cs5_scripting_guide.pdf
For older versions of photoshop you can use the macro functionality to Record an action. Then, create a droplet from the action. Call the droplet from the command line with an image file as the sole parameter. The path to the image file probably needs to be an absolute one.
Greetings,
I'm sorry if this question has been asked already. I've tried using the search function but couldn't find any answer that suited my situation.
I have a real simple C# form application of only 1 file, a exe.
I distributed this currently by 4shared where people can download it as pleased.
However, every time I make changes to the program people will have to download the new version from 4shared.
Now this isn't a ideal situation and I'm a noob when it comes to creating upgrade but the situation I wish is that the program looks at a website / ftp server where I deploy a new version.
I'm looking for a way inside my program to look at the file on that website / ftp server and decide wether there's a new version available.
If there is a new version available in the website / ftp server I would like for the program to update itself to the newest version.
Hope you guys can help me out with this and I hope I explained my situation enough !
NetSparkle is a nice alternative to click-once with more deployment options. http://netsparkle.codeplex.com/
Have a look at ClickOnce. It will do this for you.
When I'm developing and publishing such applications, I usually do it the following way:
Develop a .NET Windows Forms application
Develop a tiny ASP.NET application with an ASMX web service.
Publish the ASMX web service to my public web site.
Add a WSDL reference for the web service to my Windows Forms application.
Create a setup (I prefer Unicode NSIS over ClickOnce).
The logic I implement in the SOAP web service is basically a single function:
[WebMethod]
public string CheckUpdateAvailable( string currentVersion )
{
...
}
The Windows Forms application calls this method (e.g. from a background thread upon program start), passing its current assembly version as a string to the function.
The WSDL function in turn checks the passed version against the newest setup version (e.g. being stored inside web.config or extracted live from the setup.exe on the server). If a newer version exists, it return a string with the URL to download from; otherwise it returns NULL.
When the caller of the WSDL function gets a non-NULL string, it can show a message to the user, asking whether he wants to download and install the executable and then simply execute the URL (via Process.Start).
WyUpdate is the way to go here. We've been using it for over a year with great results (they have excellent support too).
It actually uses patches to update files so that when a 5MB executable only has a small change, the client only has to download a file in the order of kilobytes.
They supply an automatic update component for either Windows Forms or WPF that looks nice and works great.
You can host the update files on either an FTP server or a normal website without any server-side configuration.
There's plenty more to it, and the best place to start is with their video tutorial of how to set up an update.
Here's an open-source library I wrote to address specific needs we had for WinForms and WPF apps. The general idea is to have the greatest flexibility, at the lowest overhead possible. All you'll have to do is create an update feed and reference the library from your app.
So, integration is super-easy, and the library does pretty much everything for you, including synchronizing operations. It is also highly flexible, and lets you determine what tasks to execute and on what conditions - you set the rules (or use some that are there already). Last by not least is the support for any updates source (web, BitTorrent, etc) and any feed format - whatever is not implemented you can just write for yourself.
Cold updates (requiring an application restart) is also supported, and done automatically unless "hot-swap" is specified for the task.
This all boils down to one DLL, less than 70kb in size.
More details at http://www.code972.com/blog/2010/08/nappupdate-application-auto-update-framework-for-dotnet/
Code is at http://github.com/synhershko/NAppUpdate (Licensed under the Apache 2.0 license)
I plan on extending it more when I'll get some more time, but honestly you should be able to quickly enhance it yourself for whatever it currently doesn't support.