Hi,

I am looking into leanring how to program for touch screen computers and would like to view some code samples or just get general information about how this would be done. Maybe a tutorial would be useful?

Thank you for any information and I am sorry if this is not the right palce for this question.

Regards,
Gene Saika

There isn't much to it. Usually, any underlying operating system will present the touch panel to the application in the same manner as mouse clicks. The major difference is that you will only have a primary (usually left) button down and up "events."

There are some types of devices that have a much more involved touch panel, such as the iPhone and iPod touch. These devices have a comprehensive framework available through the Apple Developer Connection. The framework supports the touch panel.

If you are designing your own device, the options are relatively wide open to you as to how you want to interact with your data points. A typical touch panel driver will constantly evaluate the data received (usually through a set of ADC channels). Samples of data taken within a specific interval are acted upon by the driver code such that it sends one or more messages to the operating system or foreground task.

Most applications developers will be working within the realm of some kind of operating system and often one with a GUI when they encounter a need for interacting with the touch panel. In such cases, the OS will likely have a touch panel-specific API or at least a set of expected messages that will be received by a properly designed application.

In the future you may want to be more specific and less vague when you say "touch screen computers." Today, that could be anything from the thermostat in my hallway to a flight management system on an A380 and everything in between. Was there something specific that you had in mind?


MxB

Thank you for your response I am looking at making my own GUI to use on a consumer computer ( a tablet PC). This would msot likely not be using the OS GUI and such not the touch panel( as I understand it). So I would need to create these interfaces?

This touch ability would be used for a program, say a video game.

If possible could you give me a tutorial on something like these? Maybe you can just show me some source code?

Regards,
Gene Saika

Gene,

I think that you may be having some kind of disconnect between what you're going to be doing versus what you want to do based on your target device and its probable properties.

IF *you* are designing (or someone that you know) the device "from scratch," (this can mean a lot of things) THEN you probably do not have an OS-specific way of interacting with the touch panel aka touch key aka touch screen. Otherwise, there is probably a well or not so well defined way of interacting with one.

Some not-so-well defined ways may be through messages that an application gets that are not well documented or some hardware activity that is never propagated to the application space through a device driver layer.

There are many possible well-defined ways, but if you know NOTHING about your device, there really isn't anything that I can tell you, show you or even reasonably discuss with you that will be of much help.

A "tablet PC" is just about as ambiguous as your original statement.

PC means personal computer. A LOT of people mistakenly *think* that it means an IBM-PC clone. While it is often the case that this is mostly correct, modern "PCs" (versus Macs, Sun boxes, etc) are quite different from legacy IBM PCs.

IF you mean to say that you are running a x86-based computer with a touch screen display, then I want to ask you WHAT code are you using to boot it. Are you booting to some "common" operating system/environment such as DOS, Windows or Linux? Are you booting one of several RTOSes such as VxWorks' product(s), Qnx, etc?

Do you have a "dumb" box that does NOTHING when you turn on the power?

Are you suggesting that you are intending to take some existing "table PC" physical hardware platform and breathe life into it using all of your own code (except for the micro code in the SMC/EC)?

Can you please intentionally try to be SPECIFIC about what you have and what you're trying to do so that I don't have to f$*#&king guess what it is that you want or want to try to accomplish?

If you DON'T KNOW, that's fine, but at least try to categorize the hardware from some kind of set of functional blocks and related architectures.

What kind of processor does it have/use? What other resources is in the box?

Do you know if the touch screen is capacitive or resistive?

Why am I wasting so much of my time asking you questions about what it is that you have when I previously wrote:

In the future you may want to be more specific and less vague

Why can't you be more specific and less vague?

If you are really talking about some kind of x86-based "PC," then it is so "been there, done that" that it is incredibly boring, but none-the-less insightful for those who are first discovering it. But it also begs the question, why not use one of 10,000+ "operating systems and/or environments" already available for the "PC?" Why create your "own GUI?"

Are you incredibly skilled in this area or do you have several thousand man-hours on your hands that you're looking to pour into it? Or, do you mean your own user interface based on an existing PLATFORM (even platform-agnostic) set of tools/libraries, etc.?

Tablet PC? Run Prex on it and write you own GUI and touch screen driver. Have a blast.


MxB

I am sorry that I was still vague about it.

I am wanting to use a HP touchsmart TX2Z tablet PC running windows OS.

What I want to do is build a video game that can use touch input and would like to know how to do this or what I might need.

From what I know I will need to create the GUI for this game and thus not use the windows GUI. If this is wrong please do tell me.

Yet again I am sorry that my previous posts where vague.

Regards,
Gene Saika

Now we're getting somewhere. If you already have the HP product, then you will probably want to start with a simple application that, when written, will tell you everything that you're getting from the touch screen. There is an easy way to do this if you are using a recent set of Microsoft tools. You allow it to create a Win32 "Hello, World" application and then use Spy++ to watch the messages that are sent to your application when you use the touch screen in relationship to your application.

