My Assistant
![]() ![]() |
|
|
Mar 29 2012, 03:10 PM
Post
#1
|
|
|
UtterAccess Addict Posts: 118 |
I have a db and forms already designed that I use to keep track of my customer's purchases, contact information, and property information. It works great on a laptop but now I want to move it to a touch based design. I purchased a ASUS windows tablet and I can use the forms with the pen for precise "clicking" but the benefits of a touchscreen are not fully appreciated unless you can use your fingers to manipulate the forms. Items like drop down boxes or list boxes require too precise a touch to select a choice. With limited real estate on the screen making those controls larger to let your finger do the work causes many of the other parts of the form to be pushed down or sideways, requiring you to scroll. Fingers do not work well with scroll bars. My solution to this issue is to make forms handle very specific tasks like choosing a customer or a product, and then disappearing so you can then work on the order or update the contact information for example.
Here is a good example. Lets say I am updating a customer's contact information and I take a call from a different customer who wants to place an order. For me to do this I need to open the ORDERS form and switch the record to the customer on the phone. I am thinking that each form has a set of buttons that will open up the different forms like CONTACTS, PROPERTY, ORDERS, CALLS, CUSTOMER SELECTOR, etc. Once on the new form I can open CUSTOMER SELECTOR and change the record to a different customer. What I am not sure of is how to pull it off. If I switch to a different form by opening up the CUSTOMER SELECTOR form from the ORDERS form I will loose focus from the ORDERS form, giving the focus to the CUSTOMER SELECTOR form. Once the focus is lost I have no way of changing the record on the ORDERS form because once on the CUSTOMER SELECTOR form I have no idea how to capture the name of the form that opened the CUSTOMER SELECTOR form. Even if I could capture that information, how do I use it to change the record on the now open ORDERS form? I need to figure this process out because it will also be used in changing values in text boxes through the use of a touchscreen keyboard. I understand that changing the active record is very different than entering in text to a text box but the process of going back to the originating form would be the same and I do not know how to do it. As for the touchscreen keyboard keep in mind that sometimes a subform would be the form that you need to go back to when using the touchscreen keyboard. The subform would not be an issue if you are changing the record to a different customer because you would change the record on the parent form and it would filter the subforms accordingly. Can someone help me? |
|
|
|
Mar 29 2012, 03:50 PM
Post
#2
|
|
|
Access Wiki and Forums Moderator Posts: 48,021 From: SoCal, USA |
Hi,
If you are going to design a database for a tablet, I would suggest that you completely redesign your forms. For example, due to the limited space, I would avoid using subforms and use popup forms instead. Just my 2 cents... (IMG:style_emoticons/default/2cents.gif) |
|
|
|
Mar 29 2012, 08:18 PM
Post
#3
|
|
|
UtterAccess Addict Posts: 118 |
Redesigning the forms is exactly what I was planning on doing. If I use pop-ups how do I get the information in the pop-up form into the original form? Would it speed up the responsiveness of the program to keep only 1 or 2 forms open at a time?
|
|
|
|
Mar 29 2012, 08:54 PM
Post
#4
|
|
|
Access Wiki and Forums Moderator Posts: 48,021 From: SoCal, USA |
Hi,
If I use pop-ups how do I get the information in the pop-up form into the original form? You can either refer to the form itself or pass the values using OpenArgs or Global Variables or TempVars... QUOTE Would it speed up the responsiveness of the program to keep only 1 or 2 forms open at a time? I would think so... Just my 2 cents... (IMG:style_emoticons/default/2cents.gif) |
|
|
|
Mar 29 2012, 08:59 PM
Post
#5
|
|
|
UtterAccess Addict Posts: 118 |
With 3 options to choose from which method is the simplest?
|
|
|
|
Mar 29 2012, 09:01 PM
Post
#6
|
|
|
Access Wiki and Forums Moderator Posts: 48,021 From: SoCal, USA |
With 3 options to choose from which method is the simplest? How many values are we talking about? I think it would depend on how many values you need to pass. Just my 2 cents... (IMG:style_emoticons/default/2cents.gif) |
|
|
|
Mar 29 2012, 09:12 PM
Post
#7
|
|
|
UtterAccess Addict Posts: 118 |
In the case of selecting a different record I would think only one value. In the case of a touchscreen keyboard you would have to send each key as it was pressed and then put the focus back to the keyboard until you were finished entering text.
|
|
|
|
Mar 29 2012, 09:56 PM
Post
#8
|
|
|
Access Wiki and Forums Moderator Posts: 48,021 From: SoCal, USA |
In the case of selecting a different record I would think only one value. For one value, OpenArgs should be sufficient. QUOTE In the case of a touchscreen keyboard you would have to send each key as it was pressed and then put the focus back to the keyboard until you were finished entering text. Weird... I don't have any experience developing for tablets but I would have thought the OS for the tablet would trap the keyboard entries from the screen and pass it to the active form/application. Just my 2 cents... (IMG:style_emoticons/default/2cents.gif) |
|
|
|
Mar 29 2012, 11:51 PM
Post
#9
|
|
|
UtterAccess Addict Posts: 118 |
The tablet does have an on screen keyboard. However, it covers up the forms when you are using it. What I want is for the form to scroll when the keyboard is active so that as you move through the form you will always see the text box you are typing in while the keyboard is at the bottom of the screen. Another customization is to show a keypad when all you have to enter are numbers. This is not handled well by the built-in keyboard.
|
|
|
|
Mar 30 2012, 12:24 AM
Post
#10
|
|
|
UtterAccess Ruler Posts: 2,659 |
The bottom line here, and I know you don't want to hear it, is that you're trying to use this device for something that it was never, ever intended to be used for! Your app, going by your original post, is obviously a complex one, and you could spend months and months trying to revamp it, and reworking all of your forms, and you're still going to end up with a clunky database that is hard, if not impossible, to use with anywhere near the ease of your original PC-based app. These devices are simply not intended for this kind of work.
Linq ;0)> |
|
|
|
![]() ![]() |
|
Go to Top · Lo-Fi Version | Time is now: 23rd May 2013 - 04:52 AM |