I have a custom bar code app running on .Net 2.0 framework and installed on a Windows Terminal Server. I’m using HP type thin clients and they are pulling their desktop from the TS that has my barcode app installed on it.
For the most part, the barcode app runs with no problem. The only issue I have, is that my barcode app needs to print labels to a specific printer based on the work center that the thin client is located in. The barcode app was designed to route the labels based on the device name (Windows name) of the system that the barcode transaction originated from.
I have a full blown Windows XP Pro system also running the barcode app and I have no problem with the label routing because each of those type systems has a unique name that I can use for routing. Where I’m running into a problem is that the barcode app running from the thin clients, appears (from the barcode app’s point of view) to running from the Terminal Server not the individual thin clients.
Does anyone have any idea how I can pull some type of unique identifier from these thin clients to use within the barcode app to use for routing of the labels?
That is a tricky problem. If your thin clients have set IP addresses though, I think I have a solution for you. I found an article that explains how to get the RDP client IP address (not the server's address). This will have a problem if you are going through a NAT but if you are connecting directly using RDP, it should work:
http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/857af1fe-75a4-4845-b989-f18636f296c9/
Related
I'm trying to make my store app communication with desktop app through websockets.
I know we can make metro app as a client and do WinRT way of communicating over.
For the desktop server part, i'm planning to write a dll that will contain server code and receive metro texts being sent over.
Can someone please tell if this is possible and how to write server code in a dll and if so should we be using winhttp for wbesockets in server side ?
Windows Store (WInRT) apps are executing in a sandbox which isolates them from network communication with other applications on the local machine (localhost). That being said, this protection can be disabled using CheckNetIsolation.exe. Visual Studio automatically does the same for debugging purposes, allowing you to call e.g. a web service on your local machine during development.
As for the desktop side; to communicate with web sockets client, you can make advantage of WinHTTP. There's a working example on MSDN.
Keep in mind, though, that any application communicating with localhost will not be certified for Windows Store and will require several additional steps to install it:
The Windows Store application package will need to be sideloaded since it won't be published in Windows Store.
Any desktop component it communicates with will need to be installed separately the same way as any other desktop application.
Using CheckNetIsolation.exe loopback exemption will need to be added for the Windows Store app.
If you can avoid it, I definitely suggest you don't try communicating directly with a desktop application from you Windows Store app.
I have searched around a lot but have not found much of anything in regards to local storage for Windows 8, Windows RT, and Windows Phone apps.
I want to display the browser on a page surf and search webpages. When I find the specified webpage, I want to store the url on a local storage of the device.
On another page, I want to display the URLs in a list for fast select and direct surf to the url. I am developing with visual studio 2012 and vb.net.
Local storage options for Windows Store apps is pretty well covered in the dev center topic Accessing app data with the Windows Runtime
In Windows 8 (Windows Store apps), you could use app settings (registry based), local application data (file-based and sandboxed) as well as the roaming versions thereof.
Since you mentioned Windows Phone 8, I'll add that while the same Windows Storage APIs are surfaced for Windows Phone, only local application data will work directly. In Windows Phone 8, local application data is another way of handling isolated storage; however, there is no built-in roaming data option. Additionally, app settings as implemented in Windows 8 is not available in Windows Phone, but you can use isolated storage settings which is semantically equivalent.
I have gone through the web browser terms and conditions, and there it is clearly mentioned that you cannot use the web browser for general browsing, and if you are doing the same, your app would be rejected by the microsoft app store
For reference please go through
http://blogs.msdn.com/b/wsdevsol/archive/2012/10/18/nine-things-you-need-to-know-about-webview.aspx#AN6
I am making an app for the iPhone in Xcode which needs to be able to send and receive excel data from a windows based machine. Making the app is no trouble but what would I need from a PC to access the app data?
Firstly, I wouldn't be using Excel as a data storage program. What you really should be using is a database hosted on a web server with a PHP interface etc. If you choose to go the database route, then you can easily use a Windows machine.
Though if you choose to stick with Excel, it would be theoretically be possible given that people have made apps to have full control of a computer remotely via an app. I just think that this approach is going to be very hard to set up, and will be a lot more clunky than any sort of web server set up. Don't forget that you can get free web server services if the data level is low.
As you mentioned, this PC won't have access to the internet. Assuming you aren't willing to fix that, I guess you'd be left with a Bluetooth or local wifi option. Having to plug it in would really defeat the purpose of an app, and I don't think that iPhones can even do that without mad hacks.
An alternative idea is to build an app that links in with some free web server service, then build VBA code to download it to your Excel sheet. When you plug your iPhone into your PC, use the hotspot to get internet access.
I have a traditional Win32 program which gets some data using WMI (and it cannot be fetched using API available to Metro apps). Now I want to make a tile with part of this information. As I've understood, it's impossible to simply send this data from Win32 program to the Metro application. What's the preferred way to do such thing?
There is no direct app to app communication method. What you want to do can be accomplished in several ways, however. Your Win32 app could write data to a location on the file system that a Metro style has access to. Also, you could synchronize your Win32 app with your Metro style app using the cloud. You need to be careful, however, as this might violate some of the app certification requirements.
If you are simply writing something for yourself (not concerned with publish your app), you might consider taking the functionality that currently have within your desktop app and encapsulating it within a wcf service running on localhost. Metro apps can call wcf services.
One option would be to have your Win32 program create the tile XML and deposit in Windows Azure storage (or really anything accessible via a URI) and then your Windows 8 Store application could subscribe to that tile via a Periodic Notification.
There are some constraints here which may or may not be relevant to your application - like the refresh rate of the tile (discrete periods from 30 minutes to 1 day) and the machine must be connected to the network when the poll from the URL is made.
You might be able to incorporate a background task to do something similar.
I am looking to use Adobe Air to visualize information coming from the Serial port. Is there a way to do this naively in Air? I'm assuming not.
If this is the case, would my best route be to create a native application that makes the serial port available via a TCP/IP connection then connect to it locally? or would a different socket type be available?
With this solution, is there a way to bundle a native app with an Air app so that the user would have a 1-step solution?
You can't access the serial port from AIR, but this thread links to a library that claims it will shuttle the data across a socket: http://www.extjs.com/forum/showthread.php?t=36825
You won't be able to bundle the native app with the AIR installer, you would have to bundle the AIR app with the native app. In other words -- write a native app, with a native installer that also installs the AIR app.
Once you've got a native app and an installer, you have to ask yourself what the benefit of using AIR is anymore. Especially now that you have to write a client and server to shuttle data back and forth between the two.
Unless there is some feature in AIR that you absolutely must have, you're probably better off with a cross-platform tool set like Mono or Qt that can handle accessing the serial port. (And if you don't need cross-platform, you've got even more options.)