Most likely, you're going to find that you'll get the same kinds of Windows Messages that you would get if using a mouse, except that you won't get things like "WM_MOUSEHOVER" since the computer won't know when you're "hovering" your finger over your application. Here are a few messages that you may (or may NOT) see:

WM_CAPTURECHANGED
WM_LBUTTONDBLCLK
WM_LBUTTONDOWN
WM_LBUTTONUP
WM_MBUTTONDBLCLK
WM_MBUTTONDOWN
WM_MBUTTONUP
WM_MOUSEACTIVATE
WM_MOUSEHOVER
WM_MOUSEHWHEEL
WM_MOUSELEAVE
WM_MOUSEMOVE
WM_MOUSEWHEEL
WM_NCHITTEST
WM_NCLBUTTONDBLCLK
WM_NCLBUTTONDOWN
WM_NCLBUTTONUP
WM_NCMBUTTONDBLCLK
WM_NCMBUTTONDOWN
WM_NCMBUTTONUP
WM_NCMOUSEHOVER
WM_NCMOUSELEAVE
WM_NCMOUSEMOVE
WM_NCRBUTTONDBLCLK
WM_NCRBUTTONDOWN
WM_NCRBUTTONUP
WM_NCXBUTTONDBLCLK
WM_NCXBUTTONDOWN
WM_NCXBUTTONUP
WM_RBUTTONDBLCLK
WM_RBUTTONDOWN
WM_RBUTTONUP
WM_XBUTTONDBLCLK
WM_XBUTTONDOWN
WM_XBUTTONUP

...so, it won't be very difficult to know that the touch screen isn't likely to know if you are engaging it with your "left" or "right" index finger, so you will probably be restricted to one (probably left) button event. However, some touch screen drivers are written to support "right clicking" by holding down the "tap" for a longer period of time. There could be many more options including even raw input.

If you want to write a game that runs on Windows, then you will probably want to use DirectX or OpenGL. My recommendation is that you use OpenGL and consider using it inside of a QOGLWidget from qt-software.com. There is an OpenGL forum here.

DirectX is a viable choice if you intend to target Windows-based systems. It is probably easier to learn to use than OpenGL and its API is probably a lot easier to use, too. It is exceptionally powerful and robust and there are dozens of books available for low cost. The "secret trick" to buying a low-cost DirectX book is to buy one for a version or two "older" than the current version of the DirectX library and you'll usually get them for around $10 without sacrificing much. Most of what you can ever hope to learn in the first few weeks will be very similar between the last couple of versions.

Touch screen input is a very limiting form of input. Apple has done a remarkable job in greatly increasing the capability of touch input, but you're not likely to find that kind of driver on most "tablet PCs," but I may be wrong. The key is to explore your world and see what it returns to you.

If you compare the input of a joystick to that of a touch screen, you'll see that there isn't much going on with the touch screen compared to the stick, which has lots of buttons, switches, potentiometers and perhaps even force-feedback and accelerometers.

With your touch panel, you probably have button up, down and double click. You probably have some form of drag (move), but will it be enough to make a robust game?

In such a case where the kinds and types of user inputs are greatly limited compared to other input devices, then your UI must be extremely well considered and designed for quick access to the kinds of inputs that are not easily done because of the limits of the input device. For example, in a FPS, you might want a "free look" or a kneel, squat, crouch, low crawl, etc. that would not be easily conveyed in terms of input device data without the benefit of some additional processing based on an area of the screen designed for that kind of input processing.

Finally, the key to good game designs is imagination. It is often difficult to be very imaginative when learning a new API, particularly one as complex and involved as DirectX/Show/Draw/etc.

After I discovered what possibilities are available from my input device, I would plan my UI design around the expectations of how the tablet would be held (if held) and how the hands might be used while playing the game. Then I would right a very simple game that did nothing more than position a target or move a ball around screen. Then I would solicit the input from a user community to test my game and provide feedback. This is known as a user jury. Once they told me where the problems were and how they'd like to use the device or what worked and what didn't, I'd redesign the input to suit their tastes and reissue the game to them.

I would continue along this path until I felt that I had enough input and user usability testing to design "the real" game around the lessons learned. I would pay close attention to what they wanted and how they were using the input. A lot of computers weigh too much to be very comfortable being held for very long.

If at all reasonable, I would write a replacement driver for the input device so that I could have much greater control over the data generated by the device than what is being filtered and commoditized for my general consumption.

If any or all of this sounds like a heck of a lot of work, it's true. There is practically an unlimited number of games that were started and never completed. A successful solo game designer must be a master of mathematics, physics, graphic arts, programming, music and multimedia, hardware and software and probably many other disciplines, such as engaging customers, business, etc.


MxB