Link to home
Start Free TrialLog in
Avatar of wsturdev
wsturdevFlag for United States of America

asked on

DoCmd.Echo False fails in modal form in 2007

I am converting an Access 2003 app to Access 2007.

In this app, I have a form that is set up as a modal dialog.  There is a main "dialog" form and a couple of subforms and record navigation buttons.  Upon arriving at this "dialog" form, the user may navigate through some records, and upon finding the desired one, can click a button to make a copy of the desired record (along with appropriate value changes), which will then be available back on the main form from which the dialog originated.

In moving between records in the "dialog" form and sub forms, I am trying to use DoCmd.Echo False and True to control what the user sees.  I have traced the logic, and after I issue the DoCmd.Echo False at the beginning of Form_Current, there are no extraneous DoCmd.Echo True statements anywhere within the logic, until I finally issue a DoCmd.Echo True at the end of the Form_Current.  But I still see everything I am trying to hide.  It is as if I never issued a DoCmd.Echo False.

Is there some restriction against manipulating the Echo state if the form is "modal"?  What is going on?
Avatar of Jeffrey Coachman
Jeffrey Coachman
Flag of United States of America image

wsturdev,

Can you please explain exactly what you are trying to accomplish with this system?

"I am trying to use DoCmd.Echo False and True to control what the user sees."
I am totally confused as to why you might need to use the Echo command to do this?

JeffCoachman
Avatar of wsturdev

ASKER

Jeff --
All forms and sub forms in the app are unbound.  Their recordsets get set from queries performed against a SQL back end (Set Me.Recordset = [query]).
The main "screen" in this app consists of a Parent form showing "Entries".  The default view is Single Form.  There can be multiple Entries, so it is necessary to have Navigator buttons at the base of this form.  The Entry form has a sub form showing "Instances".  The Instances sub form is also a Single Form, and since there can be multiple Instances for each Entry, it also needs Navigator buttons.  The Instance sub form, in turn, has a sub form showing "Tasks".  Since there can be numerous Tasks for each Instance, the Tasks sub form is Continuous, with a vertical scroll bar.
When the user moves to a different Entry Record, the Instance form's recordset is reset with a new query that relates to the parent Entry.  When the user moves to a different Instance record, the Tasks form's recordset is reset with a new query relating to it's parent, the Instance form.
This scenario results in retrieving the smallest amount of data and is fast.
But, it is not instantaneous, so the user sees the Entry form fill with the new record, then the Instance form, then the Tasks form.  It is a bit disconcerting for the fraction of a second it takes all the forms to refill, to temporarily see the previous Instance/Task List with the new Entry, then the Instance changes, then the Task list changes.
To make the user experience smoother, I use DoCmd.Echo False at the beginning of the Form_Current of the Entry form and DoCmd.Echo True at the end of the Form_Current.  The result is that movement to a new Entry/Instance/Task List combination is smoother, with less screen "flashing".
This works fine on the normal "screen".
At some point in using the app, the user will need to create a new Entry record, its associated Instance records, and their associated Tasks.  There are a number of ways to create a new Task list.
The one I am dealing with in this post is that of selecting a Task List to copy.
To do this, the user must first find the Instance record he wants to copy from, and then, to be sure he is copying the correct Task list, he needs to review the list of Tasks before giving the Okay.
To accomplish this, while he is on the main screen viewing the new Entry and the new Instance, but a blank Task list, I present a modal dialog.  It mirrors the main screen presentation:  it consists of a parent form showing "Entries", with Navigator buttons, has a sub form showing "Instances" with Navigator buttons, and it has a sub form showing "Tasks" with a scroll bar.  
Because it is not necessary to show all the ancillary data required on the main screen, the "dialog" set of forms is smaller, more compact.  I present it as a modal dialog because the user needs to finish working with the copy function or cancel it and continue working with the main screen.  The modal dialog prevents the user from inadvertently moving away from the copy process, as he might do if it was not modal, and I would end up with more forms open than needed.
The modal dialog is presented in the same general format as the main screen, though smaller as I have pointed out, and with different colors, because it is a familiar layout.
The issue I am asking about in this post is, while the DoCmd.Echo False/True works on the main screen when moving from record to record, when a similar form structure is presented as a modal dialog, it does not.  
It is as if I never issued the DoCmd.Echo true statement.
What should I be doing that I am not? What setting have I missed?  I never had this problem in Access 2003... is there a bug in Access 2007?
<It is as if I never issued the DoCmd.Echo true statement.>
Sorry... I meant to say:
It is as if I never issued the Docmd.Echo FALSE statement.
As suggested by Access 2007 Help, I have switched from DoCmd.Echo to Application.Echo.  The results are the same.
 
