I am looking for a way for sending and receiving message from unity app to the windows app. All the solution which I found was just work for unity or windows.
I am looking for a reliable solution.
My windows app is not Universal Windows. It is windows form application because I need to be backward compatible.
You can always communicate between Apps using UDP by implementing your own Client/Server.
Then it doesn't matter what kind of language or framework you are using.
Related
I was trying to convert my awesome WPF app to UWP using the Desktop App Converter.
I converted the app using DesktopAppConverter successfully, installed on my local Windows 10 machine and works like a charm. All good so far.
However when I tried the Windows App Certification process, it fails with the below error.
API _amsg_exit in msvcr100.dll is not supported for this application type.
API _cexit in msvcr100.dll is not supported for this application type.
API _commode in msvcr100.dll is not supported for this application type.
I actually use many essential functionalities via a CPP library which was created using some python code (which I don't have source code for).
(I guess "msvcr100.dll" is Microsoft C++ Re-distributable Package? )
Can any one help resolve this issue?
The WACK tool in the Windows 10 AU SDK is not applicable to Desktop Bridge app. You don't need to run it prior to submission. The error you are seeing here you can ignore.
Upcoming new versions of the SDK will have an updated WACK tool with specific support for Desktop Bridge apps.
Thanks!
As far as I am concerned and what I've already implemented there is a way to cooperate somehow with mobile apps such as sending some instructions between mobile and LabVIEW instruments but...
Is there any way to implement mobile application with LabVIEW ?
I suppose that officially not, but what about some external frameworks such as LabVIEW hacker toolkit ?
I've never seen anything that allows you to create native apps. The usual solutions other than data dashboard are using web technologies:
Write a html page that LabVIEW can host that can load on the mobile device and use http or websockets for communications. There are some toolkits to automate this for example LabSocket (though not sure how much mobile testing is done with it).
Remote viewing technologies. I saw one the other day called wezarp which works on mobile.
All of these depending on a Windows based application that you are talking too though. I'm afraid natively I don't think anything exists and would be very hard to implement as you would need to play with the LabVIEW compiler to cross-compile to objective-c, java or javascript.
There was a way: NI LabVIEW mobile module which worked for windows mobile. You would program an app in LabVIEW, compile it and load onto your Windows phone. I recollect it worked pretty stable. The solution is not recommended for new projects
For dashboard style panels, there is Data Dashboard for LabVIEW Android smartphone version allows you to view only. (tablet version allows you to exercise limited control options) Also available for iPhone.
Something available here for select devices only
I'm trying to port my existing silverlight project to xbox Lakeview.
I got a compilation error saying "System.Windows.Browser" is not supported in ADK
and in Microsoft.Xbox360.Adk.targets "System.Windows.Browser.dll" is listed as the
unsupported assemblies.
I'm using APIs such as "System.Windows.Browser.HtmlPage" and
"System.Windows.Browser.HttpUtility". How can I work around it?
I'm not sure if you've gotten this figured out or not, but my version of the ADK I don't believe supports this namespace. If you would like to send me yours, I'd be more than happy to lend a hand in figuring out what's causing this issue.
LakeView is a profile of the .NET framework that is in accordance with Silverlight, but is not the same as the SL Runtime.
For instance, there is no "Browser" when running a LakeView app on your devkit.
You have a special bootstrapped container in one process that your Title will be contained within, which makes it more like a full-fledged application running in a portable OS than a Silverlight application.
What are you trying to achieve with your interaction with the HTMLPage?
Can you redirect your HttpUtility usage to the System.Net.WebUtility?
I'm using hessian protocol for communication betwee server (java) and various client applications. Now I started to develop Windows Phone 7 client. I downloaded hessian C# implementation but it does not compile for windows phone 7/silverlight.
Does anyone managed to make it work on WP7/Silverlight? It's looks like there is many thing to be done/changed to make it work, which I'd like to avoid if it has been done by someone already.
Thanks.
What is it that does not compile? I'm guessing that the implementation is probably using sockets. Please keep in mind that Silverlight (and thus, wp7) limits the kinds of network connections you can open ... preferring asynchronous web requests (via the WebRequest class) or WCF services.
Chances are the code you downloaded is having problems with the compact framework version of the network classes available on the phone/silverlight. See this msdn article for more information about the socket support:
http://msdn.microsoft.com/en-us/library/cc296248%28VS.95%29.aspx
If you want to communicate directly between the phone and a server running the hessian protocol the easiest way will probably be to proxy communication via a wcf service running on an asp.net server.
So answer is you have to rewrite hessian C# implementation as Silverlight 4 doesn't have lot of stuff from .net mobile framework, mainly Proxy class.
How do I go about hosting a silverlight 3.0 application inside of a wpf application in which I can pass data between the two? It needs to run without internet connectivity.
I have a project I'm working on to do that. It's very experimental right now...Hell I really haven't even announced it yet.
http://silverlightviewport.codeplex.com
-Jer
There is no known control that can do this seamlessly out there as yet. To do something like this, you will need to host a web control and use javascript to communicate with the host for interop. Which by the way is not at all recommended.