I would like to build my own virtual keyboard for my windows 7 tablet.
I am not starting from zero in programming; I just have no idea on where to start to make a system level device like a virtual keyboard.
Is there a good article or SDK for this?
You'll need to write a driver in order to truly get a virtual keyboard. Keyboard drivers cannot be written in C#.
Drivers are written in C (not even C++; just C), and they use the Windows Driver Kit for development. There is insufficient documentation, period (the sooner you admit this, the better). Pick up a copy of the following books if you don't already have them: Windows Internals, Advanced Windows Debugging, Oney's Programming the Windows Driver Model, and Developing Drivers with the Windows Driver Foundation. I strongly recommend using KMDF, since it makes writing drivers only extremely difficult rather than insanely near-impossible. Subscribe to OSR's NTInsider and read their mailing list archives (they are the only source I know that has all the missing details on driver writing). Begin working your personal contacts because there's a medium-to-high chance you'll need to talk to someone deep within Microsoft.
To be brutally honest, it is a lot easier to hire an existing expert in the field. Driver development is not cheap, but it's cheaper than doing it yourself.
Here's an old C++ article on the matter.
http://www.codeproject.com/KB/cpp/onscreenkeyboard.aspx?display=PrintAll&fid=500&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26&select=1605922
But I think you'll wind up using SendKeys in C# - http://www.codeproject.com/KB/cs/SendKeys.aspx
Related
I happen to have an old RFID reader from Touchatag. It's pretty old already but it seems to work fine. Unfortunately, Touchatag has stopped their support for this device and besides, it required an internet connection which doesn't make it a very practical solution...
What I would like to do is to use this device without the need for an internet connection and inside an application that's written in C#. Don't know what this app is going to do, but right now I'm investigating all the options that are available for this device. So, does anyone know a good C# library and other sources that allow me to use this device?
(Btw, this is purely experimental.)
I don't know of any C# libraries of hand, but you can check out either:
IOTOPE
Java project that includes a low level library and a more high-level interface to the reader. You can probably adapt it to provide an interface to your C# application.
See http://blog.iotope.com/node/quick-starter/
libnfc
Low level NFC library. Mostly targeted for unix like systems, but could be put to work on windows as well.
See https://code.google.com/p/libnfc/
If you're experimenting with RFID, rather than works the bugs out of interfacing with a custom reader, you can buy a cheap USB RFID reader for around 10 £/$/€
A lot of them simply act like a keyboard and 'type' characters into your application (some even add a carriage return which is handy)
I just like to code when i travel,but i can't carry my laptop while travelling so i thought of a mobile in which i can create apps in C#, .NET or Java but for that i need an IDE,Compiler,etc.
Basically I am looking for a phone / mobile / PDA (far more handy than a net-book or a laptop) in which i can code the way i can do it normally in Visual Studio installed in a machine.
So are there any such devices ?
Let's take a look at what you need to overcome to get this to work.
1) oomph
Smart phones are designed to give you the ability to stay in touch, and have a rich experience on the move, but within the confines of a device that can be put in your pocket. Storage isn't really an issue these days, but processing power on small devices are. Sure we can run calendar, 3D games (though nowhere near the complexity of what you'll see on a fully-fledged operating system), fart-applications and plug-ins for you-tube so we can watch idiots break their ballsacks on railings, but there's a reason you don't see a fully-fledged rich-desktop application, or Grand Theft Auto IV on these devices. Oomph. Now bring in the Visual Studio development environment (and database server, if that is what you're application is doing), with potentially 100s of source files in your language of choice. Assuming we put a severly cut-down version of your IDE on to your pda, I hope you brought some spare batteries or the power-cord because you're going to need it.
2) input
It's probably not difficult to change your predictive text input to cover all the keywords of your chosen language so that you don't end up typing pubic instead of public. Once we've solved that we then need to go through the agonizing process of the fact that computer code contains a lot of symbols and identifiers, meaning we'd have to switch our input mode every other word or two to facilitate it:
for(int i(0); i < _vector.length(); i++)
Takes a few seconds on a keyboard. Probably about one train journey on your PDA. To solve this, we must assume the PDA has the facility for an external keyboard to prevent suicide.
3) display
Ok, we've solved our oomph problems with a power-chord and/or 50 batteries and we've plugged in our external keyboard. We're ready to code!! We'll have to adjust the font-size on the display so that we can get more than 20 lines of code (vertically) or 10 (horizontally). I enjoy my comfort when I code, so I don't want to be squinting at a small screen as I type on my plug-in keyboard. I'd have to prop it up against some books or something (so I don't have to hold the PDA and the keyboard). Now I can't see what i am doing. So, I need a bigger display.
4) Target code
What platform are you targeting? Remember the PDA is designed to run software for the PDA in question. You won't be able to write fully-fledged win32 applications on Windows Mobile 7. There are differences in the API. What if it's a web app you're developing? We're going to have to add a web server to the phone too, unless that is deployed elsewhere and we can rely on an internet connection to upload the changed files to.
Have we solved the problem? Did we get more oomph? A keyboard? A bigger display? Yes we did.
It's a laptop.
It's impractical, as Moo-Juice mentioned. However, you could try using online compilers that work through web browsers, such as Compilr.com. Perhaps this could work well enough through a mobile device's web browser. This way you could write snippets of code and verify that it compiles. Otherwise, you'll be stuck getting a netbook or laptop.
Use a VNC client or Remote Desktop client or something.
Obviously your experience will not be very good on a phone/PDA, but I also don't have an IDE installed on my laptop -- I just use remote desktop (and a wireless modem if I'm desperately bored and can't find wifi).
I want to know how to write a C# desktop application that can connect to the mobile version of the same application (that I will create). The desktop application will be used as a backup/restore for the mobile application.
I want to know also how to write the mobile version (using C# if possible).
From your other posts, it appears you are trying to write a Symbian 7 application to sync a proprietary data format with a custom Windows 7 desktop application. That is critical information to leave out of your question; let me know if I am mistaken.
If that is correct, you have set a difficult task; Symbian 7 is an extremely old OS, I do not know if the Carbide C++ IDE can develop apps for it. If not, you are looking for old versions of commercial AppForge or Metrowerks compilers, you may be able to track these down at the Symbian Foundation.
Then the hard work starts; Symbian is an extremely difficult platform to develop on, and information on old pre-Symbian 9 OSes is scarce. If you are not already an expert on Symbian, I suggest hiring a contractor with previous Symbian 7 experience.
The hard work does not end there, Bluetooth is also notoriously difficult to develop for. The spec is incomplete, and most manufacturers only partially implement it in undocumented ways. One Bluetooth team I know of spent more time debugging hardware problems than developing the software.
This is only the start; you still have to define the Bluetooth data and synchronization protocols; I do not know if ActiveSync was ever supported on Symbian 7, so you are starting from a blank page here. Then you have to develop the Windows app.
You are looking at an enormous commitment to develop on ancient and unsupported hardware. I suggest investigating more modern and capable hardware.
I have got a monitor with multitouch overlay on top of it. It works fine with Windows 7 but I want to write a multitouch application in C# for Windows XP which doesn't support touch feature out of the box. There is no documentation whatsoever and I emailed the manufacturer but never got a reply.
However the device works with Google Earth, which doesn't natively support multitouch, on Windows XP. So I think it generates many types of messages together i.e. WM_TOUCH for Windows 7, one for Google Earth COM API, and probably its own messages either in UDP or Windows message form. How can I trap all communications and learn the protocol?
OllyDbg is a very low-level debugger that allows you to see a lot of the messages going back and forth on the machine. I've seen it used to reverse-engineer a USB device driver's messages to figure out how to interact with an item.
I suspect that would be an excellent place to start. It should allow you to determine how the messages are being passed and, perhaps, start teasing apart their structure.
There are solutions like Tuio around that do not rely on Windows 7. Maybe a tuio (or alternative) implementation would make you life easier.
I've recently been developing on the Windows 7 platform for multitouch. I'm using UniTuio -- see http://xtuio.com You can look at my question I had to get it working. I'm also using a bridge for Windows 7 called Touch2TUIO, it seems to work quite well. If you need to make the mouse inactive see my question here: using windows 7 with unituio
We are at a crossroad as what development tool to use for our application. We do not know if
we will go for Adobe Air or use the traditional road which is Objective-C and Cocoa. The software is similar to www.riffmasterpro in functionality. Is Air the best solution here?
Well, firstly, Flash isn't supported on iPhone so there is no Air platform for iPhone (at least, none that I know of - correct me if I'm wrong).
Secondly, native Objective-C applications on Mac will always surpass Air applications with regards to how well they tie into the OS. An example of this is TweetDeck. It's an amazing application but it just doesn't feel like a Mac app (no meaningful menus, no growl integration, etc...). Mac users are typically very specific with regards to how their apps behave.
I would advise that if you want to write Mac applications (and iPhone applications) to rather stick with Objective-C.
If your primary concern is cross-platform (with the exception of iPhone) then Air is an option worth considering.
If you're looking to build an app solely for the Mac/iPhone platform, I would suggest using Objective-C instead. Adobe AIR's strength is that it can be installed and used cross-platform with little problem.
One of the downsides of that, though, is that performance will never be as good as something that ties directly into the operation system.
problem of using middle frameworks is that you will never have the potential of the hardware, in other worlds you will not be able to use any feature that Mac/Windows can give to you by the hardware, you wll always be attached to what the framework will give to you and hope that you can do everything that you need...
specially in your music application.
regarding the Adobe Air framework, it is a good idea to cover both Linux, Mac and Windows computers but you will not be able to run it under the iPhone because there is no Adobe Flash supported... Adobe is making a flash player for the iPhone, but I do believe that will ot support Air, at least by the near future.
For the iPhone you can build a Web Application or a SDK Application, the last on, and if you will use SDK 3.0, you will find plenty of good things to use it to, but you need to develop a full application from sctrath.