Welcome to SPN

Register and Join the most happening forum of Sikh community & intellectuals from around the world.

Sign Up Now!
  1.   Become a Supporter    ::   Make a Contribution   
    Target (Recurring Monthly): $200 :: Achieved: $98

Modal/Dialog form problems - Some info

Discussion in 'Information Technology' started by Andrew Gabb, Oct 27, 2005.

  1. Andrew Gabb

    Andrew Gabb
    Expand Collapse
    Guest

    OK, further to my questions earlier, I've done some testing. If you
    want a copy of the DB or have anything to suggest, to advance the
    problem or the solution, email me. Otherwise this posting may be
    useful for others with the same problem. This was done in Access XP
    - but I had the same problems in 2k.

    The situation is that I'm using a form to display a 'pick list' so
    that the user can select an item for further processing. Because
    this selection is part of a relatively complex process, I have to
    wait for the selection before proceeding. The pick list is sourced
    from a table.

    In my testing I call the pick list form Form2 from buttons on Form1.
    Form2 is modal.

    A. Dialog Button
    ================
    For this test, Form2 is called with
    DoCmd.OpenForm "Form2", , , , , acDialog

    Problems:
    Ctrl-F won't bring up Find and Replace dialog.
    Normal record navigation keys (PgUp, PgDn, Ctrl-Home) don't work.


    B. Modal Button
    ================
    For this test, Form2 is called with
    DoCmd.OpenForm "Form2"
    but after opening the form, we wait till it closes using
    While Not FinF
    DoEvents
    Wend

    (The API Sleep function works no better than DoEvents.)

    Problems:
    Ctrl-F brings up Find and Replace dialog, but mouse won't work on
    dialog (eg can't cancel by clicking Cancel key).

    C. Continue Button
    ==================
    For this test, Form2 is called with
    DoCmd.OpenForm "Form2"
    and there is no waiting.

    Problems:
    This works OK, but is very nasty to code in my application - see below.

    Suggestions and workarounds
    ===========================
    I've had several suggestions on how to solve these problems - thank
    you - but as so often happens, they were not full solutions. One
    problem I had is that my clients really want standard navigation
    keys and all-field searches on these dialogs.

    Simulate the Navigation keys
    ----------------------------
    Simple for one or two keys but there are more such keys than you'd
    think, simulating the exact functionality is difficult, and I have
    several such forms. Not an option for me unfortunately.

    Redesign to avoid A/B above
    ---------------------------
    Unfortunately, selecting from these pick lists occurs relatively
    deep in a number of complex processes (which if not completed are
    aborted). Redesigning them would be a lot of work, and would also
    screw up the logic of the design making it difficult to maintain the
    app (particularly for error handling). I've done this in other apps,
    where possible.

    Make your own Find dialog
    -------------------------
    This is eventually what I did (see below), but both I and my clients
    would prefer the standard Access dialog, which has more options.
    Again, it's difficult to simulate exactly. It also bloody annoys me
    that the standard dialog almost works, but not quite!

    Those who suggest that most users don't need all-field searches if
    the DB is designed correctly may be right, but not in this case.
    There are about 10 fields in some tables where an all-field keyword
    search is essential.

    Use the datasheet view
    ----------------------
    I'm not sure that this would work anyway, but it's not an option
    because I need other buttons in the form header.


    What I Did
    ==========
    I eventually used a modal non-dialog form (B above) and put Find and
    Find Again buttons in the pick form header which use FindRecord for
    all-field searches. A bit messy but not too bad. (The header also
    contains keywoard search and sorting controls.)

    As I said above, if you have any suggestions please tell me. Also I
    can send the test DB if you want to try it.

    Andrew
    --
    Andrew Gabb
    email: agabb@tpgi.com.au Adelaide, South Australia
    phone: +61 8 8342-1021, fax: +61 8 8269-3280
    -----
     
  2. Loading...


Since you're here... we have a small favor to ask...

More people are visiting & reading SPN than ever but far fewer are paying to sustain it. Advertising revenues across the online media have fallen fast. So you can see why we need to ask for your help. Donating to SPN's is vote for free speech, for diversity of opinions, for the right of the people to stand up to religious bigotry. Without any affiliation to any organization, this constant struggle takes a lot of hard work to sustain as we entirely depend on the contributions of our esteemed writers/readers. We do it because we believe our perspective matters – because it might well be your perspective, too... Fund our efforts and together we can keep the world informed about the real Sikh Sikhi Sikhism. If everyone who writes or reads our content, who likes it, helps us to pay for it, our future would be much more secure. Every Contribution Matters, Contribute Generously!

    Become a Supporter      ::     Make a Contribution     



Share This Page