I have an upnp library .Am making it to work as a controlled device.It works fine with UPNP 1.0 standard.How will I make sure that it will gracefully handle UPNP 1.1 controlpoint/control device request as well.
There is no doccumentation for library :(
I searched in the source code for new headers like BOOTID etc .No new headers(according to 1.1) are found in the code ..
Is there any way to make sure that my solution will work with 1.0 and 1.1 as well.
Regards
Varunjith
v1.1 is backward compatible with v1.0 so any well behaved control point should work perfectly well against your v1.0 device.
Thinking about it more, I'm not sure v1.1 even contains any additional control point features. While it would be possible for a badly written control point to assume the presence of v1.1 headers in device messages, there are so many v1.0 devices out there that any such buggy control point would be quickly noticed and fixed.
Which is all a roundabout way of saying that I think you can already be confident your solution will work with v1.1.
Related
I want to make a little painting program. So i am going over if it's even possible. As with all good painting programs it needs to have pressure sensitivity. And i don't think i have ever come across anyway to get pressure sensitivity of mouse/tablet. Is there a workaround.
The thing i have come closest to is touch event that is supposed to have pressure property.
This question has been asked before but that was like in 2009. I am hoping that there would be something available this time.
Chrome apps are also an option.
As far as I know only Firefox support this through a proprietary property on the event object:
var pressure = event.mozPressure;
which keeps a value between 0.0 and 1.0.
Wacom has a plugin that can be installed to give browsers an API to read these sort of values from but I guess it only works with their own tablets.
Hello from the future world of 2022!
There is a PointerEvent API that appears to be supported by major browsers, and pressure can be read out from the PointerEvent.pressure property.
tldraw is an example of a project using this API.
Notes on operating system support for this:
macOS
I can confirm pressure-sensitivity with tldraw's drawing tool works for me on macOS, with either Chrome or Firefox, and a cheap Wacom tablet. Safari did not.
Linux
Chrome on Linux works out of the box; I used the Flatpak version. Your mileage may vary with the .deb or Snap package.
For Firefox, you may need to do this or this to get pressure-sensitivity working. There seems to be a regression with Xinput 2 support being tracked by bug #1207700, so maybe this will be fixed some day.
Windows
I don't imagine you'll have any problems on Windows, but I'm unable to test.
If you were interested in creating a web-based paint program in 2022, you might have a look at Pressure.js, which claims to support both pressure input and "3D Touch" present on some Apple devices in a single library. I have no first-hand experience with this library, though, so I can't back up those claims.
It's true this comes 9 years too late for your project. Sorry about that. But this question ranks high in search results for "pressure sensitivity javascript api," so perhaps it can still be useful to someone.
Does anyone know if there exist a development library for the ACR1222L USB NFC/LCD reader/writer? (I'm not sure if it is compatible with ACR122U or not, which libnfc is somewhat supporting it.)
ACR1222L product page
Appreciate any help.
I am sure you aware that there is an SDK available for the ACR122L (Serial) but not the ACR1222L (USB). These devices appear the same but the SmartCard connection methods/operations are completely different.
The ACR1222L that you are concerned about operates in a fashion that is closer to the ACR122U that it's serial counterpart (ACR122L).
I took a bunch of code that worked on the ACR122U and it also worked on the ACR1222L with little modification.
What platform are you developing on?
A good place to start would be with the ACR122U SDK then buy the ACR1222L.
I have developed for all three devices mentioned above.
i'm newbie in FTP connection programming in Cocoa. I found 2 library that i can choose for make my app, but i dont know what's the best between these libraries. The libraries are libcurl and chilkat . The problem is what benefit of each library? Did somebody compare it? or maybe can anyone tell me about your experience? Thank you
I don't have any experience with chilkat, but I can tell yout that libcurl is used in a lot of programming languages and is available on a lot of systems. In for example PHP or on a Mac curl is a great tool to use.
So I would advice libcurl if it's available on your platform. You will probably find more information about curl and it has proven itself on many other platforms.
Also interesting if you want to go with curl is curlhandle. It's a cocoa wrapper around the curl library. Probably very handy in your case, but I've no experience with it.
I can tell you that the difference between libcurl and chilkat is like this: (though you probably know by now)
Chilkat is like the chess game you buy at the store and libcurl is like the plastic in liquid form you buy that you can make any chess piece with.
Libcurl is a slightly abstracted sockets-connector and Chilkat handles everything you'd do, up to a certain amount, with that connection. You're either staring at bits or something "made those bits into an email". I'm about to buy Chilkat for some of the libs, I like the features, but at the same time I wish I had time to read the RFC's and play with the other stuff using libcurl. Anywho, hope that answer is worth something to someone.
Because this question is still ranking high on google i give you my experience.
I bought chilkat in 2015 and moved to libcurl later and my own implementation much later. Both are far from perfect. libcurl just shows it's age and some weak designs.
libCurl is an library that tries to implement all URL able protocols even if they are designed as stream protocol like FTP. Do yourself a favour and only use it with HTTP/HTTPS. It just does the transfer part. Which is not enough for handling. You would love to see at least mime and charset routines to use the downloaded files.
Chilkat is a toplevel library that tries to give you as much highlevel access as possible. It uses background threads in script languages where it is not easy to use. The problem is that the API is terrible, very little documented and total failure when you want to write a quality program. For example it returns requests as a string. There is no way for stream processing. Now imagine you download a large GB iso file, you wont be happy. It can return as a file but then you have to specify this at the begin of a request when you don't knwo the download size.
Also the code quality until proven otherwise is bad. There are a few chilkat source code snippets in the wild which you can find via google and they are pure madness. Ok we don't know how this old code has been refactored now. But it leaves a bad taste, remember this is closed source and there is not a single mention about corner cases, which protocol is implemented, which feature of protocols are implemented and so on. You are using a total black box.
Also it does not allow high performance and high value code. I used it to write a web crawler and it was much much slower then libcurl.
I later used the HTTP and SSH compoenents to automate some server/client management scripts and there it shines. You know both sides and can just test if they work together and don't get any surprises. Then it is indeed easy and better then using the broken python or ruby SSH.
But if you ever contact with another unknown server, Chilkat is not your library.
I have the following requirements:
I need a api that works on CE (x86) + .NET Compact Framework to play videos (Similar to CorePlayer API... Just free)?
Is their anything else available or must I use CorePlayer?
You could use the MediaPlayer with COM interop. Have a look at this and this.
Also, Media Player may not be installed in your device.
You need to use DShow and have the codecs for whatever media you intend to play in the image. COM interop for WMP 9.0 (which is what ships up through at least CE 5.0, maybe also in 6.0) is a non-starter for managed code.
If you don't know DShow, it's a fair amount of work - even in native code - as DShow is not a fun or friendly API set.
The plus side is that you don't need WMP at all in the image, so you can typically use a Core CE license (Pro is required to use WMP). I know of a commercial DShow control, but you said you're looking for a free solution and I'm not aware of anything other than rolling your own. Depending on your level of familiarity with COM interop (which you'll need for the DShow stuff) and the use of DShow and filtergraphs, I'd allocate at least a week or two to getting this working.
One added note - the complexity also changes depending on how you want the video displayed. If it's just full-screen then it's a bit less work than getting it inside a Window within your app. Not a lot less, but at least a little.
DirectShow?
Check out this page for a starting point.
Provided that DirectShow is present on your CE, which I don't know...
EDIT: Since you can use DirectShow, I'd like to add a bit.
As ctacke notes, it can be a lot of work if you do everything manually, but it's pretty straightforward if you can use IGraphBuilder (see the sample I linked above).
I don't know much about DirectShow versions, but the one included with Windows Mobile 6.0 lacks a splitter for MPEG audio. It means, e.g., that out of the box it won't play .mp3 files unless you wrap them in RIFF headers.
I bet you can convert some of DirectShow.Net to run on CE if you are looking for a C# solution.
I'm looking at rewriting an eMbedded Visual Basic app I wrote years ago. I'm unsatisified with it because of various problems clients keep having with it now and then over the years, mostly along the lines of the app not loading anymore because a required dll/activex control has gone missing! This is so frustrating and naturally difficult to debug when a client is using it far away. In alot of cases reinstalling the app doesn't fix the problem.
My preference would be to rewrite it in C# since I'm comfortable with C# and DotNet, but I'm also open to other platforms like blackberry or iTouch/iPhone so long as the platform can support maps and GPS. I'd start rewriting it in C# now but I can't be sure that I won't have the same problems in .net.
Has anyone else had similar problems with eVB apps which have gone away/persisted when moving to CF DotNet? Or would you suggest a different platform again?
Edit: Note that I wish to move away from eVB anyway, but if I move to CF DotNet I want to make sure I won't have the same missing dll/control problems.
I recommend .NET CF strongly, especially if you already know C# and .NET. Mono has been ported to the iPhone, so it is possible to write apps that will run on Windows Mobile and the iPhone. No Mono for Blackberry (yet, if ever), so that's a definite limitation. I personally can't stand Blackberries (I have both a Blackberry and a WM smartphone and the Blackberry makes me want to hang myself), but they do have a huge user base.
You should have migrated away from eVB years ago, but that's water under the bridge. If you want to continue targeting Windows CE/ Windows Mobile I'd recommend going to the CF - language is irrelevant, use what you're comfortable with.
There's no way to guarantee that whatever your "missing DLL" problem is won't happen again, since we have no idea what DLL went missing. If it was a 3rd party control, then you're at the mercy of the market. If the provider survives, it's likely their control will.
If you want to target iPhone/Blackberry then Java is more likely to be your language of choice - the tools I'm not as familiar with. Eclipse for Blackberry - iPhone may have their own tool.
As for Silverlight, you might look at it, but so far it's just way too slow to be a viable platform, at least on any WinMo device I've ever seen. We've delevered many, many CF apps for all sorts of verticals and have never had any usability problems (though we've been doing it a long time and know every limitation and what we should and should not be trying).
I suggest you take it one step further and look at Silverlight. One of the premises is that it's a more long-term-stable, portable, lightweight download and install, and it hasn't gotten krufty yet.
I think it has the potential to be the next VB for embedded. One of the difficulties with CF is that I've found it to be an insufficient subset of the real thing.
Another option is NS Basic/CE. It's highly compatible with eVB, so you will be able to keep most if not all of your code. The product has been continually updated so it runs on current devices.
The installer that NS Basic/CE creates includes all the dll files your program requires, so they will be included on installation.