The initial release of the Chilkat plugin had a minor SNAFU – all property setters were not working. This was due to an issue in the code generation (the internal Chilkat tool that generates the actual plugin source code, which is the wrapping around the existing Chilkat class implementations).
The new build at http://www.chilkatsoft.com/xojo.asp is available. The ARM sub-part is still in the process of building, and Chilkat update again later today.
Please note that this is technically a pre-release of the next Chilkat version (9.5.0.56) and should be considered Beta until 9.5.0.56 is officially released in early March.
I don’t know the answer to your question because I’m fairly new to Xojo. If the Xojo plugin SDK (meaning the C++ code that is located under the “Extras/PluginsSDK” directory) is valid for the older Real Studio, then it should work with it.
PS> The new build containing the ARM fix has been uploaded…
I’ve been using Chilkat for a couple of years now with .Net. I think more than a few of us would like to say welcome and thank you for adding Xojo to your many supported languages.
The plugin is very welcome. Have been using the Objective C version before but the declares were annoying. The documentation is very good with nice examples. I was able to convert from Objective C to the Xojo version in a couple of hours.
One small nitpick: the installation confused me a bit. A single file would be easier to use - especially the first time.
Thanks Trixi, I answered your post on the Chilkat forum, and I also received an email about the same issue. (I’ll have to test with an empty “subEmail”…)
Nitpicks are welcome!
I don’t claim to be a Xojo expert where I know what is customary, so my choice for installation might be unorthodox – but I’m willing to change things as I gain experience. What do you mean by “a single file”? The intent was to provide the .zip (which is never to be unzipped by the way). After the user downloads, he/she just changes the extension from .zip to .xojo_plugin, and then copies that single file to the Plugins directory.
(Maybe the convention is to download a .zip and then unzip to get the .xojo_plugin – but a .xojo_plugin is really just a .zip with the file extension changed – so in effect it’s just a .zip re-zipped…)
I don’t think that anyone else besides the plugin authors know that the plugin is a simple zip file. Therefore a file with the ending “xojo_plugin” really would be better.
Should the setters work with the latest version? I can’t get setting a port to work.
CkoImap = new Chilkat.Imap
CkoImap.Port = 993
gives a Port = 0 in the debugger which then defaults to 143.
I updated the download and instructions so that “chilkat.xojo_plugin” is downloaded instead of the .zip
(I had to add a MIME time to the chilkatsoft.com IIS server to make it possible…)
The OAuth1 is interesting and not available in other plugins. Very useful for a lot of online services like Facebook, Twitter, …
Will check that one out very soon.
oauth is nothing special and I think we have it in one example project.
It’s just a rule on how to put data into a hash function to get back the hash for an hash.
Sascha, you sort of look like the green Chilkat dude!
Exchange Server (any version) can potentially behave as an IMAP server, POP3 server, and SMTP server. From Chilkat’s perspective, it’s essentially the same as any other IMAP, POP3, or SMTP server. (Exchange can also be the server-side for Microsoft-specific protocols (MAPI), and Chilkat doesn’t implement that.) Within the framework of the protocols, Exchange might use NTLM, and Chilkat can certainly handle that. There may also be gotcha’s with the login name – you might need to quality with a domain. See https://www.chilkatsoft.com/p/p_175.asp
Hi Christoph! I don’t know if an API for OAuth2 makes sense. (See this after reading the rest of my response: https://aaronparecki.com/2012/07/29/2/oauth2-simplified ) OAuth1 requires the client-side to perform various cryptographic computations which can complicated and tricky to get right. OAuth2 doesn’t require it. Although if a particular implementation uses a public/private key pair instead of a password, then you’d need to perhaps create an RSA signature. But in that case you would just use the Chilkat RSA API (or any other RSA API).
Anyway, the fact that OAuth2 leaves many decisions open to the implementor, and the fact that technically no cryptographic computations are involved, makes it difficult to think of what an OAuth2 API would look like…
One purpose of Chilkat’s OAuth1 API was to provide an inner look at the intermediate results of the OAuth1 computation. That’s why there are a number of different output properties. OAuth1 is, quite frankly, a real pain-in-the-ass and tricky to get right, and the worst problem having to do with debugging cryptographic problems is that your usually facing a “wrong answer” with N degrees of freedom (i.e. N inputs) and you don’t know which ones are incorrect. There are millions of possible combinations of inputs, and there’s now way to know if you’re getting “closer” to a solution – it’s an all-or-nothing guess. The purpose of the API is to provide a means for diagnosing the problems – to see which inputs are good/valid, and which might be suspect…
