Page 1 of 2 12 LastLast
Results 1 to 15 of 16
  1. #1
    Join Date
    Aug 2003
    Location
    Lancaster, CA
    Posts
    17

    Unanswered: MsgBox opens then hides behind a form

    Using MS Access 2002, format 2000 (I think that may be its default format)...on Win7 64-bit. Access bombs from time to time (but so far never with known damage or corruption).

    Fairly frequently, on different forms with different code, a MsgBox will open, then hide behind a form, making it invisible and not possible to close. Because of this, Access seems frozen (can't click anything). The same MsgBox will do this one time and not do it the next time. No sense to it.

    Although the instances are many and varied, here is the code fragment for the most recent encounter of this anomaly.

    If (IsNull(DLookup("[CDC#]", "CCI", _
    "[CDC#] = '" & Forms![frmAddNewParticipants].[CDC#].Text & "'"))) Then
    If CurrentProject.AllForms("frmAddExistingBASICpartic ipantsINFOreviewFromNew").IsLoaded Then
    DoCmd.Close acForm, "frmAddExistingBASICparticipantsINFOreviewFrom New"
    End If
    If CurrentProject.AllForms("frmAddNewBASICparticipant sINFOentry").IsLoaded Then
    DoCmd.Close acForm, "frmAddNewBASICparticipantsINFOentry"
    End If
    If (Me![CDC#] = "") Then
    MsgBox "It appears processing is complete (the CDC# field is empty)."
    Me![PartiHold] = ""
    Exit Sub
    Else
    DoCmd.OpenForm "frmAddNewBASICparticipantsINFOentry", acNormal
    End If
    Else
    (etc., etc.)

    The above code is in a module for an unbound form which calls one of two bound forms (no relationships). If the user clicks a button to continue from that point with automated processing and the next item's field is empty, this results in generating the MsgBox above.

    For myself, this is just a minor annoyance, but for another user it would be a "run get help" situation. When it occurs, I click my link to open the Windows Task Manager, select Access in the Applications tab, and click the Switch To button. That pops it back on top, but others would not do that.

    In searching the web, I only found one instance of someone complaining of this exact problem, but after a lengthy thread, it was not really resolved. (i.e.- They removed some calculation fields and it went away, but that doesn't really resolve what's happening...and in my case is not relevant.)

    Suggestions?
    Doug Couch

  2. #2
    Join Date
    Apr 2014
    Location
    Kentucky
    Posts
    495
    Provided Answers: 24
    Remember you cant close a form if you are running code IN that form.
    unless the last statement in the code is CLOSE ,
    it may stay open to continue the code or close and NOT do the code (i forget which)

  3. #3
    Join Date
    Aug 2003
    Location
    Lancaster, CA
    Posts
    17
    Thanks for the response, ranman256. If a form's own code closes the form, any code after the close command "which refers to that closed form" will throw an error (closed or not exist). And any other code will continue to run until the sub completes. (Just created a new form to test it, just in case I didn't remember correctly.)

    The code example in my original post however, is in a form (frmAddNewParticipants) which stays open until all processing is done and a user clicks close. The forms being closed are the two optional forms opened by that form, in case a user interrupts automated processing and leaves either of these forms open. They need to be closed when the automation code runs because one of them will be opened with new data, and I believe will retain old data if not closed first (sometimes being real data Values and sometimes being DefaultValues).

    My best guess is that this is a bug in MS Access 2002, and that there may be no simple remedy. Hope I'm wrong on that one. Thanks for taking a look.
    Doug Couch

  4. #4
    Join Date
    Oct 2013
    Posts
    8
    Have a look at the Msgbox constants (vbSystemModal, vbApplicationModal) to corral your user into handling the msgbox before moving on.

  5. #5
    Join Date
    Aug 2003
    Location
    Lancaster, CA
    Posts
    17
    Thanks for responding. However, this is not a user-generated issue, and does not seem to be a code-generated issue (as it happens whenever it decides to happen, then doesn't happen another time with the exact same code for the same MsgBox). After reading your post, I did search and read about modal forms, modeless dialogs, vbSystemModal and vbApplicationModal. None of these seem to be capable of addressing this problem; which as far as I can tell, is a bug in this earlier version of Access.
    Doug Couch

  6. #6
    Join Date
    Oct 2013
    Posts
    8
    Hello Doug,

    What message (prompt) is the inadvertant Msgbox producing? What happens when you either set a break point at the Msgbox line or insert a Debug.Print line just before? In other words, lets see if you can narrow down what triggers this behavior.

  7. #7
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    my guess would be you have effectively a dialog box which is modal painted for some quirky reason behind the window that called it. you cant click on the dialog box and the calling window blocks anything until you do. Ive seen this sort of behaviour before in other applications. rather than be a specific Access 'bug' I suspect its an underlying windowing problem. I think its often triggered in development environments where you have two linked windows... say one is running code and the other is the IDE or analysis tool. the IDE halts on an error. the modal dialog is painted underneath another screen

    granted you could argue that probably the developer(s) should check the that the modal dialog is painted ojnt he top level (ie the highest z order) but soemtimes it gets bolluxed.
    I'd rather be riding on the Tiger 800 or the Norton

  8. #8
    Join Date
    Aug 2003
    Location
    Lancaster, CA
    Posts
    17
    Your question makes me face something I've avoided...how to use Access debug features. I don't know how to use break points, etc. So I suppose it's time to learn. Before posting this response, I did go read through some basic information about several interrelated debug, break point, and various debug oriented windows...code execution flow and stopping, etc. So it might take me awhile to figure that out before I could respond to your question. Should be doable though. I can't leave it with the MsgBoxes hiding from time to time.

    I didn't mention earlier, but Access (2002) bombs periodically for no apparent reason, and in different situations (some that seem to stem from code execution, and some just when doing something in the database window, etc.). My guess is that the level of compatibility of this older version with Win7 64-bit is less than optimal. Whether that has anything at all to do with aberrant MsgBox behavior is a question I wouldn't know how to investigate.

    I'll look into it as I find time (today is Thanksgiving).

    I do appreciate your looking and offering good ideas of things to try, directions to go, etc. My experience almost 100% of the time, is that there is an answer and something is doable, with enough perserverance and perhaps asking the right questions.
    Doug Couch

  9. #9
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    As an aside: in my books if you are doing virtually anything with vba code in an Access project then you really, really need to get to grips eith the debugger. I find it invaluable in understanding what the code is doing, ax opposed to what you think its doing. It takes away guesswork, it takes away 'wing and a prayer' approach. It akso allows you to correct (most) errors when in halted mode.
    It can take a while to understand how to use it effectively, but that time is well spent and will be dramatically rewarded over time.
    I'd rather be riding on the Tiger 800 or the Norton

  10. #10
    Join Date
    Aug 2003
    Location
    Lancaster, CA
    Posts
    17
    Especially recently, it has become more and more clear that I need to learn the ins and outs of using debug features. However, my view remains pretty much the same regarding the MsgBox anomaly which no one seems able to explain (here or elsewhere).

    It is a custom message box, not an error message, etc. In that case, the MsgBox function when called (as far as I'm aware and what anyone on any forums has said) causes code execution to stop. And when a MsgBox opens, its default is always on top. I'm taking these two aspects as assumptions, lacking any information suggesting otherwise. If it opens and declares itself to be the top object, and code execution stops...if it then hides, it would seem to be a bug anomaly in Access...or...an incompatibility with the system where Access's call doesn't accommodate newer requirements? If the latter, it is still a bug more or less, although becoming such after the fact of the Access version release.

    I provided a single code example, just to show there is nothing strange going on with adjacent code. But I don't think it has anything to do with the code, but rather is the MsgBox function itself. I'm okay with hearing that this logic is unsound if it is. But I'm unclear what purpose would be served putting the code under a microscope in this particular case. Further, it is almost impossible to test it because there is no consistent instance or pattern of occurrence of this anomaly. If you were to test a given example 100 times and it always tests good, it leads one to believe that it probably is good, even if inelegant, etc. Without being able to even predict when it will occur, it's dicey whether this will ever come to a good resolution.

    Although I haven't used the debug features, I have been occasionally resorting to inserting temporary MsgBoxes before and after things or sections of code to assure the code is being or should be executed, etc. (removing them later). This has been helpful for identifying which code line or section was incorrect or had missing necessary code fragments, etc. Unfortunately, MsgBoxes are the culprit in this case. My need to learn how to step through code and check certain values at various points is unavoidable though.
    Doug Couch

  11. #11
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    Nope, not sure you are correct there
    a message box is modal, which means it takes preference (locks out) the calling form. that means you must complete /dispose of the modal window before you can select the the calling window. it may well be a bug appearing in Access, but Ive seen it elsewhere, in other applications. so its not unique to Access. it may be that Access is not using the correct windows API's to paint the message box, but its not solely an Access problem

    ..anyway moving on from whwether it is or isnt' a this/that/whatever error
    My need to learn how to step through code and check certain values at various points is unavoidable though.
    aint that the truth. debugging through message boxes is an ugly, cackhanded way of development (we have all doine it it). Granted its better than just guessing what is going on, but the debugger is so much more usefull and powerfull. ferisntance, what happens if you:-

    missed a critical variable from you messgae box, with the debugger you can examine and/or modify any variable in the current scope and then run any code within the current scope (so you can reset s function call and step through it line by line

    what happens if the value in one of your variables is wrong, msg box will tell you the fault but debugging will allow you to fix the fault, re run what ever lines of code you need to and keep running

    ..trust me, drop the development by message box and switch to using the debugger its such a powerfull and flexible tool you will be amazed at why you haven't used it yet. Get clearance from your project manager to spend a half day learning the basics of debugging (or more) and prepare to be amazed at the improvement in productivity

    want to to work out if your code is correctly handling soem complex if or select case, then no message box is going to handle that. debugging will allow you to step through code line by line. if you see the code is going down the wrong path you can reset the code, branch down the correct path and keep debugging.

    ..to quote Nike 'Just do it'
    I'd rather be riding on the Tiger 800 or the Norton

  12. #12
    Join Date
    Aug 2003
    Location
    Lancaster, CA
    Posts
    17
    Addendum to my last post: I'm considering using forms instead of MsgBoxes...set to always on top (http://support.microsoft.com/kb/210500) and ?set to modal to stop users from doing other things once opened. While not solving the MsgBox riddle, it seems to be a viable way to do the same thing, as well as have more control over where it pops up, sizing, text layout and formatting and other plus aspects. Takes a little bit to setup, but should be worth it. However, the KB article is for Access 2000. I'm using 2002 and 2003, with a 2000 format file. Hopefully, that should still work okay (knock on layered plastic).
    Doug Couch

  13. #13
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    if you are using message boxes to display debugging messages, then use the debugger.

    in terms of a user interface, then unless you have strong opinions to the contrary then I'd be very reluctant to use modal dialogs (or any form of dialog) to display status messages. use a caption or text control instead, then if users want to do something they can, but otherwise let the system keep running.

    granted this is opinion but developers need to put themsleves in the fra\me of mind of a user, not a developer when creating a UI. Users don't really care that much about how pretty a UI is, or how trick it is, all they really care about is how it gets their job done. Over the years I recognised that users hate being pestered with lots and lots of popups (its no different to popups in web pages), used 'responsibly' they are fine, used selectively. but if you keep requiring user intervention to dismiss what to them are irrelevant messages it just annoys the feck out of 'em

    as a ferinstance I inherited a survey data capture form that was an absolute frightmare. it had something like 500 questions each with a combo box and or option box. A redesign of that form which went away from having to use a mouse to select answers to effectively keyboard only meant users were happier (their workflow was simpler, managers were happier as more data survey answers were captured per hour/time unit byt fewer staff. sounbds like Im trying to lecture, Im not, or at least not deliberately.

    message boxes in Access are great tool to request user intervention (ie x has happened, what do you want to do)... but they can easily be iver used provide a status update.
    I'd rather be riding on the Tiger 800 or the Norton

  14. #14
    Join Date
    Aug 2003
    Location
    Lancaster, CA
    Posts
    17
    Hi Jaded Developer, Thanks to you, ranman256 and hambakable for the responses.

    I will need to learn debugging as a general need. I understand that jumping into modal forms as though it is the answer without much consideration is not the wisest path. And I relate to the user frustrations which can come from overuse of message boxes, comboboxes and option groups. In navigating forms, all of these "can" be done via the keyboard and not the mouse, but as you've alluded to, users either don't know that or don't want to know it, so it's a "grab the mouse" frustration.

    However, and unfortunately for me, I'm mostly wasting your precious time, and not finding any useful answer to the MsgBox anomaly problem. If it is a Windows API issue rather than solely an Access issue (which I have suspected all along), it is beyond any avenue I plan to pursue in correcting it (unless someone knew the problem and the fix and had instructions on implementing the fix). In any case, if the MsgBox anomaly doesn't find resolution, I will have to find another method of informing users and offering them choices. Typically, in this case, "users" means myself and my wife, and later an occasional facilitator in our nonprofit. So the resolution of training, frustration resolution and getting the job done is at least contained.

    My goal is to have our various data entry and editing needs fully available and reasonably intuitive without need for me to come running to answer questions and fix things. Also some manually placed question mark links with somewhat context sensitive help is being added to give answers. That goal is coming along nicely, and would be faster if I actually knew how to program in VBA and knew the debugger, etc.

    Probably the best bet at this point is to post only related to the anomaly and its resolution or work-arounds...even though I love to chat. That is both more useful to me, and to other people visiting the forum looking for answers. I really like that this forum has real people with caring attitudes, rather than uppity snobs with terse answers to visitors like some other forums have. Thanks for being here for us.
    Doug Couch

  15. #15
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    Quote Originally Posted by DCOUCH View Post

    ...Access bombs from time to time (but so far never with known damage or corruption)...

    ...Fairly frequently, on different forms with different code, a MsgBox will open, then hide behind a form, making it invisible and not possible to close...
    Given your second statement, above, I can't really think that your first statement is correct! The 'sometimes it occurs, sometimes it doesn't' together with 'on different Forms with different code' sounds exactly like you're describing a corrupted Access app!

    The first attempt to recover an Access file from corruption, with multi-form involvement, would be to create a new file and Import all objects into it and see what happens.

    As to what could be causing the corruption, the first question that comes to my mind, given that this is a multi-user app, per your description, would be is the database split into a Front End/Back End configuration, as it should be? Multiple users sharing a non-split database, or even sharing the Front End on a split database, can lead to all kinds of problems, including that which you 're experiencing, now, as well as major loss of data.

    Linq ;0)>
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

Tags for this Thread

Posting Permissions

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