Results 1 to 7 of 7
  1. #1
    Star Lounger
    Join Date
    Sep 2002
    Location
    Indianapolis, Indiana, USA
    Posts
    80
    Thanks
    1
    Thanked 0 Times in 0 Posts

    Query vs set focus (All Versions)

    I am working with some forms where I would like to offer the user more detail or an explanation of data in a field, much like a control tip. I use this when there would be max of 20-30 item choices in the data. I primarily want to use this with MouseMove. I am looking for input on which would be a better approach: 1) use a query to update at each mouse move or 2) have a form open in the background, hidden with a 1/3rd-1/2 sec delay on the mouse move, then do a seek on the data and unhide the form when the mouse moves over the item and the delay time has passed.

    Any thoughts? Forget this and use a mouse click event? You're a putz for asking silly questions?

  2. #2
    Super Moderator
    Join Date
    Aug 2001
    Location
    Evergreen, CO, USA
    Posts
    6,623
    Thanks
    3
    Thanked 60 Times in 60 Posts

    Re: Query vs set focus (All Versions)

    <<I use this when there would be max of 20-30 item choices >>

    Does this refer to the choices for a single field, or is this referring to the number fields to be completed on the form? If it's the former, why not use a combo box with the possible choices stored in a table? If it's the latter and the choices are fixed, store the descriptive info in the control tip property for the form. In my experience, the complicated and messy you make a form, the less friendly users find it to be.
    Wendell

  3. #3
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Query vs set focus (All Versions)

    I don't understand your subject line at all, since you seem to be talking about two entirely different things and neither one seems to have much to do with popping up information. MouseMove is a very iffy event, since you're liable to find the details remain visible when you would prefer them to vanish again, unlike a tooltip when is visible for a limited amount of time. Are you going to pop this information up only when the mouse moves over a specific control, several controls, or what? I'm assuming this is a continuous form? I don't understand what you would be doing with a query for something like this. You could use a subdatasheet if your "all versions" means Access 2000 or later, although I avoid them because they can cause serious performance hits. A subdatasheet would be bound to the particular field and would drop down when the use clicked the + sign in the record selector.
    Charlotte

  4. #4
    Star Lounger
    Join Date
    Sep 2002
    Location
    Indianapolis, Indiana, USA
    Posts
    80
    Thanks
    1
    Thanked 0 Times in 0 Posts

    Re: Query vs set focus (All Versions)

    The construct I use is a simple way of storing common data and it involves classifying the data by the type of data item it is. I will use phone numbers as an example. I have 6 phone numbers I can be reached by, so I use a phone type field as part of the key. So I can have a main phone, cell phone, work phone, lab phone, pager, etc. These would be in the phone type field. So there is a separate table that has two fields, PhoneType and PhoneTypeDescription. This construct works for data that has more complex information associated with it. I like to use whole english words as opposed to numbers or codes that require a magic decoder ring. The more complex the relationship, the larger the TypeDescription field becomes. In the subform I will be showing the Type field, which is usually self explanatory for simple data relationships such as phone. However in my current need, a new or infrequent user would be better served with more information in order to make a choice. The character count could easily exceed 200 chars, so I would like to have them just put the mouse over the field and get a popup with the TypeDescription. A time delay would minimize unnecessary boxes popping up.

  5. #5
    Star Lounger
    Join Date
    Sep 2002
    Location
    Indianapolis, Indiana, USA
    Posts
    80
    Thanks
    1
    Thanked 0 Times in 0 Posts

    Re: Query vs set focus (All Versions)

    don't understand your subject line at all......Well it is a fishing for information event and you have taken the worm. [img]/forums/images/smilies/smile.gif[/img]

    So like a leech I get several pieces of info covering several ways to serve up the information. So it looks like MouseMove is not a good idea and while the subdatasheets look cool they are not so good from a performance standard. So I will probably use a click event.

    The form is a subform in datasheet view. I am working immediately in 97 but have another app coming up in 2000 where I will do something similar. The TypeDescription field in the 2000 app is going to get quite large.

    The contents of the TypeDescription field will be based on the data in the field. It is just a clarification in the 97 app. In the 2000 app it is going to be part of a reminder on a decision process.

  6. #6
    Super Moderator
    Join Date
    Aug 2001
    Location
    Evergreen, CO, USA
    Posts
    6,623
    Thanks
    3
    Thanked 60 Times in 60 Posts

    Re: Query vs set focus (All Versions)

    Hans has given you my view of the best way to solve this problem - combo boxes were invented for precisely this problem. Another observation - it appears that your database design is not normalized, and as a result you are likely to have serious bloat problems as well as performance problems. In addition, you will need substantial code on the subform to implement the approach you suggest, making the design more fragile. Finally you indicate the Type Description field will get quite large in 2000 - that creates serious limitation on how you can approach the design unless you go to a SQL Server or ADP back-end, as text fields in Access can only be a maximum of 255 characters. That would require using memo fields which are problematic from performance and reliability perspectives.
    Wendell

  7. #7
    Plutonium Lounger
    Join Date
    Mar 2002
    Posts
    84,353
    Thanks
    0
    Thanked 29 Times in 29 Posts

    Re: Query vs set focus (All Versions)

    If you have a combo box from which the user can select a phone type (to use your example), you could use the phone types table as row source, and include the PhoneType and PhoneTypeDescription field as columns. Set the column width for the second column and the list width for the combo box to a large number. Only the PhoneType will be visible in the text box part of the combo box, but PhoneType and PhoneTypeDescription will both be displayed in the dropdown list.

    You could also use code to set the ToolTipText property to the PhoneTypeDescription in the OnCurrent event of the form and in the AfterUpdate event of the combo box. That way, the description is shown in the standard tool tip.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •