I need my code to wait... (modal?)

[Canderel]

Hi

I am importing a database, but I first need a couple of parameters from the user.

Now I write this mostly in Access VBA, since I come from programming background.

What I want to know is how can I let my code wait for the modal form to close before continueing?

Thanks

-Canderel

Sub ImportFoo()
'//Prepare files for import

docmd.OpenForm "frmImportParameters"    '//(with modal, pop-up, etc.)

'//---- WAIT For form to close ----    THIS IS MY Question... 

'//Import Code... This runs before I close (actually before the form opens about)
End Sub

 

[Mile-O]

docmd.OpenForm "frmImportParameters" '//(with modal, pop-up, etc.)

This method tells the form how to open and thus overrides your form's default properties.

You should open it modal in this method.

i.e.

DoCmd.OpenForm "frmImportParameters", , , , , acDialog

 

[Canderel]

Thanks so much!

While I am busy...

How do I access the values that's on that form?

Will

Forms("frmImportParameters")!Text0.Value

work?

 

[Mile-O]

It will, but it is much simpler to use:

Forms("frmImportParameters").Text0

. instead of !

And you can drop .Value as this is the default value of a control anyway.

 

[maxmangion]

[Forms]![formname]![controlname] ...............

 

[Canderel]

In ADO 1.5, it's possible to copy values from one Recordset field to another by using a command line such as:

destRst.Fields("myfield") = srcRst.Fields("myfield")

It has been found that explicitly specifying .Value on both sides of the expression will improve performance and will avoid a known issue with a small memory leak in this area. The new syntax to use would be:

destRst.Fields("myfield").Value  = srcRst.Fields("myfield").Value

This should improve performance and avoid the memory leak.

http://support.microsoft.com/default.aspx?scid=kb;en-us;230293

So, out of principal I use .value whenever I can. 'Cause I dunno which version of ADO or whatever I am using, and better be safe than sorry.

DoCmd.OpenForm "frmImportParameters", , , , , acDialog

MsgBox "Opened"

This worked the first time, but after that it didn't work. The "Opened" msgbox was upon me long before I closed the window.

I try to explain it by the fact that I hide the window, and not close it. But I feel it's better to hide, because of speed and to make sure the objects I refer to is still in memory.

Thanks

-Canderel

 

[Canderel]

Yes... it's because it's hidden and not closed... I checked it again. Thanks a lot for all of your help.

I'll be definately visiting here again when I run into tricky bits.



Cheers

-Canderel

 

[Mile-O]

To be honest, I'd never trust any advice that Microsoft give with respect to programming as, for example, they have an article on using best practice notation and then don't use it in their examples. And their wizards still need updated - ten years later.

 

[Canderel]

Hmmm... I'm not much of a programmer... that's why I take all the help I can get. And it's seems I am at the right place here.

Keep up the good work!

Cheers. (going home)

-Canderel

 

[Canderel]

Morning all.

Ok, back for more.

Now I've already fallen into this trap yesterday, when my code only hides the form instead of closing it alltogether.

So I'd like to know how do I check to see if the form is closed and not just hidden?

basically

if forms("frmImportParameters").open then   'How do I check this?
  DoCmd.Close "frmImportParameters"
end if
DoCmd.OpenForm ...

 

[MarkK]

If CurrentProject.AllForms("FormName").IsLoaded Then
   DoCmd.Close acForm, "FormName"
End If

Access 2002

 

[Canderel]

I'm still using 97, and CurrentProject doesn't get recognized.

We'll upgrade in a couple of months, but I assume there'll be something similar for 97.

Thanks.

 

[Mile-O]

First of all, don't rely on DoCmd.Close to just close your form - be explicit.

i.e.

DoCmd.Close acForm, "frmImportParameters"

As for the is a form loaded? question - there is a function in the Northwind database that you can use.

Function IsLoaded(ByVal strFormName As String) As Boolean
 ' Returns True if the specified form is open in Form view or Datasheet view.
    
    Const conObjStateClosed = 0
    Const conDesignView = 0
    
    If SysCmd(acSysCmdGetObjectState, acForm, strFormName) <> conObjStateClosed Then
        If Forms(strFormName).CurrentView <> conDesignView Then
            IsLoaded = True
        End If
    End If
    
End Function

Stick that in a module and call it like so:

If IsLoaded("frmImportParameters") Then
    MsgBox "Form is loaded"
Else
    MsgBox "Form is not loaded"
End If

 

[Canderel]

SJ, you specialize in hitting the spot!

Thanks your solution(s) all work!

 

[Canderel]

Still vaguely relevant to the topic...

If I want the user to input data onto a form, but I do not connect it to a table or a query, then the only way for the data to remain accessable is to not close the form. Right?

Any other way to create 'global' variables? Or can I create a table with only one entry in the table, and add fields (variables) to the table as I need more?

If I create a table like this, what is the easiest way to access the actual content in it?

This is probably very bad database design though, so maybe I should just let it go.

Comments?

-Canderel

 

[Mile-O]

This is probably very bad database design though, so maybe I should just let it go.

What might be better is if you just explain what exactly it is that you want to do - the best advice, always, is that which is relevant to your needs.

 

[Canderel]

Well, at this stage I have a couple (4) of user-input variable that I want to save, in an easy accessable place (like a global variable in a programming language).

They are all date, or date like variables. Some range checking needs to be done on them, and they are called up for reports etc.

This is at the moment. But as the database grows I can see that these odds and ends bits of user-input will need to be centralized. And my current method, saving it on a form's unbound textboxes is far from a fail safe method of retaining these bits of data.

So I thought that I could create a table with these bits of data in them. But they need to be overwritten when they are changed... not added into a table as such.

So trying to be specific, but still being somewhat vague I'm sure, that's what I need.

-Canderel

 

[Mile-O]

It may just be down to our different ways of thinking but...

Are the values in this unbound form being used as criteria for a query displayed in a report?

 

[Canderel]

Some of it yes. (I just posted a question about that...)

But some of it has a direct impact on the import process.

Eventually we'd like to mail different reports to different people... but that's like phase 99.

This should become automated, and that's the dream we're going at.

-Canderel