Show/Hide a Dialog Form

[OldBirdman]

Yeah, I saw *8. It make no sense to me. I get a 0 if I call it. I'm not sure how it applies to the problem I stated.

[MMcCarthy]

Yeah, I saw *8. It make no sense to me. I get a 0 if I call it. I'm not sure how it applies to the problem I stated.

Don't 'call' the function.

Just put in the line

	DoEvents

after you apply the new form filter and before you requery or do anything else with the form.

[NeoPa]

Yeah, I saw *8. It make no sense to me. I get a 0 if I call it. I'm not sure how it applies to the problem I stated.

What Mary means (I think) is that you should not worry about the value returned from the function when you call it. The effect of the function (allowing other code to get a look in), is what's required and the return value (0 in this case) simply tells you how many forms you have open at that time.
VBA has many ways of ignoring the value from a function. I normally use the Call statement, as it shows, explicitly, to any reader of the code that you don't care about the result (as well as showing that it's a procedure call and not an array reference or such like).

Call DoEvents

I suspect, in this case, that it is equivalent to Mary's version :

DoEvents

[MMcCarthy]

What Mary means (I think) is that you should not worry about the value returned from the function when you call it. The effect of the function (allowing other code to get a look in), is what's required and the return value (0 in this case) simply tells you how many forms you have open at that time.
VBA has many ways of ignoring the value from a function. I normally use the Call statement, as it shows, explicitly, to any reader of the code that you don't care about the result (as well as showing that it's a procedure call and not an array reference or such like).

Call DoEvents

I suspect, in this case, that it is equivalent to Mary's version :

DoEvents

It is!

The call statement is nice programming but it's not necessary in Access VBA. It's implicit default.

Mary

P.S. Thanks for explaining what I meant :D

[NeoPa]

It is!

The call statement is nice programming but it's not necessary in Access VBA. It's implicit default.

Mary

P.S. Thanks for explaining what I meant :D

I wasn't trying to be cheeky Mary.
There is a slight difference between using Call and not :
Call expects the parameters after a function to be enclosed in parentheses () whereas otherwise they're not. Obviously with a parameterless function call there would be no noticeable difference.

The effect is exactly the same though, as you say.

[MMcCarthy]

I wasn't trying to be cheeky Mary.
There is a slight difference between using Call and not :
Call expects the parameters after a function to be enclosed in parentheses () whereas otherwise they're not. Obviously with a parameterless function call there would be no noticeable difference.

The effect is exactly the same though, as you say.

I only ever enclose the parameters if there is a return from the function.

I was only joking, I know you would never dare to be cheeky to me :rolleyes:

[NeoPa]

I only ever enclose the parameters if there is a return from the function.

I was only joking, I know you would never dare to be cheeky to me :rolleyes:

That's sort of the point, in that Call treats it more like a function call, but explicitly telling it to ignore the returned value.

I like the heretofore unsuspected extra smiley (Don't tell Killer - -He'll want one).
I can see that one getting some use, between us somehow :rolleyes: (see?)

[OldBirdman]

Please forgive the long delay. I forgot how to find my posts, and the answer to that question was within my posts.

After all the above discussion on DoEvents, only the single "DoEvents" will work. Access VBA gives errors for DoEvents(), Call DoEvents and Call DoEvents(), although I like the argument around Call Xxx to show that a procedure is being called, and the return value (if any) is ignored.

DoEvents does not stop the code.

This line of attack seems to be getting nowhere. To go back to the original problem: how to have a form that is Modal when visible, but that is hidden most of the time. This would allow the fields to be accessable to the main form. In other cases, it would preserve the settings on the hidden form until that form is used again, and then the status of the form would be as it was when hidden.

OldBirdman

[NeoPa]

Please forgive the long delay. I forgot how to find my posts, and the answer to that question was within my posts.

After all the above discussion on DoEvents, only the single "DoEvents" will work. Access VBA gives errors for DoEvents(), Call DoEvents and Call DoEvents(), although I like the argument around Call Xxx to show that a procedure is being called, and the return value (if any) is ignored.

DoEvents does not stop the code.

This line of attack seems to be getting nowhere. To go back to the original problem: how to have a form that is Modal when visible, but that is hidden most of the time. This would allow the fields to be accessable to the main form. In other cases, it would preserve the settings on the hidden form until that form is used again, and then the status of the form would be as it was when hidden.

OldBirdman

I'm afraid I can't help you much further. Everything I could think of I've posted already (Please feel free to review my earlier posts and ask for further clarification etc on any of them.)

You're right about DoEvents. It is possibly not a function, but is very useful nevertheless. It won't stop the code executing as such, but it will release control to the operating system and other processes. This is critical if you intend to use a loop to delay code from executing (Test status; DoEvents; Loop back; ). Without it you could create some misbehaving code.