I also found this comment in the Application.Echo Method documentation:
____________________________
Remarks

If you are running Visual Basic code that makes a number of changes to objects displayed on the screen, your code may work faster if you turn off screen repainting until the procedure has finished running. You may also want to turn repainting off if your code makes changes that the user shouldn't or doesn't need to see.
The Echo method doesn't suppress the display of modal  dialog boxes, such as error messages, or pop-up forms , such as property sheets.
_____________________________
I wonder if the implementation of Application.Echo in Access 2007 considers "Modal forms" to be the same as standard Access 2007 "modal dialog boxes", such as error messages.
If it is, in my opinion, it shouldn't.  The cocept of Modal should be that the user is prevented from doing anything else in the app until the dialog form is dismissed, but within the dialog form, the developer should have complete freedom to use all aspects of the development toolset in Access.
wsturdev,

Thanks for the explanations.

Access 2007 has changed a lot of the way that forms are viewed and intreracted with.

For example, the "Tabbed View" seems to over-ride some of the form properties that developers in the past had used.

The Echo command may have been affected by this as well.

This is why I originally asked why you were using this.

I only use ehco when I want to hide screen activity for Access 2003 and earlier reports because they did not have an Open "Hidden" argument.

Perhaps you could redesign certain parts of your apps so that forms are hidden.

Also investigate some of the new form properties that might be able to be substituted for the echco command in certain instances.

:-)


JeffCoachman
Jeff,
<Open "Hidden" argument>  By this do you mean I can open a form in "Hidden" mode, that is not visible to the user?  If so, I don't think that is what I want here.  I am not interested in hiding forms, just turning off screen updates until I am ready for the user to see the results.
<Perhaps you could redesign >   I am trying to do the absolute least redesign possible.  
<Also investigate some of the new form properties that might be able to be substituted for the echco command in certain instances.>   Any suggestions about which ones might be applicable?
Bill
wsturdev,

On your first two statements:
OK, just tought I'd bing it up.

On the third statement, you will really have to see for yourself.
Click on any property and press F1 for more info.

Jeff
Jeff -- just getting back to this.  Can you open a form as "Hidden" and the at some point "Unhide it"?
You can open the Report hidden and THEN immediately open it Unhidden.
(Obviously you cannot do both at the same time.)

But I can't see any point in doing this?

Can you explain?

I guess my question about hiding/unhiding was kind of stupid, because I can't see any point in doing it either!  Why would I want a modal dialog to disappear and reappear every time a user went from one record to another within it?  Dumb me!
I am trying to open a form as a modal dialog.  The modal dialog form has a set of record nafigators in it and the user will need to move from record to record within the dialog.  Various background activities take place for each movement, and I am trying to lock the screen so the user does not see those things.   The modal dialog is necessary so the user cannot go off somewhere else until the work on that dialog is finished and they click either Okay or Cancel.
In Access 2003, DoCmd.Echo False -- DoCmd.Echo True use to accomplish this, but in Access 2007 it is as though I have never issued the DoCmd.Echo False -- DoCmd.Echo True statements.
I just want the DoCmd.Echo False -- DoCmd.Echo True to work while the modal dialog is open.  Or some other construct -- Application.Echo False -- Application.Echo True does not work either.
I have explored other potentially "helpful" properties and found nothing so far.
[I really am getting tired of having to constantly "redesign" my apps, which used to work in 2003, to get them to work the same way in 2007 (I have no choice about 2003-2007).  Does anyone have any idea when an updated version of Access 2007 will be released with all the various known issues corrected?]
Turning the "Echo" off basically "Freezes" the screen.
So you can do this at anytime and the screen will "Freeze", until Echo is turned back on.

Opening a form "Hidden" just opens the form/report, but the form/report is not visible.

So opening a Form Hidden, and opening a from then turning off the Echo are two different things.

This all being said, ...I don't think opening the form Hidden will help you in this regard.

As far as re-designing your apps is concerned...
We Experts here have seen that generally these types of issues are caused by developers using techniques that were, ...(and don't take this the wrong way).... "questionable" to begin with.
;-)

It seems that many things that VBA let "Slide" are not possible in Access 2007.
Some examples are the use of undeclared variables and certain syntax for referring to other forms.

Other examples are that many "dangerous" code segments could run in older versions, but are stopped from running by the new "Trust" center in Access 2007.

Finally, in my own experience I have found that there is always "something" that goes wrong whenever you try running a 2003 DB on Access 2007 and vice versa.

;-)

