X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
   Reply to this topicStart new topic
> Developing For Touch Screen    
post Jun 6 2011, 11:55 AM

Posts: 446
Joined: 17-January 11

I'd love to hear from anyone who has developed MS Access applications for touch screens. What tips would you have for someone who is considering at developing an MS Access touchscreen application?
'll give you a little information from my own perspective but I'm hoping it doesn't kill the discussion.
A while back I did build a time clock interface, basically a single form specifically for a 1024 X 768 touchscreen. It works well other than the fact that it has tons of code behind it but that's really quite irrelevant because much of the code doesn't have anything to do with the fact that it's a touchscreen.
Recently our company purchased an HP Slate 500. It's somewhat of an iPad competitor that runs Windows 7. The iPad has a resolution of 1024 X 768 on a nearly 10" screen if I error not, but this slate has a resolution of 1024 X 600 in landscape mode and 600 X 1024 in portrait mode on an 8.9" screen. I'm not going to give a full review of the HP Slate 500 here but I'll give a little information on what I've found out so far concerning running Access on it. I loaded Access 2010 Runtime on it with no issues. Next I put an Access application on it that I developed recently that was not designed for any specific resolution or for touchscreen. I was impressed with how it displayed but I quickly found that doing anything in my Access Application was clumsy and time-consuming, even with the digital pen that comes along with the HP Slate. Using a mouse and keyboard was no problem but most of the point of a slate is to get away from a mouse and keyboard.
It appears to me that an application really needs to be designed for a specific resolution as well as for a minimum screen size (with your given resolution). The reason for this is that the controls need to be large enough to be visible and easily clickable. This is a fairly major limiting factor and it's one of the reasons that most applications will have to specifically designed (or redesigned) for a touchscreen. I don't really have any experience with the iPad but it's my impression that this is also true of the iPad as well as iPad apps. I think one of the reasons for the iPad's success is the fact that Apple has stuck with a specific screen size and resolution and that apps have been designed for and tested on the iPad before they are released. People moving to something like the HP Slate are probably in hopes that their existing applications will work nicely on the touch interface, including applications such as Outlook and Excel. I haven't tested either one of those but I have some doubts about how well they will work as a touch screen application since they are not specifically designed for it.
The other problem I've ran into deals with the on-screen keyboard in Windows 7. The first and perhaps most obvious point is that it doesn't work as well as the on-screen keyboard on an iPad. The second point is that when you do bring it up it sometimes covers the field you're trying to fill in. You can dock the on-screen keyboard on the bottom of the screen. This will help for any form that depends on user input but if the application isn't designed specifically to use only the space that will be left above the keyboard it's still not going to work very well.
Odon't have any experience building forms that are "fluid" and "flexible". I understand that there are simple ways to change the size of your controls based on the size of the screen they are trying to fill but most of my current, non-touchscreen forms are designed in such a way that I would be unable to easily change sizes on the fly and still have the form be usable. Not only do you need to change sizes, you also need to change position. I guess I just don't see any way to get around the fact that you need to design specifically for a touchscreen of a specific size and resolution. But I'd love to hear some contrary opinions.
Go to the top of the page
post Jun 6 2011, 12:22 PM

UtterAccess VIP
Posts: 7,139
Joined: 29-July 02
From: Perris, California

I don't have time to comment on all of this, but maybe my response to the following will help provide some insight.
This is incorrect. Using the same sizing or resolution does not play into the success of the iPad and it's Apps. Many mobile/tablet applications are built in JAVA, which provides for controls to be fluid with the screen available. So instead of designing a button and saying, "I want this button to be THIS big.", you simply create the button and tell it how much of the available spacing it can utilize of the screen.
These options are available in .Net Development as well. Unfortunately, for Access to pull something like this off, it will take a large effort to get it to handle the different sizing, and then handle the different orientations (landscape and portrait).
Go to the top of the page
post Jun 6 2011, 01:39 PM

UdderAccess Admin + UA Ruler
Posts: 19,557
Joined: 27-April 02
From: Upper MI

Not for anything as tiny as an iPhone, there is a demo in the Code Archive - Keyboard on Screen that may help.
Hope it does
Go to the top of the page
post Dec 15 2018, 05:47 PM

Posts: 8
Joined: 6-August 12

Well, I'm late to the party on this. But, in case anyone is interested, I've had good success with resizing everything to fit different resolution and size screens using Peter's Software code module called "Shrinker Stretcher". It just resizes all controls and scales them to the size of the screen. On small touch screens, I've just had my app go full screen and its very cool.

For my core application that works on non-touchscreen PCs, I've developed some work-arounds that fix the vertical sizing of subforms in order to get as many records as possible and take advantage of high res monitors.

Now, I've rented a server on apps4rent.com and am playing around with RDP. The iOs and Android clients available from the app stores (and built by Microsoft) are wonderful. So, I'm redesigning my inspection app to work on phones. Before, I was just playing in the 8-10" windows tablet market, but this is opening up a whole new world!

Scroll bars kill you on small screens, especially vertical ones meant for scrolling through list boxes and subforms. So, I'm playing around with some code that lets you search a list box via typing and it matches as you go. I really want to develop the equivalent of iOs' rolling selection where the default choice is shown large and in the center, with the next choice up and down showing above and below in a lighter font. That's going to take some thinking, but I can see how I might do it with mouse scroll wheel functions. We'll see on that.
Go to the top of the page
post Feb 14 2019, 07:44 AM

Posts: 60
Joined: 8-May 16

Hi ,
I have developed an access application for the windows tablet. One tip I would share is , instead of using the combo box , use a continuous form. The continuous form scrolls very good.

Go to the top of the page

Custom Search

RSSSearch   Top   Lo-Fi    19th June 2019 - 03:54 AM