The project we were on used an older version of caliburn micro, we have upgraded to the current version and have found that the IWindowManager interface has gone! Even crawling through the codeplex/github sites and searching here I can find no details as how you are supposed to mimic its methods.
What is the current practice?
Regards
Caliburn.Micro.Platform might be missing in your references
WPF variant...
https://github.com/Caliburn-Micro/Caliburn.Micro/blob/master/src/Caliburn.Micro.Platform/net40/WindowManager.cs
codeplex source is horribly unreliable now since they moved source to GitHub, I wouldn't rely on much there.
Related
Am I correct in observing that Corda 1.0 is using Kotlin plugin 1.1.4? Just out of interest I tried to use 1.1.51 and ran into defaultWhiteList loading issues...although I'm not entirely sure why tbh...suspect classpath loading issues on the ServiceLoader.load in DefaultKryonCustomizer?? Anyway, when I revert to 1.1.1 (am still on M13) all is well again.
Just wanted to gain some understanding around why an inadvertent upgrade of the Kotlin plugin to 1.1.51 would cause issues with the serialisation default whitelist loading?
Thanks
A somewhat non-answer, but I'll try anyway: As we see the kotlin language mature and as Corda uses quite a wide feature set of what's available in kotlin, it doesn't surprise me that sometimes the frequently published newer versions of Kotlin don't work with older versions of Corda - especially if they make some internal changes to objects then I'm not surprised we see kryo serialisation issues. We publish the recommended / supported version of kotlin in the constants.properties file which, for release 1, is as you've correctly pointed out, 1.1.4 (which can be confirmed here: https://github.com/corda/corda/blob/e564edaa572a011869d692b05518113632363216/constants.properties ).
It does look as if we have updated this for the forthcoming v2 release to 1.1.50 if that helps. It may be a little late in the day to bump this to 1.1.51 though (a fair amount of testing and QA has already been performed).
I've read some things about .NET Standard and .NET Core, and generally they seem to say something like "This is the new way to do things, and here are the advantages and disadvantages."
What I haven't seen is a good, clear explanation of what was wrong with the status quo, such as .NET Standard and .NET Core were even necessarily. To really judge what I should use these for, it would be helpful to know why they exist at all.
Can someone give a clear (and not necessarily concise!) explanation of (a) what problem .NET Standard and .NET Core are intended to solve, and (b) how they solve it?
.NET Standard is a set of library contracts. Each version includes all the contracts of the previous version - so everything in netstandard1.4 is in netstandard1.5 for example.
.NET Core is an implementation of .NET Standard (and some extra functionality) which runs on Windows, Linux and OSX.
Biggest problems they solve:
Not having a Microsoft-provided/supported toolchain and runtime on Linux/MacOSX. Saying that you could only run .NET-based server code on Windows or Mono was simply untenable.
The Portable Class Library mess with hundreds of different profiles giving partially-overlapping API surfaces to target.
PCLs in particular were very hard to work with for class library authors such as myself. The mess came about because there were multiple efforts to bring a .NET runtime to different devices without enough coordination to provide a coherent API surface to target.
Now multiple vendors can target particular versions of .NET Standard, and anything targeted to that version or higher should work. For example, my Noda Time library targets netstandard1.3. Suppose a new mobile phone vendor comes out with a completely new implementation of .NET, with a completely new kind of application - but says they support netstandard2.0. That's fine - a user of that new platform will still be able to install the Noda Time NuGet package and (implementation bugs aside, of course) they'll be able to use it. I don't need to know that the platform even exists.
I want to make an app using Qt that communicates with serial port.
The problem is that I cant find a library that works and does this thing.
I need a non General Public License library I think.
Actually I am not sure cause I don't know if I can use a General Public License library for a closed source program.
I found qextserialport but I am unable to build it using Qt 4.7.3. I added all the needed headers but it fails on some functions.
Can anyone help me here?
If you want to go closed source and distribute your application, you can't use GPL. You can use LGPL when linking either dynamically or statically. For the latter, you need to provide object files for all of your code, so that they can be statically re-linked with Qt.
Conercerning your base issue, Qt 5 includes a serial port module. On Qt 4, you'll need a platform-specific solution. Reducing the scope might help to point you to something. I suggest that if you don't target portability, you should add relevant tags and comments. Otherwise, saying that you need a portable solution is a good thing too.
As far as I know, on most paltforms, accessing to serial port requires higher privileges, so be ready for that in your deployment.
Concerning qtextserialport, license is BSD so it would work for your clsoed source application. If you post a compilation issue on where it fails, maybe people will be able to help you
I tried to compile it using VC2010 and Qt 4.7.2 and head of project (I just cloned it) compiles flawlessly: I got a nice qextserialport1.dll (that I admit I didn't try using).
There is a QtSerialPort add-on nowadays that can be used for such tasks. I am one of the maintainers behind it. That is the "official" Qt add-on nowadays, so I would suggest switching to it. It will also support Qt 4.
It is properly useful for commercial code (closed source) as I have also been doing that. If we do not yet have an exception for static linking, I would even accept that if legally possible.
My opinion about licenses is somewhere in-between LGPLv2 and MIT, i.e. LGPLv2 + static linking.
Here you can find my blog post about it. It also works fine with Qt 4 as we have had put some effort into that support, too.
http://lpapp.blogspot.co.uk/2013/02/qtserialport-in-qt-51.html
I was surfing through various article related to Webservice in Qt , but unfortunatly didn't got what i was looking for. I am using .Net webservice with SOAP, and want to parse this service. Gone through various related article, but the basic problem that i am facing is to get the Soap libraries? Where to download from? And how to integrate? And this will really work for me?
Thank You.
Your best bet is probably integrating gSOAP into your Qt application. (Make sure it's Licensing terms are ok for you.)
A good run-down of how to do the integration is GSoap: SAOP and XML Web services for Qt apps (includes a sample .zip file). That doesn't require a specific version of Qt (since gSOAP is doing all the work essentially), so anything modern-ish should do.
Although it's a very late suggestion, Apache Axis is a free/open source software SOAP stack that appears to fit your needs.
I have downloaded OpenMHeg simulator..how to develop an application in mheg?what eclipse version i need to use?where do i get the sdk for mheg?
I haven't tried yet. but I think it's worth trying. Someone said that the BBC's implementation of MHEG5 is open sourced
It can be downloaded from mhegplus on sourceforge
There is no MHEG-5 SDK. There is some limited documentation available online, and a few discussions of the type hierarchy.
Since MHEG-5 has no support for user defined types and the API is completely provided by the implementation (in various states of brokenness), you only need an editor and an understanding of the application model to write applications.
I wrote an introduction to MHEGPlus a while ago but didn't go into any advanced application building techniques. There are a few more examples out there if you look for them.