Show/Hide a Dialog Form

[OldBirdman]

I want a form that is Modal, PopUp, and Dialog, but that is hidden most of the time so that the fields are available to the code of my other forms.
Modal means that only the form can have control, until it is closed or hidden, I hope.
PopUp means that the form remains on top of other forms, I hope.
Dialog means that the code stops until the form is closed or hidden, then the code continues, I hope.

The form ("fOptions") properties are Pop Up=Yes, Modal=Yes, and BorderStyle=Dialog.

I open form with:
DoCmd.OpenForm "fOptions", acNormal, , , , , acHidden
or
DoCmd.OpenForm "fOptions", acNormal, , , , acDialog, acHidden

When I do Forms!fOptions.Visible = True, the code doesn't wait for the form to be hidden again (not Dialog?).

How may I achieve this objective?

Old Birdman

P.S. Is there a thescriptsforum for dummies?

[MMcCarthy]

Old Birdman

P.S. Is there a thescriptsforum for dummies?

Like the name and don't worry we take all comers in the question stakes. Just one thing, you have posted this in the Articles section rather than in the forum. I am now moving this question to the Access forum.

Mary

[NeoPa]

I want a form that is Modal, PopUp, and Dialog, but that is hidden most of the time so that the fields are available to the code of my other forms.
Modal means that only the form can have control, until it is closed or hidden, I hope.
PopUp means that the form remains on top of other forms, I hope.
Dialog means that the code stops until the form is closed or hidden, then the code continues, I hope.

The form ("fOptions") properties are Pop Up=Yes, Modal=Yes, and BorderStyle=Dialog.

I open form with:
DoCmd.OpenForm "fOptions", acNormal, , , , , acHidden
or
DoCmd.OpenForm "fOptions", acNormal, , , , acDialog, acHidden

When I do Forms!fOptions.Visible = True, the code doesn't wait for the form to be hidden again (not Dialog?).

How may I achieve this objective?

Old Birdman

P.S. Is there a thescriptsforum for dummies?

Interesting question. You don't sound like a dummy to me.
Unfortunately, if I'm right, you can only have a form work modally if it is visible.
I'm not sure exactly what allows code to continue (close or hide), but if it's Hide, then I wouldn't expect a Show to suspend the code again. If truth be told, I wouldn't expect the Hide to resume the code execution either, but that's only my guesswork.