Sorry I could be no more help :(

[OldBirdman]

Closure for hiding modal forms -
DoCmd.OpenForm WILL OPEN an already open form. Probably not really, but it will set properties as if it were opening the form. Therefore:
Main form -

Option Compare Database
Option Explicit

Private Sub cmdOpenFilters_Click()
    DoCmd.OpenForm "fFilters", acNormal, , , , acDialog
    txtFilters = Forms!fFilters.txtTest
End Sub 'cmdOpenFilters_Click

Private Sub cmdOpenOptions_Click()
    DoCmd.OpenForm "fOptions", acNormal, , , , acDialog
    txtOptions = Forms!fOptions.txtTest
End Sub 'cmdOpenOptions_Click

2 Identical forms, fFilters and fOptions -

Option Compare Database
Option Explicit

'txtTest is inititalize to "Zero" in Properties Dialog

Private Sub cmdClose_Click()
    Me.Visible = False
End Sub 'cmdClose_Click

Private Sub cmdSetText_Click()
    If txtTest = "Zero" Then txtTest = "One" _
            Else If txtTest = "One" Then txtTest = "Two" _
            Else txtTest = "One"
End Sub 'cmdSetText_Click

Either form can be shown, modal, so the other form cannot be shown simultaneously. Forms remain open when hidden, so values are preserved and are also available to main form. The assignments to txtFilters or txtOptions after the "DoCmd.OpenForm " are not done until the forms are hidden.

My Google Searches on this problem before I presented it to this forum found the same issue on other forums, basically unresolved.

Thanks to all who worked on this problem.

OldBirdman

[Denburt]

The assignments to txtFilters or txtOptions after the "DoCmd.OpenForm " are not done until the forms are hidden.

This seems to be the issue I don't think anyone understands this part. What exactly does the form do? I could sit here and guess all day about that alone.

I am thinking that these two forms (txtFilters or txtOptions) filter a form or query or report and you are saying that the form or report isn't updating properly with the filtered results?

If I understand correctly when the form becomes Modal or Visible you want the user to take action before some code runs... where is the code and can you move it to another location such as form deactivate?

[OldBirdman]

Explanation of #25 --
I solved my original question, and as no solution was presented by this forum, I wanted to show a solution and thank those who addressed this issue.

Apparently my post #25 is unclear. It as simple as I could write the code, and still mimic the complex program from which it was extracted.

Main form has 2 command buttons, cmdOpenFilters and cmdOpenOptions.
On Click of either does a DoCmd.OpenForm 'formname', , , , , acDialog
line 6 or 11 are to demonstrate that the current value on that form is retrieved, in other words, that the form is MODAL, that the code waits until the user is done with the form. The form also contains 2 TextBoxes, txtFilters and txtOptions.

fOptions & fFilters are identical for test purposes only. Each contains a command button cmdClose and a command button cmdSetText. cmdSetText changes the value in TextBox txtTest in a very simple way. txtTest is given a Default Value of "Zero". cmdSetText changes that value in a predictable way, and allows all testing to be done with the mouse only, not having to type.

Post #1, Sentence 1 defines my question. Sentences 2-4 are what I think I mean by the words I am using. The remainder of this post show what I have tried. I did not think that exactly what the form(s) did pertained to the problem.

Post #3 misunderstood problem, thought I wanted a form to be modal and hidden simultaneously.

Post #4 I attempted to clarify

Post #6 suggested using "DoEvents", which did not work because the form wasn't modal, and so there was nothing else to wait for.

Post #11 was an attempt to bring the discussion back to the problem, "I want a form visible to my code, and when visible to my users, modal"

Post #23, I still did not have a solution

Post #24, Sorry, we can't help

Post #25, I succeeded, and thank you. Here is my solution: use 'DoCmd.OpenForm "formname", acNormal, , , , acDialog' even for an open form. "Open" in all above discussion means that the controlls are accessable to code.

It doesn't make any difference to the problem what the modal forms do or how they do it, just that they have controls with properties that I need in the code for my main form.

[MMcCarthy]

I'm glad you got your solution.

There is something you should keep in mind however.

You can see your database and understand how it functions. The experts can't. They rely totally on the information provided by the poster and sometimes regardless of the posters best efforts it is very difficult to visualise the problem. As you said yourself you didn't fully understand what you required initially and may have led the experts to look in the wrong direction.

In an effort to help you experts will often ask a series of questions to help them better visualise your problem. Although these questions may not be directly relevant they can help the experts to a better understanding.

Communicating technical problems in this medium is difficult at times and our experts volunteer their valuable time in an effort to help you overcome your problems.

Mary

[Denburt]

Glad you got it, I didn't think you had a difficult problem but didn't understand why you needed to pause the code. Generally speaking in situations where some code needs a pause or break it is usually best to try and rearrange the code somewhat and that makes for a cleaner solution. This is why I was asking the questions I was asking. I overlooked a couple of things along the way that may have help me understand better however it is as I stated earlier.

.
I am changing the filter for the current display, the code runs with the original filter, because the computer is faster than my typing.

If you want the original or calling form to display the results from your filter or options form you can use the deactivate event on the options form and runn the filter from there.

FYI:
pop-up (pop-up form: A form that stays on top of other windows. A pop-up form can be modal or modeless.)

modal (modal: A window or dialog box that requires the user to take some action before the focus can switch to another form or dialog box. Dialog boxes and messages are usually modal.)


Have a nice day and if you would like any further assistance we will surely do what we can.

[NeoPa]

Explanation of #25 --
I solved my original question, and as no solution was presented by this forum, I wanted to show a solution and thank those who addressed this issue.

...

Thank you for taking the time to :

1. Post your solution for the benefit of our other members.
2. Thank all the members who tried to help, even though it was not always as successful as we'd have liked.
3. Explain the thread in a fairly concise resume to help resolve any potential residual misunderstandin gs.

A perfect example of good manners :)