JeffCoachman
Jeff -
I agree "Echo" is what I want, and "Hidden" is not.  But, somewhere in this chain of posts, it was mentioned and I wanted at least to give it consideration.
I don't take anything you say the "wrong way".  ;-)
Having been doing this now for over 40 years, I am fully aware of loopholes being closed in newer versions of products.
As for questionable practices, in my case, major chunks of code in 5 critical applications, code that was designed by some very expensive and highly skilled Microsoft technicians, worked in 2003 but not in 2007.  If anyone would avoid questionable VBA, you would think it would be them.  
As for dangerous code, I would not think Echo should be considered in that vein.
In my experience, the number of things that have gone wrong while trying to run 2003 apps in 2007 leads me to state emphatically that the phrase "backward compatible" certainly does not mean to Microsoft what it means to me!
And I do not blame the experiences I have had on Microsoft -- I blame them on the person in my company who decided everyone and everything had to be upgraded to Office 2007 before the product had matured enough (e.g. gotten to SP2 or SP3).
;-)
All that being said, do you think Echo not working within a modal dialog is a bug in 2007?
Bill
 
OK,

If you want to give the Hidden argument a try, then here is the basic syntax:
      DoCmd.OpenForm "YourForm", , , , , acHidden

  "As for dangerous code, I would not think Echo should be considered in that vein. "
It's not, I was just using that as an example.
(The "Kill" command would have been a better example)


Again as far as the issues I have swapping versions, it may be something with my machine?
:-O
So I, like you, cannot really blame Microsoft.
;-)

I think if your company just uses Office from an end user standpoint, then all is well.
But as soon as you have advanced automation, things might not go as smoothly as planned (to say the least)
;-)

A well you know, you will always find a developer who will state that they had absolutely no issues upgrading.

I have to get home to try your "bug" theory, where I have Access 2003 and 2007 on the same machine.

Jeff
I don't really want to pursue "Hidden"!  I am at a loss why anyone would want to "open" a "hidden" form.
Probably goes with the line of thinking that you should go to the "Start" button to "Shut Down"!  :-)))
I am at a loss why anyone would want to "open" a "hidden" form.

1. Can make forms "appear" to load faster.
By opening a slow loading form and keeping it hidden you can "unhide" it, and it will seem to open quicker.
2. Persistance.
You can still reference controls on a hidden Form.
Keeping a form open and hidden can be used to keep certain DB connections open.
3. Amaze you friends at your "Database Parties"
Display 3 open forms, but yet the Forms collection count lists 4 open forms!
;-)

JeffCoachman
I knew there was something of value here!!
1. Cool... I'll try that
2. Interesting... I'll also try that
3. No offense, but I have much more interesting parties than that...
;-)
Anything further on this?
No,

Are you saying that the issue is still not resolved?
Correct.  The last question I posed was "do you think it is a bug"?  You indicated you would try the "bug" theory on both 2003 and 2007 and I had not heard the results.
Can you post a sample of your database that exhibits this issue?
Because of the complexity, this will make it easier to test.
Unfortunately, my boss will not allow me to do that.  I will try to come up with a test case, but might not have it until Monday.
OK,

Again, I just need a file that exibits the issue
That was a long weekend... ;-)  If only it really was...
I have created a small Access 2007 ACCDB that illustrates the problem.  Please find it attached.
Open Main Screen then click on the buttons to open the Dialog form as acDialog, where the problem occcurs, or as acWindowNormal, where the problem does NOT occur.

Dialog-Echo-Test.accdb.txt
ASKER CERTIFIED SOLUTION
Avatar of Jeffrey Coachman
Jeffrey Coachman
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Jeff,
<The newer syntax is "Application.Echo">  -  I know, but was too lazy to change it, I guess. ;-)
<Me.Painting=False [True]> is almost perfect!  But it certainly is a major part of the solution.  If you use "Me.Painting =" instead of "Application.Echo", the painting on the subdialog is suspended, but the underlying main form flashes through for a fraction of a second if, in the dialog form, you reference anything on the main form.  I found I had to use both "Application.Echo False [True] and Me.Painting = False [True] in combination.  (Or, I could have put all required data into variables before calling the dialog.
Many thanks for solving a tough one.  The solution was so simple, though, as many times it is... ;-)
Can I ask -- did you by any chance see another of my questions?  Asking you this way may not be kosher, but could you take a look at it:
"How do I encrypt/decrypt data on SQL DB using MS ACCESS - part 2 "
Thanks, This was actually an interesting question.
;-)

<did you by any chance see another of my questions?  Asking you this way may not be kosher, but could you take a look at it:>
Thats fine, but just post the link to the question, so I can just click on it.
;-)

Jeff

Encryption, and SQL are not my strong points.

It seems that you are already getting great advice in that Q already.
;-)

Jeff