Code resumption can be arranged (not straightforwardly :() by using the OnTimer event to check the status of the form. It means redesigning the structure of the code a little I'm afraid.

[OldBirdman]

I am Dummy as to using this site. I posted to "Articles Section" in error, Thanks Mary for moving post.
I have tried to search Access Section, but all searches seem to be of entire site, and must read through too many hits, when I don't even understand most of the stuff outside Access.
I am afraid to turn off computer after post, as I don't know how to find MY Thread again.

My question is apparently not understood.
1. If I originally open my Options Form with "DoCmd.OpenForm "fOptions", acNormal, , , , , acHidden" and with the form properties as PopUp=True; Modal=True; BorderStyle=Dialog then the form is open and accessable for such tests as: "If Forms!fOptions.chkConfirmDelete then ... Msgbox ..... End If"
2. If my command button "Change Options" uses the code "Forms.fOptions.Visible = True", the form shows, and is modal. I cannot use the primary form until I close fOptions, but the code continues to the end. No problem if I am changing choices for future events, but if I am changing the filter for the current display, the code runs with the original filter, because the computer is faster than my typing.
3. Selecting the command button "Change Options" again will achieve the desired result, as the code runs to completion with the prior open of the form.

I am not trying to run a modal/dialog form while hidden, only when visible. I could assign all items on the form to Global Variables, but this seems awkward, and Access continually loses all values for Global Variables if ANY ERROR occurs. This means that whenever I debug a program, and an error occurs, I may loose the values of ALL global variables. This makes debugging very slow and lots of clicks.

[NeoPa]

I am Dummy as to using this site. I posted to "Articles Section" in error, Thanks Mary for moving post.
I have tried to search Access Section, but all searches seem to be of entire site, and must read through too many hits, when I don't even understand most of the stuff outside Access.
I am afraid to turn off computer after post, as I don't know how to find MY Thread again.

Let's deal with the easy first then.
Searching within a particular forum:
This is a relatively new feature and is still having teething troubles. When the option is there, there will be a selection of the current forum or the whole site. You're just unlucky enough to come in at a time of great flux.
Finding posts again:
Wherever you are in the site, there should be a menu type area at the top-right. It will show something like :

0 PMs | Control Panel | Buddy List | Help | Site Map

If you click on Control Panel it will show you a list of ALL the threads you're subscribed to. This will include, but not be limited to, all the threads that you have initiated.

[MMcCarthy]

I am Dummy as to using this site. I posted to "Articles Section" in error, Thanks Mary for moving post.
I have tried to search Access Section, but all searches seem to be of entire site, and must read through too many hits, when I don't even understand most of the stuff outside Access.
I am afraid to turn off computer after post, as I don't know how to find MY Thread again.

My question is apparently not understood.
1. If I originally open my Options Form with "DoCmd.OpenForm "fOptions", acNormal, , , , , acHidden" and with the form properties as PopUp=True; Modal=True; BorderStyle=Dialog then the form is open and accessable for such tests as: "If Forms!fOptions.chkConfirmDelete then ... Msgbox ..... End If"
2. If my command button "Change Options" uses the code "Forms.fOptions.Visible = True", the form shows, and is modal. I cannot use the primary form until I close fOptions, but the code continues to the end. No problem if I am changing choices for future events, but if I am changing the filter for the current display, the code runs with the original filter, because the computer is faster than my typing.
3. Selecting the command button "Change Options" again will achieve the desired result, as the code runs to completion with the prior open of the form.

I am not trying to run a modal/dialog form while hidden, only when visible. I could assign all items on the form to Global Variables, but this seems awkward, and Access continually loses all values for Global Variables if ANY ERROR occurs. This means that whenever I debug a program, and an error occurs, I may loose the values of ALL global variables. This makes debugging very slow and lots of clicks.

Try putting a DoEvents command in the appropriate place. This will tell the processor to complete all previous commands before moving forward.

[OldBirdman]

Help "DoEvents" is an example, I cannot find a description of this function. Therefore, I cannot find where might be an appropriate place. Can you elaborate?

[NeoPa]

Help "DoEvents" is an example, I cannot find a description of this function. Therefore, I cannot find where might be an appropriate place. Can you elaborate?

DoEvents Function


Yields execution so that the operating system can process other events.

Syntax

DoEvents( )

Remarks

The DoEvents function returns an Integer representing the number of open forms in stand-alone versions of Visual Basic, such as Visual Basic, Professional Edition. DoEvents returns zero in all other applications.

DoEvents passes control to the operating system. Control is returned after the operating system has finished processing the events in its queue and all keys in the SendKeys queue have been sent.

DoEvents is most useful for simple things like allowing a user to cancel a process after it has started, for example a search for a file. For long-running processes, yielding the processor is better accomplished by using a Timer or delegating the task to an ActiveX EXE component.. In the latter case, the task can continue completely independent of your application, and the operating system takes case of multitasking and time slicing.

Caution Any time you temporarily yield the processor within an event procedure, make sure the procedure is not executed again from a different part of your code before the first call returns; this could cause unpredictable results. In addition, do not use DoEvents if other applications could possibly interact with your procedure in unforeseen ways during the time you have yielded control.

To get help on this, open the Immediate pane in the VBA window (Ctrl-G), type in DoEvents then press F1. This will invoke context-sensitive help for whatever is under the cursor.

[NeoPa]

Getting back to the second part of the question (Post #4) though, I would say that the code that succeeds the opening of the modal form, and which depends on the form being closed again (or hidden) should be placed in a publicly accessible function which can be called by the code which hides the form. This is, in effect, the logically correct place for it to be in object-oriented programming (IMHO).
It is code that depends on the form being closed, therefore it should be triggered (somehow) by the closing of the form.

[OldBirdman]

OK, I did that. DoEvents gives the value 0, which according to Help means that nothing is running. As to how it applies to my problem, I am uncertain.

[OldBirdman]

To solve my problem I am uncertain. I have an answer, but I do not understand. I very much appreciate all the effort being expended to resolve my issues, but I still am not certain I understand. I want a form visible to my code, and when visible to my users, modal. I still don't think I understand how to achieve this.

[NeoPa]

Which answer are you referring to?

[OldBirdman]

Help "DoEvents" is an example, I cannot find a description of this function. Therefore, I cannot find where might be an appropriate place. Can you elaborate?

[MMcCarthy]

Help "DoEvents" is an example, I cannot find a description of this function. Therefore, I cannot find where might be an appropriate place. Can you elaborate?

Can you post the actual code you are using as I think there is some confusion.

[NeoPa]

Help "DoEvents" is an example, I cannot find a description of this function. Therefore, I cannot find where might be an appropriate place. Can you elaborate?

I thought I'd explained that quite fully in post #8. Did you see that one?

[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 misunderstandings.

A perfect example of good manners :)

[erici]

Just for clarification:

Opening a form with acDialog will set the forms Modal and Popup properties to True. Once a form is opened, the popup property is readonly, so it can only be set when opening the form.

If the form is opened with acDialog, the code that opened the form will stop executing until the form is closed.

If you open the form in acHidden mode or acWindowNormal, or any other setting, the code that executed the openform will keep executing after the form is opened.

DoCmd.OpenForm FormName:="frmName", WindowMode:=acWindowNormal
MsgBox "This msgbox will show up when the form is opened."
 
DoCmd.Close acForm, "frmName"
 
.
.
.
 
DoCmd.OpenForm FormName:="frmName", WindowMode:=acDialog
MsgBox "This msgbox will NOT show up until the frmName form is closed or made invisible."

.
.
.
Opening the form in Dialog mode has the benefit of forcing the user to close (or make the form invisible) before they can continue AND stopping the code.

This has some obvious benefits since the code after the opening of the form in Dialog mode will halt until the user is done working with the form. You can set the visibility of the form to false (via an OK or Cancel button) and then the code that called the form can immediately read those values from the form.

The biggest problem with acDialog, Modal, and Popup is that you can't get the same functionality with the code stopping executing if you want to do something to the form in code before it's displayed to the user...

Dim frm as Form
DoCmd.OpenForm FormName:="frmName", WindowMode:=acHidden 'Opens form with Visible set to False
Set frm = Forms!frmName
frm.Modal = True
frm.Visible = True
'frm.Popup = True  (You can't do this, as Popup is a readonly property)
MsgBox "This msgbox will show up when the form is made visible, not when the form closes."

.
.
.

The only work arounds for this, that I'm aware of are Timers or Loops...

Dim frm as Form
DoCmd.OpenForm FormName:="frmName", WindowMode:=acHidden 'Opens form with Visible set to False
Set frm = Forms!frmName
frm.Modal = True
frm.Visible = True
 
Do While frm.Visible=True 'Test for form being invisible
    DoEvents
Loop
 
MsgBox "This msgbox will show up when the form is made invisible (but will error if the form is closed (because frm will refer to an invalid object.)"
 
Do While (SysCmd(SYSCMD_GETOBJECTSTATE, A_FORM, "frmName") <> 0) 'Test for form still being open
    DoEvents()
Loop
 
MsgBox "This msgbox will show up when the form is closed, but will not show up while the form is opened either visible or invisible."

I hope that helps someone.

[erici]

This code would mimic the dialog mode...

Dim frm as Form
DoCmd.OpenForm FormName:="frmName", WindowMode:=acHidden 'Opens form with Visible set to False
Set frm = Forms!frmName
frm.Modal = True
frm.Visible = True
 
 
Do While (SysCmd(SYSCMD_GETOBJECTSTATE, A_FORM, "frmName") <> 0) 'Test for form still being open
If frm.Visible = False The
    Exit Loop 
End If
DoEvents()
Loop
 
MsgBox "This msgbox will show up when the form is closed or made invisible."

[OldBirdman]

In this case, let's assume I have 900 options. I have a form "fOptions". So I create a form with tabs, and allow you to check/choose/enter/select various choices. Controls include TextBoxes, ListBoxes, Frames with options, CheckBoxes, etc. You make all the choices you want, changing the default settings or not. Then you click "Done", "O K", or some such.

I have 2 choices in the code. Hide the form, and if I need to know what you selected, I can refer to Forms!fOptions.controlname or under cmdDone (or whatever I name the "I am finished changing Options" button"), I can have 900 assignment statements to global variables.
GlobalVariable1 = Forms!fOptions.xxxxx
. . . . .
GlobalVariable900 = Forms!fOptions.xxxxx
and then refer to GlobalVariablexxx when I need your choice.

From several attempts by all of you to answer my problem, I found a solution. None of you presented a solution, but all of you helped me solve my problem. In #27, I stated that I had a solution. I was done. I was satisfied. I thanked all of you.

I have reviewed post #1, and I don't see that I wasn't clear. "When I do Forms!fOptions.Visible = True, the code doesn't wait for the form to be hidden again (not Dialog?) How may I achieve this objective?"

I have an open form, fOptions, but hidden. I set .Visible to True. This works, but the form is no longer Dialog. If we are going to keep this thread open, then what was unclear? I read other's problems, and they require the problem solver to understand the user's program. I tried to present the problem as a simple program, with no details to distract from the actual problem.

Old Birdman's steps before submitting to this forum:
1. Write a description of my problem.
2. Write code that isolates the problem, eliminating code exclusive to this problem.
3. Test new code, determine if problem still exists.
4. If problem goes away, find solution within test program.
5. Review description within test environment.
6. Determine if isolate code is clear, and creates the problem.
7. Rewrite description of problem entirely within the isolated test environment.
8. Submit to Forum.

The code from the main form is:
DoCmd.OpenForm "fOptions", acNormal, , , , acDialog
The code on exit from fOptions is:
Me.Visible = False

At this point, the form exists, and is hidden. If the code:
Me.Visible = True
is executed, the form loses the Dialog attribute, and the calling procedure continues beyond the making of the form visible. But if the form is re-opened with:
DoCmd.OpenForm "fOptions", acNormal, , , , acDialog
even though already open, the form is made visible and is Dialog.

I now had what I needed to proceed.

If this thread is to continue, I want to know what in post #1 was not clear. I have re-read this several times, and cannot see why it is not clear.

Sentence #1: "I want . . . " states where I want to go.
Sentences #1-4 are definitions of terms. If wrong, they should be corrected, but nobody did. Therefore, I might presume PopUp, Modal, and Dialog are understood by me.

Sentence #5 "The form ("fOptions") . . . Clearly states I have a form, named "fOptions". and the Properties are as stated.

I then present 2 lines of code, both which open the form "fOptions". I want to show the form again, with the same properties, Modal, Dialog, and PopUp, by setting the Visible property to True. It doesn't work. I asked how to show the form as Dialog.

I don't know why anyone needs to know what the main form that opens fOptions does. Also, I don't know why the options on fOptions are is important.

I have tried other forums, and this one is very GENTLE compared to the others I tried, which I never returned to. (A preposition is not a good word to end a sentence with [Winston Churchill]). Followup questions, when solutions are presented but not understood, are treated kindly.

Old Birdman

[NeoPa]

I'm a little confused as to why you would want to continue the thread if you already have a solution (as stated earlier). I'm not trying to be argumentative (in case you thought that), but I thought you were happy that you'd found your solution.

As a separate point, you seem to be wondering how anyone could find your post #1 confusing?
Sometimes it is how information is laid out that is difficult for some people to understand. Always it is difficult for technical questions to be understood without the actual items in front of you to look at. I won't comment particularly on you post #1 as I don't want to spend more time analysing it for no purpose (unless that becomes necessary). I just make these points generally from my experience trying to answer the questions.
Actually, I checked out your post #1 (it was easier than not in the end) and I could find very little that was not clear. If I were to be very picky I would rewrite :

When I do Forms!fOptions.Visible = True, the code doesn't wait for the form to be hidden again (not Dialog?).

as :

When I do Forms!fOptions.Visible = True, the code continues to execute when I would have expected it to wait for the form to be hidden again (not Dialog?).

That would be picky though, as I said.
Threads like these though, are not always about the first post. Often direct answers cannot be found or are not possible. In situations like these it is necessary to offer alternative solutions that don't quite match the original requirement, but which offer a similar level of solution. It is very hard to do this without asking for more information. In situations like these, it is really a good idea to provide the information requested. Understanding the reasoning behind the request is not important.

[OldBirdman]

I do not know how to close a thread.

Yes, I was happy with the responses. But later I found posts to this thread after I was happy.

I continually monitor threads that are 3 months old, as I still get an occasional response. I need a "theScripts" for Dummies, because I don't know how to REALLY close a thread. I got an answer. I am done. Don't respond. I don't know how to do that.

OK. I agree that the more info, the better, but also, a sample program that has the same problem, but is not specific to the program may be more useful both to the original poster and to the group-at-large. I try to read many issues, as I may find solutions. If the problem is described TOOO specifically, I am not interested.

Were a member of this forum says something like: "My aluminum sliding windows 'whistle'", "Why?"

I might look at any response, but as soon as someone asks for the manufacturer of the windows, I'm not interested. It is no longer a general question, and the discussion goes to specifics. If I don't have that brand, any information beyond this point is not useful.

So I try to ask questions in the "generic" case. Nobody but me cares whether I have a table item as "Integer" or "Long". What is useful is whether a numeric item is correct for this problem. Doesn't matter if the number is Long, Integer, Long Integer, Decimal, or something else.

As to why I want to continue this thread, I want to stop it. How do I stop this thread? Now???

OldBirdman

[MMcCarthy]

Threads don't get "Closed" as often future visitors like to post a comment or as you've found experts come along afterwards with a variation or new opinion. Where NeoPa was confused was your latest post seemed to be asking a further question. We understand now that you were simply responding to the further opinions, sorry for the confusion.

Mary

[NeoPa]

Thanks for that Mary. I've been away for a couple of days so I'm just catching up now.
You're right about the post too, I was just trying to provide any info that might prove helpful. This thread is done with apart from that.

-Ade.