I have a Control Panel (lots of buttons) which works on all platforms.
I want that Control Panel to be shared with everyone (PC users, Android users etc).
Once a person press a button, all of the users Control Panels will be updated.
How do I approach this issue?
Dedicated server with clients?
I'm looking for a block of code which handle sending/receiving data/click on a button.
The whole program written in Unity C# and I'd like a solution in this platform as well (if possible).
socket programming is cross platform. you just send and recieve bytes. you just should have a server to recieve data and send it to other devices. if you use c# you can use .net sockets but for get rid of syncing problem yu can simply use unity Network library and using RPC. now unity has new network system named UNET and there is also photon. photon is not made by unity technologies but as the api is written for many different platform it can be the best choice for you to work on.
Related
I am making a C# app to capture graphic from an avermedia pcie capture card.
But it seems that there are no out of box tools to do so.
So I made a C++ directshow app to do the capture, which is a console app and opens a capture window when running.
How can I redirect the output to a C# app? for example, to a CaptureElement?
So you want to have XAML CaptureElement connected to AverMedia PCIe capture card. This sounds like a well-understood challenge overall, however every other piece of technology you mentioned is eventually a bad choice: DirectShow, multiple apps with piping, redirection and fitting of cutsom code to XAML CaptureElement control.
Microsoft has intentionally been limited ways you can integrate different APIs and so there are not so many ways to get everything together.
Let us go over the supposed integration path. The capture card is supposed to be shipped with a compatible driver:
Video capture devices are supported through the UVC class driver and must be compatible with UVC 1.1
When this is the case, such devices are visible to Media Foundation API handling video capture among tasks. XAML CaptureElement would be able to see a video capture device through this API and this way everything is supposed to work without need to fit anything from your end.
If this is not happening, it suggests you are dealing with an unsupported device coming without suitable or compatible driver.
Previous media API in Windows was DirectShow but its days are gone. It remains perfectly working as a legacy framework, a lot of applications out there are still relying on it. Specifically it will not integrate with new technology like XAML and UWP. More to that, even Media Foundation itself, the current media API, in its public offering is lagging behind when it comes to fitting with most recent technology. Having said that it is a good idea to stay well clear of DirectShow here if this is at all possible.
I see no need for cross-process design with video travelling between process through piping. There is no good reason for such design and even though this can work efficiently (Windows itself proves it can work great in terms of performance by having so called Frame Server service in it), this is not to be built on piping. In your case it is unlikely to be have to be built on multiple processes either. Instead you can develop a native code DLL project that takes care of video acquisition and connects to managed code via suitable glue layer: C++/CLI, COM, C++/WinRT and such.
Then next thing is fitting to XAML CaptureElement. The control is designed to work with Windows.Media.Capture.MediaCapture class that talks to hardware and you don't have suitable hardware as you plan to implement your own acquisition layer. Long story short you are not supposed to forward external data to CaptureElement and you would have hard time doing this. Your best strategy is to upload externally obtained data to Windows.Graphics.Imaging.SoftwareBitmap or alike and take involved performance impact as acceptable. That is, you will be dealing with video frames as images.
An alternative way is to upload acquired video frames into Direct 3D 11 textures and it would open you a more performant way of integration with video related controls, such as Windows.UI.Xaml.Controls.SwapChainPanel however it would also require that you put much more development effort in there.
I have a universal apps getting data from Microsoft's Band 2 (accelerometer) and want to export the processed data in the app to the unity project to be used as input control. The data will be frequent, so real-time response is preferred.
What should I learn or use to achieve this?
I'm pretty sure it would be easier to write a plugin for Unity to connect to Band directly rather than to connect to an app that connects to Band (actually I have no clue how to do that).
Having that in mind, you probably should:
download the appropriate Band SDK from the official website
Read about writing plugins for Unity for the platform you need (Desktop/WP, Android, iOS)
Draw a pentagram and hope for the best
I need to develop a C# touch-screen desktop application with a "modern good-looking" UI.
How would you approach it? I´ve got in mind using Flash (just for the UI) or WPF... but i´m open to any idea or any third-party C# UI you´d know.
Is Flash easy to integrate with C#?
Thanks for your knowledge!
You should look for a AMF remoting library in C#.
Remoting is when you call a function on your server from flash.
AMF (version 0 or 3) is a binary format used to encode object transfered
between client and server
Weborb and fluorine are solutions for this.
see : .NET and AMF
You will probably be doing well with a third party framework to avoid the overhead of writing user interactions, controls, etc.
A couple of options are
http://xamarin.com/
http://www.resco.net/developer/mobileformstoolkit/
A review of these options is provided here.
I recall combining a flash interface with a C# back-end back in university. There's a method called fscommand() that will take a couple of string parameters (I may be mistaken, read up on it) to pass to and from the interface and the C# "code-behind".Flash is an ok option, but if I were you I'd opt for a WPF interface. I'm a huge fan of the telerik libraries, their WPF one allows you to create the most modern-looking interfaces and dashboards. Not to mention that the skills you will acquire while learning enough about wpf will be hugely beneficial in your career as a developer the way things are going (depending, obviously, on what direction you're heading).
FlashBuilder 4.6 has some nice functionality for quickly building a UI that work on a desktop or mobile device. You could use FluorineFX (free) or webOrb on a webserver to send data back and forth to a database server if that were needed. If you build it with the Flashbuilder 4.6 mobile project template, it would work on a iPad, mac, windows pc, or android device as well. Since a pc touchscreen should use the same type of finger gestures as a mobile app, this might be a nice way to go. (I don't actually have a touchscreen on my pc, but it runs well with a mouse, so I'd assume it worked with gestures too).
Adobe.tv has lots of examples of building a mobile app project (Which also runs on a PC) and there is a Flashbuilder 4.6 free trial.
http://flex.org/
My class was recently assigned a group project to be worked on over the next 5 or 6 weeks. It is largely complicated, but a specific item I need to work on involves a chat feature. To keep it simple, there will be about 5 workstations hard-wired together at an event, and they need to be able to communicate instantly.
Our idea is to just throw an executable on each of their computers, so the chat functionality needs to be built-into the application. In order to keep conversations clear and uncluttered, we are going to have a group chat as well as individual chats. I have no way of displaying the GUI we are shooting for, but basically a window will be split in two. On one side a list of workstations as well as a group option will appear, and on the other the actual chat window.
As an aside, I would like to add a notification feature to it so that an alternate tab of the chat will blink, show a star, or something to that effect.
Long story long, I need ideas on how to implement this chat system within an application. It's got me stumped.
Windows Communication Foundation would be a good choice for the network communication portion. There have been many WCF chat servers written - for example, see here and here. One of these examples could get you started.
how about this for a starting point. If you need help code project is a good place to start if you have specific requirements
http://www.codeproject.com/KB/WCF/WCFWPFChat.aspx
Heres a tutorial How to create a remote server by using Microsoft Visual C# that should get you started.
Using ExternalInterface in AS3 is it possible to call OS (C#?) functions within XP?
Example: Set the desktop background to a image supplied by a flash app?
If it is possible would it be different calls when applied to different OS. And what about cross over the Mac?
Any information would be great
Thanks
If you're launching the swf from within a C# app, external interface will do just fine. Nothing will change on the flash side, but you'll need to go through a couple hoops to get it to work in C#. It's not as simple as AMF or External Interface to JS.
All the communications to C# get converted to XML describing the data, and you've gotta write XML to send back to flash. Other than that though, its relativly simple.
Here's some info on how to do it. The AS portion is Flash 8/AS2, but the C# portion should say the same.
When working with Flash from a webpage or as a desktop app, you are limited to a small security sandbox and you will not be able to make any relevant OS call. I thought that switching to AIR would give the developper more flexibility but it doesn't seem correct either. From "The Pros and Cons of Adobe Air":
AIR apps have
file access, clipboard access, support
multiple windows, support drag and
drop, and can trigger notifications
(toast in Windows). If you app needs
to interact with the desktop in other
ways, the chances are that AIR is not
suitable. For example, there is no
access to COM automation, and no way
to execute external applications. The
reason is to maintain cross-platform
compatibility. That's a worthy goal,
but it would be good to have a way out
of the sandbox. Unlike Java or .NET,
you cannot extend AIR with custom
native code libraries. Nor can you
call operating system APIs.
As Alex Jillard commented, if your swf is called inside a C# desktop application, you should be able to access more OS funcionalities although I'm not sure how.
You could use as already mentioned AIR. Another idea would be to use HippoHX (I haven't written this, the similarity with my username is just coincidence). It runs on top of the NekoVM and gives you unrestricted (so no limitations like in AIR ) access to the system.